Project

General

Profile

Actions

Feature #703

closed

Configurable required fields per tracker/status/role

Added by Sven Schuchmann about 16 years ago. Updated almost 9 years ago.

Status:
Closed
Priority:
Normal
Category:
Issues workflow
Target version:
Start date:
2008-02-21
Due date:
% Done:

0%

Estimated time:
Resolution:
Fixed

Description

Hi,
I think it would be nice to be able to configure the required fields
for an issue. I know that you can do this for custom fields, but not with
the predefined ones.

e.g.:
- I would like to have "Category" and "Assigned to" to be required
- I does not make sense to have "Tracker", "Status" and "Priority" to
be required, because you even don't have an option to leave them empty.


Files

workflow_permissions.png (13.7 KB) workflow_permissions.png Jean-Philippe Lang, 2012-07-15 18:23

Related issues

Related to Redmine - Feature #2708: Require CategoryClosed2009-02-10

Actions
Related to Redmine - Feature #1091: Disabling default ticket fields per trackerClosedJean-Philippe Lang2008-04-23

Actions
Related to Redmine - Feature #1919: Separate permissions for changing assigned-to, % finished and target versionClosed2008-09-18

Actions
Related to Redmine - Feature #8050: Mightful workflow field enhancement: visible, read only and mandatory Closed2011-04-03

Actions
Related to Redmine - Feature #4584: Require a Target Version and Category and provide a default version.Closed2010-01-14

Actions
Has duplicate Redmine - Feature #9136: Mandatory Due Date SwitchClosed2011-08-26

Actions
Has duplicate Redmine - Feature #11055: Conditional mandatory fieldsClosed

Actions
Has duplicate Redmine - Feature #582: Make fields mandatory/unmandatory based on roleClosedJean-Philippe Lang

Actions
Has duplicate Redmine - Feature #2500: configure custom fields as "required for status transition"Closed2009-01-13

Actions
Has duplicate Redmine - Feature #1917: Required on closeClosed2008-09-18

Actions
Has duplicate Redmine - Feature #13336: Custom field option for issues: "required before closed"Closed

Actions
Has duplicate Redmine - Feature #10394: Implement permission "Assign users to issues".Closed

Actions
Has duplicate Redmine - Feature #514: Custom Field on Closing ScreenClosed

Actions
Has duplicate Redmine - Feature #4670: Fine tune "New Issue"Closed2010-01-27

Actions
Has duplicate Redmine - Feature #16716: Due Date CompulsoryClosed

Actions
Actions #1

Updated by Paul Voelker almost 15 years ago

Thumbs WAY up on this request.

I think it would also be great to be able to configure what fields can be seen by what roles. Especially when entering issues. For example, consider the "assigned to" field…

Right now, anyone that can enter an issue can set the "assigned to" field. I would really prefer that "reporter" and "non member" role users not be able to do this.

Actions #2

Updated by michael bequette almost 15 years ago

This issue issue would be AMAZING!!! It is SOOO NEEDED!!!

Actions #3

Updated by Michael Chadwick over 14 years ago

Completely agree. We have multiple I.T. staff members and when our less-than-technically minded users try and send in tasks, we don't always see them because they don't get assigned. We really want to make Assigned To a required field and I cannot figure out how to do so.

Thanks for this fantastic application, though - it has changed our lives!!

Actions #5

Updated by Nanda P over 14 years ago

Any chance of having this feature in 0.9 ?

Configurable required fields like,
  1. Assigned to:
  2. Category:
Actions #6

Updated by Kamil . over 14 years ago

+1 for 0.9
(and where is the voting option by the way?!)

Actions #7

Updated by Nanda P about 14 years ago

Any body has patch for this? (make "Category:" as required field)

Actions #8

Updated by Jean-Philippe Lang about 14 years ago

The following patch makes issue category required:

Index: app/models/issue.rb
===================================================================
--- app/models/issue.rb    (revision 3238)
+++ app/models/issue.rb    (working copy)
@@ -48,7 +48,7 @@

   DONE_RATIO_OPTIONS = %w(issue_field issue_status)

-  validates_presence_of :subject, :priority, :project, :tracker, :author, :status
+  validates_presence_of :subject, :priority, :project, :tracker, :author, :status, :category
   validates_length_of :subject, :maximum => 255
   validates_inclusion_of :done_ratio, :in => 0..100
   validates_numericality_of :estimated_hours, :allow_nil => true
Actions #9

Updated by Nanda P about 14 years ago

Jean-Philippe Lang wrote:

