Project

General

Profile

Actions

Feature #582

closed

Make fields mandatory/unmandatory based on role

Added by Daniel Jones about 16 years ago. Updated over 11 years ago.

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

0%

Estimated time:
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

Is duplicate of Redmine - Feature #703: Configurable required fields per tracker/status/roleClosedJean-Philippe Lang2008-02-21

Actions
Actions #1

Updated by Milton Taylor about 16 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!

Actions #2

Updated by Moo Jix about 15 years ago

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

Actions #3

Updated by Marco Gigante almost 15 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.

Actions #4

Updated by Nicklas Holm almost 15 years ago

+1

Actions #5

Updated by Axel dV almost 15 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

Actions #6

Updated by Nanda P about 14 years ago

+10

Actions #7

Updated by Alain V. about 14 years ago

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

Actions #8

Updated by Andrea Lona about 14 years ago

+1

Actions #9

Updated by Anton Statutov almost 14 years ago

+1

Actions #10

Updated by Bryce Ellis almost 14 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.

Actions #11

Updated by Frank Maker almost 14 years ago

+1

Actions #12

Updated by Ajax Dyn about 13 years ago

+1

This is crucial feature.

Actions #13

Updated by Hans Bangkok almost 13 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.

Actions #14

Updated by Bryce Ellis almost 13 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.

Actions #16

Updated by Etienne Massip over 12 years ago

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

Updated by Anonymous over 12 years ago

+1

Actions #18

Updated by André Bachmann over 12 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)?

Actions #19

Updated by Andrea Saccavini over 12 years ago

+1

Actions #20

Updated by pasquale [:dedalus] over 12 years ago

+1

Actions #21

Updated by Terence Mill over 12 years ago

duplicate of #8050

Actions #22

Updated by Etienne Massip over 12 years ago

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

Updated by Gokay Gok about 12 years ago

+1

Actions #24

Updated by Radek Antoniuk about 12 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...

Actions #25

Updated by Bernard Steens about 12 years ago

+1

Actions #26

Updated by Adrien Delcourt almost 12 years ago

+1

Actions #27

Updated by Anders Wallin almost 12 years ago

+1

Actions #28

Updated by Jean-Philippe Lang over 11 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.

Actions

Also available in: Atom PDF