Defect #11942
open
When tracker field and other required fields are read-only, the user can get 'stuck' when creating a new issue
0%
Description
Use case:
1) There are internal defects and defects, so that customer issue queries don't show internal defects.
2) Internal defects are filed and closed by the software team.
3) Defects are filed and closed by the customer.
4) When closing, some information is required by the customer, thus, 'edit issues' permission is required.
5) A customer should NOT create internal defects, so this is disabled by making the subject field read-only (in all states).
6) A customer should NOT turn an existing internal defect into a defect and be able to close it, so the tracker field must also be read-only (in all states).
Now you have a customer who can attempt to file a defect, accidentally choose internal defect, and is now 'stuck' and has to click 'new issue' again.
In other use cases, for example, where software team members can't create regular defects, you can't have regular defects be the first tracker (in order). If you do, a software team member can never create an internal defect. You now have a catch 22. You can't make internal defects first in order, because otherwise the customer can never create a regular defect, and you can't make defects first in order, because otherwise a software team member can never create an internal defect.
Ideally, it should be possible to disable the creation of trackers for roles on a per-project basis. This would avoid the problem altogether in a rather simple and obvious manner. A secondary solution would be to detect when a tracker field and other required fields are set as read-only, and disable the creation of the tracker for that role.
Updated by Brian Lindahl over 11 years ago
A secondary solution would be to detect when a tracker field and other required fields are set as read-only, and disable the creation of the tracker for that role.
Or, in a simple implementation, when the subject field is read-only for the default state, remove the tracker from the drop-down list.
Updated by Brian Lindahl over 11 years ago
Honestly, I wish this had been thought about from the very beginning. The most elegant way would have been to disable any tracker for which there is no status change allowed, and for any edit to require a valid status change (i.e. with old state == new state to indicate editing is allowed in that state). It's a little too late to provide this restriction unless a new project setting is created for backwards compatibility.