The following patch makes issue category required:

[...]

JP, Thanks a lot for the patch. It is working fine for new issues, but not for update (System let me blank the category value during update)

Regards,
Nanda

Actions #10

Updated by Nanda P about 14 years ago

Jean-Philippe Lang wrote:

The following patch makes issue category required:

[...]

Required field indicator (*) is not showing up.

Actions #11

Updated by Mischa The Evil about 14 years ago

Added issue-relationship to issue #1091.

Actions #12

Updated by Jose Luna almost 14 years ago

+1 I just wanted to say that we need this too (making the assigned-to field required). I hope it's helpful for us add comments to the request, so that you know what the community would like to see in future versions.

Actions #14

Updated by Anton Statutov almost 14 years ago

The Jean-Philippe Lang's solution is not suitable for me because there are projects without categories. So not being familiar with ruby I made the patch which simply selects first available category:

diff --git a/app/models/issue.rb b/app/models/issue.rb
index 8574a61..f4ebb29 100644
--- a/app/models/issue.rb
+++ b/app/models/issue.rb
@@ -211,15 +211,6 @@ class Issue < ActiveRecord::Base
   end

   def before_create
-    # default category
-    if category.nil? && project && project.issue_categories
-       project.issue_categories.each do |issue_category|
-           if category.nil?
-               self.category = issue_category
-           end
-       end
-    end
-
     # default assignment based on category
     if assigned_to.nil? && category && category.assigned_to
       self.assigned_to = category.assigned_to

I tried to add 'default' field to category to be able to choose default category, but with no success. Maybe someone could help me to do it?

Actions #15

Updated by Katrina Brinkley almost 14 years ago

Paul Voelker wrote:

Thumbs WAY up on this request.

I think it would also be great to be able to configure what fields can be seen by what roles. Especially when entering issues. For example, consider the "assigned to" field…

Right now, anyone that can enter an issue can set the "assigned to" field. I would really prefer that "reporter" and "non member" role users not be able to do this.

Ditto this for me. We're trying to use this as a helpdesk system as well.

Actions #16

Updated by Mortitia Adams over 13 years ago

+1
would be very important to have such a right, to dis-/enable fields for the specific roles.
This missing feature is the only reason, i can't use redmine in my company (they don't want the customer/reporter to assign tickets to specific users) :(

Actions #17

Updated by Caio Cunha over 13 years ago

Paul Voelker wrote:

Thumbs WAY up on this request.

I think it would also be great to be able to configure what fields can be seen by what roles. Especially when entering issues. For example, consider the "assigned to" field…

Right now, anyone that can enter an issue can set the "assigned to" field. I would really prefer that "reporter" and "non member" role users not be able to do this.

+1

Very usefull feature. When using as a helpdesk would be really nice to hide some options, in other cases, just don't let the users to update it, not even the requirer.

By the way, after all the issue updates, what does the Redmine team says about this feature?

Thanks,
C.

Actions #18

Updated by Mischa The Evil over 13 years ago

Added relation to issue #1919 as it might be interesting in the light of the scope of this issues subject.

Actions #19

Updated by Caio Cunha over 13 years ago

Think would be nice to be able to do a "fine tuning" on view/change field permissions for roles. And also have a "default permissions settings" feature in the scope of the category, project and overall.

This comment also (or better) applies to issue #1919.

Cheers,
CaioToOn!

Actions #20

Updated by Christophe Absil over 13 years ago

We are currently using Redmine for internal project management but I want to open Redmine to our customers. In order to create a new issue, Redmine displays unnecessary non required fields even if we reduces the permissions of the role as much as we can. For example, "assigned to", "Priority", ... are confusing for an external reporter. It would be great to hide/show non required default fields based on user's role.

I have read some comments in the forum and found that this issue was covering that feature. Am I wrong ? If not, does anybody have an idea when this feature will be implemented ? Hope the answer will be "It is already there ..." ;-). Opening Redmine to our customers is part of our "end of year targets".

Regards

Christophe Absil

Actions #21

Updated by Ben Collins over 13 years ago

+1

I am also in the process of (trying) to start using Redmine for bug tracking too. But Issues reports will come more or less from the end user perspective, they do not know which fault it is, how long it will take it to fix it etc.

AFAIK erasing the default field is not possible, maybe one of the following options is more do able:

  1. option greying them out so the issue reporter can't enter values there
  2. ignoring them. the issue reporter: values can enter the values, but there will be simply not saved
  3. informing the issue reporter: this value(s) are/is only a "hint" or a "suggestion"

