View Issue Details

IDProjectCategoryView StatusLast Update
0006604mantisbtfeaturepublic2016-02-11 04:18
Reportermlovell Assigned To 
PrioritynormalSeveritytrivialReproducibilityalways
Status acknowledgedResolutionopen 
Product Version1.0.0rc5 
Summary0006604: Update form allows for modifying issue to a non-sensical state
Description

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
(Closed, Open).

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.

TagsNo tags attached.

Activities

milliams

milliams

2009-03-31 07:55

reporter   ~0021332

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

To enforce this requires two things I think. Firstly (from the user's point of view) a bit of JavaScript on bugupdate[advanced_]page.php to grey out the boxes that shouldn't be editable and to enable them when the status/resolution boxes are on appropriate values. Secondly is something in the API to prevent nonsensical combinations being put into the database. Perhaps just one of these would be enough, simply to improve the current situation - the JavaScript solution would be easiest and cleanest to implement I think.

From what I can tell, these three fields are the only ones where nonsensical combinations can be set.

dhx

dhx

2010-06-19 01:19

reporter   ~0025920

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.

aluque.icca

aluque.icca

2016-02-11 04:08

reporter   ~0052512

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.