Redmine

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!

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

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.

+1

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

+10

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

+1

+1

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.

+1

+1

This is crucial feature.

+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.

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.

+1

+1

+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)?

+1

+1

duplicate of #8050

+1

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...

+1

+1

+1