View Issue Details

IDProjectCategoryView StatusLast Update
0015653mantisbtbugtrackerpublic2016-07-17 07:06
ReporterToeterniettoe Assigned Todregad  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version1.2.14 
Target Version1.3.0-beta.1Fixed in Version1.3.0-beta.1 
Summary0015653: 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
Invalid value for field "Oplossing".

I checked the workflow settings, but didn't find anything strange.

Steps To Reproduce

The issue is marked as solved and closed.
I try to reopen the issue with the reopen button. I can add feedback, but then I get the error.
I also get the error when changing status and resolution manually.

TagsNo tags attached.

Relationships

related to 0009828 closeddhx Reopen issue access check is wrong 
related to 0012097 closedatrol 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 closedvboctor Mantis 1.3.0 blocking issues 

Activities

dregad

dregad

2013-03-15 10:03

developer   ~0035878

Is Oplossing a custom field? If yes then check it's definition, and if you 're still stuck post it here

Toeterniettoe

Toeterniettoe

2013-03-15 12:50

reporter   ~0035883

'Oplossing' is the Dutch translation for 'Resolution'. So it is a standard field.
There are no custom fields (filled in) in this issue.

atrol

atrol

2013-03-15 14:57

developer   ~0035884

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:

  • Exact version of MantisBT, PHP, Database, Web server and Operating System
  • Relevant customizations (e.g. changes in config_inc.php, etc)
  • Installed plugins or custom functions ?
  • Was the MantisBT source code modified in any way ?
Toeterniettoe

Toeterniettoe

2013-03-15 15:28

reporter   ~0035885

MantisBT-version: 1.3.0devmaster-540ae47
PHP: 5.3.19
Database: MySQL 5.5.28-cll
Server: Linux - Apache 2.0 (20051115)

Changes in config_inc.php file:
$g_time_tracking_enabled = ON;
$g_time_tracking_stopwatch = ON;
$g_use_javascript = ON;
$g_show_version = ON;
$g_crypto_master_salt = '[KEY]';

Installed plugins:
Mantis Graphs 1.0
MantisBT Formatting 1.0a

I added 2 custom fields, both:
Type: String
Add to filter
Display when reporting, updating, resolving and closing
Not required for any of the above
Linked to all projects and subprojects.

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?

atrol

atrol

2013-03-15 16:11

developer   ~0035886

Toeterniettoe, at the moment I recommend to use a stable version of MantisBT (1.2.x) instead of using a non released developer version.

atrol

atrol

2013-03-15 16:16

developer   ~0035887

Regression caused by
https://github.com/mantisbt/mantisbt/commit/035a1302792ada9ba36ed1d729542ea629de8cca

dregad

dregad

2013-06-12 21:02

developer   ~0037173

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)
$g_bug_resolution_not_fixed_threshold = UNABLE_TO_DUPLICATE; (resolutions below that are considered "not fixed" by developers)