I hope this import detail issue goes not down in the noise which surround us all.

Actions #22

Updated by Sebastian Herbermann over 13 years ago

+1

Actions #23

Updated by Anonymous over 13 years ago

+1

Actions #24

Updated by Steve Overton over 13 years ago

+1

Actions #25

Updated by Glauber Matos about 13 years ago

+1

Actions #26

Updated by Brendan Abel almost 13 years ago

+1
p.s. Seriously! This bug is over 3 years old! You know, I did need a good reason to learn Ruby...

Actions #27

Updated by Alexis U. almost 13 years ago

+1
One of these long-awaited feature...

Actions #28

Updated by Johannes Schneider almost 13 years ago

+1
I was surprised this feature is not already there. It is very necessary to have the possibility to make fields mandatory/required for us. It is also important that fields can be made invisible for customers. I read in another thread that this also is not possible by now. Please keep these features i track! Thank you

Actions #29

Updated by Seth Sandler over 12 years ago

+1 it should be possible to make fields mandatory, optional or hidden on a per tracker-type basis. What apply to some trackers does not apply to all.

Actions #30

Updated by Terence Mill over 12 years ago

This beavhiour is described in Mightful workflow field enhancement: visible, read only and mandatory > #8050

Seth Sandler wrote:

+1 it should be possible to make fields mandatory, optional or hidden on a per tracker-type basis. What apply to some trackers does not apply to all.

Actions #31

Updated by Etienne Massip over 12 years ago

  • Category changed from Administration to Issues workflow
  • Target version set to Candidate for next major release
Actions #32

Updated by Aidin Abedi over 12 years ago

+1

Actions #33

Updated by Toggi Muppet over 12 years ago

+1

Actions #34

Updated by Nathanael Hansen over 12 years ago

+1

Actions #35

Updated by Shawn Duncan over 12 years ago

+1

Actions #36

Updated by Carlos Serrano over 12 years ago

+1

Actions #37

Updated by Chris Lockwood over 12 years ago

+1

Actions #38

Updated by Ahmed A over 12 years ago

In an organization of 6000 people... this feature is absolutely required.

Excellent, excellent product otherwise.

Actions #39

Updated by Beau Taub over 12 years ago

+1
My organization would benefit from this feature request as well. We've had a number of users ask for it.

Actions #40

Updated by Darren Cook over 12 years ago

