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 |
Reporter | Toeterniettoe | Assigned To | dregad | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.2.14 | ||||
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 | ||||
Description | 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. |
|
Toeterniettoe, 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:
|
|
MantisBT-version: 1.3.0devmaster-540ae47 Changes in config_inc.php file: Installed plugins: 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 ?
Agreed. 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) <pre> 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 2013-06-12 23:03 Damien Regad Details 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. |
Affected Issues 0015653 |
|
mod - bug_update.php | Diff File | ||
mod - core/constant_inc.php | Diff File | ||
mod - lang/strings_english.txt | Diff File | ||
MantisBT: master af963574 2013-06-13 03:13 Damien Regad Details Diff |
bug_update.php: validation for change in resolution - Reopening an issue must not cause an error (regression introduced by 035a1302792ada9ba36ed1d729542ea629de8cca) - Don't reopened resolution unless old status >= RESOLVED - fix a few other cases of invalid transitions Fixes 0015653 |
Affected Issues 0015653 |
|
mod - bug_update.php | Diff File |