Hi,
I would like to make the "assign to" field mandatory. I've looked around and did not find any specific solution (yet), but the general sense I got is that it is possible only by replacing code or writing custom validation functions. Is my conclusion correct? If that is the case, what should I look at?
Cheers,
DB
Making a field mandatory
Moderators: Developer, Contributor
Re: Making a field mandatory
Writing a custom validation function custom_function_override_issue_create_validate could be used for this
http://docs.mantisbt.org/master/en/admi ... USTOMFUNCS
Or using the new plugin system since version 1.2 is an option
http://docs.mantisbt.org/master/en/deve ... ENTREF.BUG
Could you describe the scenario where you need this?
I am wondering, because I don't think that reporters can always choose a good handler for an issue.
Maybe using categories with automatically assigned users is also an option for you?
http://docs.mantisbt.org/master/en/admi ... USTOMFUNCS
Or using the new plugin system since version 1.2 is an option
http://docs.mantisbt.org/master/en/deve ... ENTREF.BUG
Could you describe the scenario where you need this?
I am wondering, because I don't think that reporters can always choose a good handler for an issue.
Maybe using categories with automatically assigned users is also an option for you?
Re: Making a field mandatory
Hi atrol,
First of all one of the first things you pick up when you leave the code and start managing people (ok let's face it, you never really leave the code...), is that a task that no one is responsible for often gets neglected. I assume from your remark that Mantis has some native way to care for unassigned issues!?
Secondly, the type of projects I have worked on usually involved multiple teams and areas of responsibility. Actually our current situation is even simpler than that but still, it has always been our common practice to assign an item to the person best suited to care for it. This is usually the developer. If we are talking about a bug I expect the reporter (testing team member in most cases), to either know who should get it (client, server etc), or to consult with the developers and decide regarding it. If this is an item that requires 'triage' than most likely a team lead would get it and decide who it belongs to.
If we are talking methodology, you also might be interested in the fact that I cancelled the 'new', 'acknowledged' and 'confirmed' statuses in order to not over-complicate the workflow. On the other hand I added a 'completed' status before resolved. An issue starts as assigned to someone. Mantis item reviews are performed weekly, bi-weekly or even daily depending on the current status and type of the project. So I can hear from the responsible developer or junior (or senior) manager the status of each (drilling down to the resolution of my liking). Of course an item can become 'feedback' and back to 'assigned' multiple times. Once an item is done it is marked as completed. When a new build is sent to testing the responsible party be it developers, team leads or whomever, review the issues and change each completed that went into that build to 'resolved'. Testers will only review resolved issues and can either close or re-assign them.
Regarding using categories with auto-assigning users. That's actually a very good idea that I need to consider.
Cheers,
DB
First of all one of the first things you pick up when you leave the code and start managing people (ok let's face it, you never really leave the code...), is that a task that no one is responsible for often gets neglected. I assume from your remark that Mantis has some native way to care for unassigned issues!?
Secondly, the type of projects I have worked on usually involved multiple teams and areas of responsibility. Actually our current situation is even simpler than that but still, it has always been our common practice to assign an item to the person best suited to care for it. This is usually the developer. If we are talking about a bug I expect the reporter (testing team member in most cases), to either know who should get it (client, server etc), or to consult with the developers and decide regarding it. If this is an item that requires 'triage' than most likely a team lead would get it and decide who it belongs to.
If we are talking methodology, you also might be interested in the fact that I cancelled the 'new', 'acknowledged' and 'confirmed' statuses in order to not over-complicate the workflow. On the other hand I added a 'completed' status before resolved. An issue starts as assigned to someone. Mantis item reviews are performed weekly, bi-weekly or even daily depending on the current status and type of the project. So I can hear from the responsible developer or junior (or senior) manager the status of each (drilling down to the resolution of my liking). Of course an item can become 'feedback' and back to 'assigned' multiple times. Once an item is done it is marked as completed. When a new build is sent to testing the responsible party be it developers, team leads or whomever, review the issues and change each completed that went into that build to 'resolved'. Testers will only review resolved issues and can either close or re-assign them.
Regarding using categories with auto-assigning users. That's actually a very good idea that I need to consider.
Cheers,
DB
Re: Making a field mandatory
Thanks for giving feedback
There are also at least two plugins of community members which are also interesting.
If you use due date feature of MantisBT
http://git.mantisforge.org/w/Reminder.git
If you have to guarantee a certain service level
http://git.mantisforge.org/w/ServiceLevel.git
Until now, I didn't use them in my projects, so I can't say anything about the quality of these plugins
When using categories with auto-assigning users, there will be no unassigned issues.devboy wrote:I assume from your remark that Mantis has some native way to care for unassigned issues!?
There are also at least two plugins of community members which are also interesting.
If you use due date feature of MantisBT
http://git.mantisforge.org/w/Reminder.git
If you have to guarantee a certain service level
http://git.mantisforge.org/w/ServiceLevel.git
Until now, I didn't use them in my projects, so I can't say anything about the quality of these plugins