+1 (unless you count my customers asking for this, then it's +5)

Actions #41

Updated by Alexandre KOCH over 12 years ago

It's very important for to remove default fields just for one tracker. Is a solution exist ?

Actions #42

Updated by Alexandre KOCH over 12 years ago

It's very important for me to remove default fields just for one tracker. Is a solution exist ?

Actions #43

Updated by Octavian Susnea over 12 years ago

This feature definitely needs to be included in redmine. I've implemented the patch by Jean-Philippe but it didn't add the asterix sign next to the label, here is my updated patch for the Assignee field. I hope it helps:

Index: app/models/issue.rb
===================================================================
-  validates_presence_of :subject, :priority, :project, :tracker, :author, :status
+  validates_presence_of :subject, :priority, :project, :tracker, :author, :status, :assigned_to

Index: app/views/issues/_attributes.rhtml
===================================================================
-  f.select :assigned_to_id, (@issue.assignable_users.collect {|m| [m.name, m.id]}), :include_blank => true
+  f.select :assigned_to_id, (@issue.assignable_users.collect {|m| [m.name, m.id]}), :required => true, :include_blank => true 
Actions #44

Updated by Lucas Castro about 12 years ago

+1

this is something very useful to me

Actions #45

Updated by Gokay Gok about 12 years ago

+1

Actions #46

Updated by Matt Groener about 12 years ago

+1

I'd like this to be configurable per-project as well, if that wasn't clear from other requests. IE:

project-A - fixed_version is required
project-B - fixed_version is optional (the default)
etc.

Actions #47

Updated by Terence Mill about 12 years ago

Your shall check #8050 , which is more detailed how the requirements can be implemented.

Actions #48

Updated by Beau Taub about 12 years ago

Octavian, thanks for the patch, it works for me. Appreciate it.

Octavian Susnea wrote:

This feature definitely needs to be included in redmine. I've implemented the patch by Jean-Philippe but it didn't add the asterix sign next to the label, here is my updated patch for the Assignee field. I hope it helps:

[...]

Actions #49

Updated by Eric Strennen almost 12 years ago

+1
Redmine is a great product, but this feature is very important in my company. Would like to have the following default fields configurable as either visible/enabled based on user role:
-Assignee
-Target version
-Priority

Thanks!

Actions #50

Updated by Terence Mill almost 12 years ago

How could this Plugin get extended to be able to decided between view/hide, readonly, read/write and mandatory.

mandatory fields

{:required => true} 

view/hide

 :disabled  

readonly

??

Which view has to be pacthed to set rules for user defined fields?

Actions #51

Updated by Daniel Santos Bathke almost 12 years ago

+1

Would be very nice to configure the mandatory default fields.

Actions #52

Updated by tasneem maistry over 11 years ago

+1

Actions #53

Updated by Jean-Philippe Lang over 11 years ago

  • File workflow_permissions.png workflow_permissions.png added
  • Subject changed from Configurable required fields to Configurable required fields per tracker/status/role
  • Status changed from New to Closed
  • Target version changed from Candidate for next major release to 2.1.0
  • Resolution set to Fixed

Feature added. You can now configure required fields per tracker, status and role.

A new tab is added to the workflow settings to configure required standard/custom fields. This same form is used to configure read-only fields as well (#3521):

Note that if a user has multiple roles on the same project, only fields required for all its roles are actually required.

Actions #54

Updated by Luis Serrano Aranda over 11 years ago

It's possible add the option Not visible (Required, Read Only and Not visible)

Actions #55

Updated by Aleksandr Voronin over 11 years ago

Luis Serrano Aranda wrote:

It's possible add the option Not visible (Required, Read Only and Not visible)

+1
Some fields for some roles must be hidden.

Actions #56

Updated by Jos Groot Lipman over 11 years ago

Luis Serrano Aranda wrote:

It's possible add the option Not visible (Required, Read Only and Not visible)

Not Visible would be a great (and simple?) addition.

Hiding field for all roles is implemented in #1091 but I really would like to hide some fields (Due date, Time spent) for certain roles only.

Actions #57

Updated by Terence Mill over 11 years ago

This will make the feature complete +1

Actions #58

Updated by # And over 11 years ago

Me too need the feature - hide custom fields per role. But it is must be realized as additional choice - field may be required/readonly and hidden for the clients, for example.

Jean-Philippe Lang, what you think?

Actions #59

Updated by @ go2null over 11 years ago

+1

Actions #60

Updated by David Rahusen over 11 years ago

+1

Actions #61

Updated by Bruno Medeiros over 11 years ago

Guys, this ticket is closed. Why don't you create a new one asking for that?

Actions #62

Updated by David Rahusen over 11 years ago

Bruno Medeiros wrote:

Guys, this ticket is closed. Why don't you create a new one asking for that?

Sorry, recognized the state just after posting... :-(
In future, I will read more intensive the head information, promised! :-)

Actions #63

Updated by Olivier Houdas over 10 years ago

For people who would come to read the previous comment, it had been done with feature request #5037.

Actions #64

Updated by Go MAEDA over 9 years ago

  • Has duplicate Feature #10394: Implement permission "Assign users to issues". added
Actions #65

Updated by noah t about 9 years ago

Jean-Philippe Lang wrote:

Feature added. You can now configure required fields per tracker, status and role.

A new tab is added to the workflow settings to configure required standard/custom fields. This same form is used to configure read-only fields as well (#3521):

Note that if a user has multiple roles on the same project, only fields required for all its roles are actually required.

I am using 2.6-stable branch from Github.

"Required" is not an option for the Subject field.

How can I remove the Subject field, or make it a not required field? Using the above approach my only option is to make it read-only, which is useless.

Actions #66

Updated by Toshi MARUYAMA about 9 years ago

noah t wrote:

I am using 2.6-stable branch from Github.

"Required" is not an option for the Subject field.

How can I remove the Subject field, or make it a not required field? Using the above approach my only option is to make it read-only, which is useless.

Do not add note on closed issue with target version.
Please create new issue if you have feature request.

Actions #67

Updated by Pedro Cainã C Lima almost 9 years ago

I'm using the 2.6.3 version and I'm not getting permit requirement for standard field.
How can I do this?

Actions #68

Updated by Go MAEDA about 7 years ago

  • Related to Feature #4584: Require a Target Version and Category and provide a default version. added
Actions #69

Updated by Go MAEDA about 7 years ago

  • Has duplicate Feature #514: Custom Field on Closing Screen added
Actions #70

Updated by Go MAEDA about 7 years ago

Actions #71

Updated by Go MAEDA almost 6 years ago

Actions

Also available in: Atom PDF