In other words,

  • FIXED and REOPENED are both >= FIXED and < UNABLE_TO_DUPLICATE, so they are both fixed and not fixed at the same time (!)
  • all resolutions > FIXED are considered successfully fixed (including things such as won't fix, not a bug, etc which are clearly not fixed)

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
$g_bug_resolution_fixed_threshold = FIXED; (resolution >= that are considered as successfully fixed by developers)

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.

atrol

atrol

2013-06-13 04:33

developer   ~0037175

Last edited: 2013-06-13 04:34

A solution could be to have no threshold but an array of resolutions which are considered as fixed.
There is no migration of data needed but a migration of the two old settings to the new one.

BTW, UNABLE_TO_DUPLICATE ?
Quite confusing, instead we should introduce UNABLE_TO_REPRODUCE and deprecate UNABLE_TO_DUPLICATE

dregad

dregad

2013-06-13 05:39

developer   ~0037177

Thanks for your feedback

There is no migration of data needed but a migration of the two old settings to the new one.

Not sure I'm following you here, can you clarify ?

Quite confusing, instead we should introduce UNABLE_TO_REPRODUCE and deprecate UNABLE_TO_DUPLICATE

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 ?

dregad

dregad

2013-06-13 06:14

developer   ~0037180

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>
o/o o/r o/f r/o r/r r/f


open/open - Y ERR - ERR Y
open/reopen Y - ERR ERR - Y
open/fixed - - - - - -
resolved/open - - - - - -
resolved/reopen - - - - - -
resolved/fixed Y Y - ERR ERR -
</pre>
Test cases based on the above matrix, assuming no workflow restrictions, test issue initial state is new/open
http://localhost/mantis/bug_update.php?bug_id=1&amp;status=10&amp;resolution=10

  1. to feedback/fixed http://localhost/mantis/bug_update.php?bug_id=1&amp;status=20&amp;resolution=20 nok
  2. to resolved/reopen http://localhost/mantis/bug_update.php?bug_id=1&amp;status=80&amp;resolution=30 nok
  3. to resolved/fixed http://localhost/mantis/bug_update.php?bug_id=1&amp;status=80&amp;resolution=20 ok
  4. to resolved/open http://localhost/mantis/bug_update.php?bug_id=1&amp;status=80&amp;resolution=10 nok
  5. to resolved/reopen http://localhost/mantis/bug_update.php?bug_id=1&amp;status=80&amp;resolution=30 nok
  6. to feedback/reopen http://localhost/mantis/bug_update.php?bug_id=1&amp;status=20&amp;resolution=30 ok
  7. to feedback/fixed http://localhost/mantis/bug_update.php?bug_id=1&amp;status=20&amp;resolution=20 nok
  8. to resolved/open http://localhost/mantis/bug_update.php?bug_id=1&amp;status=80&amp;resolution=10 nok
  9. to assigned/open http://localhost/mantis/bug_update.php?bug_id=1&amp;status=50&amp;resolution=30 ok
  10. to resolved/fixed http://localhost/mantis/bug_update.php?bug_id=1&amp;status=80&amp;resolution=20 ok (already tested)
  11. to assigned/open http://localhost/mantis/bug_update.php?bug_id=1&amp;status=50&amp;resolution=30 ok
  12. to feedback/reopen http://localhost/mantis/bug_update.php?bug_id=1&amp;status=20&amp;resolution=30 ok
  13. to resolved/fixed http://localhost/mantis/bug_update.php?bug_id=1&amp;status=80&amp;resolution=20 ok (already tested)
  14. to feedback/reopen http://localhost/mantis/bug_update.php?bug_id=1&amp;status=20&amp;resolution=30 ok (already tested)
  15. to resolved/fixed http://localhost/mantis/bug_update.php?bug_id=1&amp;status=80&amp;resolution=20 ok
atrol

atrol

2013-06-13 08:53

developer   ~0037182

Not sure I'm following you here, can you clarify ?

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
(e.g. resolution in mantis_bug_table, entries in mantis_history_table)

You don't have to migrate any data if you migrate the options
$g_bug_resolution_not_fixed_threshold = UNABLE_TO_DUPLICATE;
$g_bug_resolution_fixed_threshold = FIXED;

to a new option array which contains all resolutions >= FIXED and < UNABLE_TO_DUPLICATE
$g_bug_resolutions_fixed = array(FIXED, REOPENED, UNABLE_TO_DUPLICATE)

The better new default for new installations in config_defaults_inc.php might be
$g_bug_resolutions_fixed = array(FIXED, UNABLE_TO_REPRODUCE, NOT_A_BUG)

leave it in constant_inc.php (with a comment) for backwards compatibility. What do you think ?

This is the best way to avoid any trouble

dregad

dregad

2013-06-13 12:20

developer   ~0037184

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.

dregad

dregad

2013-10-17 04:01

developer   ~0038285

Commits not picked up by source control - adding manually

Related Changesets

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