View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006604||mantisbt||feature||public||2006-01-18 21:44||2016-02-11 04:18|
|Summary||0006604: Update form allows for modifying issue to a non-sensical state|
I am curious about the intent of the Update form presented by either bug_update_page.php or bug_update_advanced_page.php...
The form allows the user to alter both the issue Status and the Resolution independently. This would seem to allow some entertaining combinations, such as
Perhaps it would be best just not to show the Resolution field unless the issue was already in a resolved state. One could also prevent modifying issue state except through the selection box available on the Viewing page.
|Tags||No tags attached.|
I've had a quick look and it seems this bug is still valid.
In fact, the solution seems a little more involved than the original poster implied. Ignoring for the moment any possible custom fields, it is possible to have any combination of "Status", "Resolution" and "Fixed in Version". i.e. you can have Status=new, Resolution=wontfix and Fixed_in_Version=1.0.
Really, it shouldn't be possible to set a resolution (to anything except 'open') unless Status=Resolved or Closed. Then, it shouldn't be possible to set 'Fixed in Version' to anything unless Resolution=fixed(or maybe duplicate/no_change_required).
From what I can tell, these three fields are the only ones where nonsensical combinations can be set.
We can't really add that level of customization to MantisBT as it becomes far too complex. It is something that needs to be written in code as there is no easier method than using a bunch of 'if' statements.
What you'd need to do is write a custom plugin that performs your own validation routines on BUG_UPDATE (and likely other events too, some of which don't exist yet). You could then prevent the bug from updating with an error message of your choice whenever the logic in your plugin decides that an invalid combination of fields have been requested.
The problem of preventing the user from seeing invalid field options on bug_update_page (and other UI screens) is somewhat more complicated. It's something that I would love to see but it most likely requires a rewrite of the field and custom field functionality of MantisBT. Effectively with a rewrite we could fire a plugin event whenever a field is about to be outputted to the user. Your plugin could then remove invalid options from the list before they're shown to the user.
Also, it has been observed (v.1.2.19) that, if you have an open issue and you close it directly (without passing by the status 'Resolved'), the email notification is sending a wrong 'Resolution' value (even if the resolution update is made correctly in the database), showing always the 'Open' value in the email. This has been observed through the "Close" button and also the "Change state" select of an issue.
However, if you resolve the issue, and then you close it, the email notification sends the correct 'Resolution' value.
|2006-01-18 21:44||mlovell||New Issue|
|2009-03-31 07:55||milliams||Note Added: 0021332|
|2010-06-19 01:19||dhx||Note Added: 0025920|
|2010-06-19 01:20||dhx||Status||new => acknowledged|
|2010-06-19 01:20||dhx||Target Version||=> 1.3.0-beta.1|
|2014-01-21 16:08||atrol||Target Version||1.3.0-beta.1 =>|
|2016-02-11 04:08||aluque.icca||Note Added: 0052512|