View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0015653||mantisbt||bugtracker||public||2013-03-14 07:48||2016-07-17 07:06|
|Target Version||1.3.0-beta.1||Fixed in Version||1.3.0-beta.1|
|Summary||0015653: APPLICATION ERROR 1303 when trying to reopen an issue|
When I try to reopen an issue that is closed and marked as resolved, I get the following error:
APPLICATION ERROR 1303
I checked the workflow settings, but didn't find anything strange.
|Steps To Reproduce|
The issue is marked as solved and closed.
|Tags||No tags attached.|
|related to||0009828||closed||dhx||Reopen issue access check is wrong|
|related to||0012097||closed||atrol||Tracking issue for the refactoring of bug_update.php|
|related to||0016054||new||Refactoring the notion of "fixed issue"|
|related to||0021306||new||Unable to re-open bug tickets — application error #24|
|child of||0014088||closed||vboctor||Mantis 1.3.0 blocking issues|
Is Oplossing a custom field? If yes then check it's definition, and if you 're still stuck post it here
'Oplossing' is the Dutch translation for 'Resolution'. So it is a standard field.
I was not able to reproduce your problem with a fresh install of the latest stable version of MantisBT (1.2.14 at the moment).
Please provide detailed, step-by-step instructions to reproduce the issue. Additional information listed below may also be useful:
Changes in config_inc.php file:
I added 2 custom fields, both:
I didn't do any specific changes to the source code.
The issue I want to reopen is in a subproject. Don't know if that has something to do with it?
Toeterniettoe, at the moment I recommend to use a stable version of MantisBT (1.2.x) instead of using a non released developer version.
Regression caused by
I had a look at this.
In fact it's quite an easy fix, just need to add an additional condition to the test, so that the error is not triggered if the resolution is REOPENED. However, that got me thinking about the logic behind the order in the resolution enum... Currently we have as defaults:
10:open,20:fixed,30:reopened,40:unable to duplicate,50:not fixable,60:duplicate,70:not a bug,80:suspended,90:wont fix
$g_bug_resolution_fixed_threshold = FIXED; (resolution above that are considered as successfully fixed by developers)
In other words,
I guess this is probably legacy, but IMO would be more logical if FIXED was at the end of the enum:
10:open,20:reopened,30:unable to duplicate,40:not fixable,50:duplicate,60:not a bug,70:suspended,80:wont fix,90:fixed
$g_bug_resolution_not_fixed_threshold = UNABLE_TO_DUPLICATE; (resolutions below that, i.e. open/reopened, are considered "not fixed" by developers, those above
Feels like opening a can of worms, as the implications of attempting to implement this are very far-reaching, both in terms of code and a nightmarish data migration/update. Probably better to leave things alone, and live with this somewhat illogical order I guess.
A solution could be to have no threshold but an array of resolutions which are considered as fixed.
BTW, UNABLE_TO_DUPLICATE ?
Thanks for your feedback
Not sure I'm following you here, can you clarify ?
Can't really deprecate a constant though - I can just remove its definition, then users would get a PHP notice if they refer to it assuming their error levels are set accordingly, or leave it in constant_inc.php (with a comment) for backwards compatibility. What do you think ?
My testing shows that the code checking the changes of resolution has several additional issues, e.g. should not be able to set resolution to reopen unless the old status is >= RESOLVED, so it should be reworked.
Herebelow for future reference is what I think is the expected behavior.
Transition Matrix (Y = valid, ERR = error, - = not applicable/nonexistent)
open/open - Y ERR - ERR Y
If you change the enumeration the way you mentioned (moving "fixed" to the end, changing value from 20 to 90) you have to migrate data
You don't have to migrate any data if you migrate the options
to a new option array which contains all resolutions >= FIXED and < UNABLE_TO_DUPLICATE
The better new default for new installations in config_defaults_inc.php might be
This is the best way to avoid any trouble
Ah yes it makes sense. Good idea actually !
That's kind of refactoring the way we deal with resolutions / fixed issues, so maybe it's a bit beyond the scope of fixing this issue as it involves changing at least 8 pages and api files, not counting the documentation updates.
Commits not picked up by source control - adding manually
MantisBT: master 9ec99686
Damien RegadDetails Diff
|bug_update: better error message for invalid resolution
The error generated when target resolution is not valid as described in
issue 0015653 is not very clear.
We now print a new, improved error message ERROR_INVALID_RESOLUTION,
which includes both the target resolution and status codes.
|mod - bug_update.php||Diff File|
|mod - core/constant_inc.php||Diff File|
|mod - lang/strings_english.txt||Diff File|
MantisBT: master af963574
Damien RegadDetails Diff
|bug_update.php: validation for change in resolution
- Reopening an issue must not cause an error (regression introduced by
- Don't reopened resolution unless old status >= RESOLVED
- fix a few other cases of invalid transitions
|mod - bug_update.php||Diff File|
|2013-03-14 07:48||Toeterniettoe||New Issue|
|2013-03-15 10:03||dregad||Note Added: 0035878|
|2013-03-15 10:03||dregad||Status||new => feedback|
|2013-03-15 12:50||Toeterniettoe||Note Added: 0035883|
|2013-03-15 12:50||Toeterniettoe||Status||feedback => new|
|2013-03-15 14:57||atrol||Note Added: 0035884|
|2013-03-15 14:57||atrol||Status||new => feedback|
|2013-03-15 15:28||Toeterniettoe||Note Added: 0035885|
|2013-03-15 15:28||Toeterniettoe||Status||feedback => new|
|2013-03-15 16:09||atrol||Status||new => confirmed|
|2013-03-15 16:09||atrol||Product Version||=> 1.3.0-beta.1|
|2013-03-15 16:09||atrol||Target Version||=> 1.3.0-beta.1|
|2013-03-15 16:10||atrol||Relationship added||child of 0014088|
|2013-03-15 16:11||atrol||Note Added: 0035886|
|2013-03-15 16:16||atrol||Note Added: 0035887|
|2013-06-12 21:02||dregad||Note Added: 0037173|
|2013-06-13 04:33||atrol||Note Added: 0037175|
|2013-06-13 04:34||atrol||Note Edited: 0037175||View Revisions|
|2013-06-13 05:39||dregad||Note Added: 0037177|
|2013-06-13 06:14||dregad||Note Added: 0037180|
|2013-06-13 06:14||dregad||Assigned To||=> dregad|
|2013-06-13 06:14||dregad||Status||confirmed => assigned|
|2013-06-13 06:27||dregad||Relationship added||related to 0009828|
|2013-06-13 06:29||dregad||Relationship added||related to 0012097|
|2013-06-13 07:49||dregad||Summary||Reopen issue APPLICATION ERROR 0001303 => APPLICATION ERROR 1303 when trying to reopen an issue|
|2013-06-13 07:49||dregad||Description Updated||View Revisions|
|2013-06-13 07:49||dregad||Steps to Reproduce Updated||View Revisions|
|2013-06-13 08:53||atrol||Note Added: 0037182|
|2013-06-13 12:20||dregad||Note Added: 0037184|
|2013-06-13 12:33||dregad||Relationship added||related to 0016054|
|2013-10-17 00:28||vboctor||Product Version||1.3.0-beta.1 => 1.2.14|
|2013-10-17 04:01||dregad||Note Added: 0038285|
|2013-10-17 04:01||dregad||Status||assigned => resolved|
|2013-10-17 04:01||dregad||Fixed in Version||=> 1.3.0-beta.1|
|2013-10-17 04:01||dregad||Resolution||open => fixed|
|2013-10-17 04:01||dregad||Changeset attached||=> MantisBT master af963574|
|2013-10-17 04:02||dregad||Changeset attached||=> MantisBT master 9ec99686|
|2014-12-08 00:34||vboctor||Status||resolved => closed|
|2016-07-17 07:06||atrol||Relationship added||related to 0021306|