Feature #582

Make fields mandatory/unmandatory based on role

Added by Daniel Jones almost 10 years ago. Updated over 5 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:Jean-Philippe Lang% Done:

0%

Category:Issues workflow
Target version:-
Resolution:Duplicate

Description

I would like to have the ability to make a standard field mandatory/required or unmandatory/not required based on the
role. For example "Category" is not currently showing up as mandatory, but I would like to make it so for
Manager. This would allow the reporter to report a bug without giving it a specific category, but the manager would
have to go in and give it a category when he/she does assigns the bug.


Related issues

Duplicates Redmine - Feature #703: Configurable required fields per tracker/status/role Closed 2008-02-21

History

#1 Updated by Milton Taylor almost 10 years ago

I second this request:

But I think category should be mandatory based on project, not
based on role.

It's too easy for new issues to be created by a customer, and
leaves assignee and category blank. Therefore nobody picks it
up to deal with it because it's not in anyone's in-tray!

#2 Updated by Moo Jix almost 9 years ago

this feature "Setting category mandatory for specific projects" would be helpful.

#3 Updated by Marco Gigante over 8 years ago

Daniel Jones wrote:

I would like to have the ability to make a standard field mandatory/required or unmandatory/not required based on the
role. For example "Category" is not currently showing up as mandatory, but I would like to make it so for
Manager. This would allow the reporter to report a bug without giving it a specific category, but the manager would
have to go in and give it a category when he/she does assigns the bug.

It would be useful to have fields mandatory or not depending upon issue status as well.
This is useful especially when custom fields and custom Status get involved (not only standard ones).

For example, in a scenario like the follow.

Status can be: New, Assigned, Resolved, Integrated, Closed, Rejected
Branch as custom field.

where
Resolved means that developer has resolved the issue on its own development branch, but not merged the code into main branch.
Integrated means integration team has merged new code into main branch (e.g. trunk).

The Branch field has little sense when issue is New or Assigned, so it is optional; while it has to be filled up when issue gets moved to Resolved (and to Integrated afterward).

I think some kind of mandatory matrix would be very useful into "Issue statuses" administration section, similar to "Workflow" matrix.

#4 Updated by Nicklas Holm over 8 years ago

+1

#5 Updated by Axel dV over 8 years ago

I totally agree, that is very important. Especially because you cannot set a project manager per project in Redmine.
For instance, I have 3 projects:
- Dev
- Design
- Admin
Tasks should be automatically affected (the best would be on a group like the "Dev group") to a developer or a designer ... The workaround is to use Categories as you can define one (only one, pity) responsible.
But as this field is not mandatory....

Cheers

#6 Updated by Nanda P almost 8 years ago

+10

#7 Updated by Alain V. almost 8 years ago

I also have this need in our company.
This feature would be useful. Thank you

#8 Updated by Andrea Lona almost 8 years ago

+1

#9 Updated by Anton Statutov over 7 years ago

+1

#10 Updated by Bryce Ellis over 7 years ago

I would also like to see this one resolved. It could end up being a very complex issue to resolve. Really I think this is tied to the workflow. If you could specify the mandatory fields under each of the workflow transitions I think that would be best. For example when you move from "new" to "assigned" you could elect to add "assigned to" and "target version" as mandatory fields for this action. With this method it would be up to the Project Manager to decide what and when fields might be mandatory along the workflow. The additional beauty of this is it would automatically tie to the actions allowed by a user through the workflow.

#11 Updated by Frank Maker over 7 years ago

+1

#12 Updated by Ajax Dyn almost 7 years ago

+1

This is crucial feature.

#13 Updated by Hans Bangkok over 6 years ago

+1

Althought I really like the flexibility of Bryce's ideas, they do make implementation more difficult, to the point that I'd say the whole role/status/workflow UI's being upgraded first or as part of this would be a good (but even bigger) goal.

In the meantime, how about a simple line of checkboxes as to which fields should be mandatory in all situations on a per-project basis? That would at least be a manageable step in the right direction. . .

For example, category and version are critical in the use-case I'm currently implementing, we're actually building reports for managers to use to identify which issues don't have the (organizationally) required fields filled in.

#14 Updated by Bryce Ellis over 6 years ago

Agree that my approach would extend the capabilities and complicate the resolution. I would agree that the update originally proposed and restated by Hans would be a significant step forward.

#16 Updated by Etienne Massip over 6 years ago

  • Category set to Issues workflow
  • Target version set to Candidate for next major release

#17 Updated by Artur Pirozhkov over 6 years ago

+1

#18 Updated by André Bachmann over 6 years ago

+1

This is a nice to have feature. Well I think setting the field "category" as mandatory by editing some of Redmine's .rb files shouldn't be that hard. So what is the right place to look for this (until the next major release is out)?

#19 Updated by Andrea Saccavini over 6 years ago

+1

#21 Updated by Terence Mill over 6 years ago

duplicate of #8050

#22 Updated by Etienne Massip about 6 years ago

  • Subject changed from Make fields mandatory/unmandatory to Make fields mandatory/unmandatory based on role

#23 Updated by Gokay Gok almost 6 years ago

+1

#24 Updated by warden (warden) almost 6 years ago

Guys, I know that you have little development time but...
Please at least set sensible "expected" version or dates ... or merge... or do anything. For now there are already 3+ tickets for this that had been assigned, re-assigned, dis-assigned and so on...

#25 Updated by Bernard Steens almost 6 years ago

+1

#26 Updated by Adrien Delcourt over 5 years ago

+1

#27 Updated by Anders Wallin over 5 years ago

+1

#28 Updated by Jean-Philippe Lang over 5 years ago

  • Status changed from New to Closed
  • Assignee set to Jean-Philippe Lang
  • Target version deleted (Candidate for next major release)
  • Resolution set to Duplicate

Same as #703, implemented for 2.1.0.

Also available in: Atom PDF