MantisBT

View Issue Details Jump to Notes ] Wiki ] Related Changesets ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0009828mantisbtbugtrackerpublic2008-11-17 17:132013-04-06 09:26
Reporterolegos 
Assigned Todhx 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version1.2.0a2 
Target Version1.3.xFixed in Version1.3.x 
Summary0009828: Reopen issue access check is wrong
DescriptionI want to allow any reporter to reopen any issue.
In configuration in Workflow Thresholds, I checked everyone starting with Reporter for "Reopen an issue".
In Configuration Report, reopen_bug_threshold is 25 (Reporter - correct).
Looking at a resolved issue (where I'm not the submitter), I see the "Reopen Issue" button.
But clicking on it, I'm getting "Access Denied" (after the screen where I can add a note).

The problem is that bug_update.php is not checking reopen_bug_threshold. Its checks when a bug is being reopened should mirror the checks for placing the Reopen button.
Tags2.0.x check, patch
Attached Filespatch file icon bug9828.patch [^] (2,462 bytes) 2009-01-14 20:15 [Show Content]

- Relationships
related to 0015721new Functionality to consider porting to master-2.0.x 
has duplicate 0012103closeddhx g_reopen_bug_threshold - config parameter defined but reopen doesn't check it 
related to 0011396resolveddhx difference between closed and resolved 
child of 0012097assigneddhx Tracking issue for the refactoring of bug_update.php 

-  Notes
User avatar (0019929)
vboctor (administrator)
2008-11-18 01:42

I agree that this issue needs to be fixed. This may require revisiting what goes through bug_update.php vs more specific action scripts.
User avatar (0020622)
jreese (administrator)
2009-01-14 18:18

Targetting for future 1.2.x release.
User avatar (0020626)
olegos (reporter)
2009-01-14 20:22
edited on: 2009-01-14 20:30

A patch for fixing this issue is attached. Although it's against not the very latest trunk, it should apply cleanly to the head.

It also fixes a couple of security issues, I think. Looks to me if the user was a reporter, and allow_reporter_reopen was set, any update by the user would be allowed, not just reopening. Same with allow_reporter_close.

The access check for reopen case is adapted from html_button_bug_reopen() in html_api.php (so if changes are made to this part of the patch, html_button_bug_reopen() may need to be updated to match).

User avatar (0022849)
ahutta (reporter)
2009-09-02 09:24

Welcome.
I have the same problem even when attached patch was applied.
After checking bug_api.php I found that user should have permission to assign 'target_version' and 'resolved_in_version'. I think that restricion is not necessary then reporter have permision to reopen the bug.
Resolution for me was to place 'if' rule in bug_update.php:

if ( ON != $f_reopen_flag ) {
   $t_bug_data->fixed_in_version = gpc_get_string( 'fixed_in_version', $t_bug_data->fixed_in_version );
   $t_bug_data->target_version = gpc_get_string( 'target_version', $t_bug_data->target_version );

}
User avatar (0022863)
dhx (developer)
2009-09-04 07:16

ahutta: it is quite plausible for users to be able to reopen bugs, but not have access to change the target_version and fixed_in_version fields. These permissions are independent of each other.
User avatar (0025587)
Renegade (reporter)
2010-05-22 00:02

Since no one seems to work on this issue and it has been bothering me for quite a while, I'm gonna give it a shot in the next few days (if only to get it fixed locally), and try to submit a working patch against the then-latest build.

Right now, I'm mentally accounting for two cases in which a user should be able to reopen a bug:
# when the user meets or exceeds the required $g_reopen_bug_threshold
# when the user is the reporter of the issue, and $g_allow_reporter_reopen is on

...can anybody come up with additional cases in which a user would be allowed to reopen an issue?
User avatar (0025966)
Renegade (reporter)
2010-06-23 09:47

Thank you, dhx...I had given this a shot last month, but I ended up breaking something and got sidetracked with other projects before I could fix it. >_>
User avatar (0036503)
grangeway (developer)
2013-04-05 17:57

Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch

- Related Changesets
MantisBT: master 035a1302
Timestamp: 2010-06-23 00:44:38
Author: dhx
Details ] Diff ]
Refactor bug_update to fix multiple bugs

This is a large change to bug_update.php which refactors the code to
make it clearer and easier to understand. More importantly this
refactoring fixes a number of bugs including the prior ability for
reporters (with allow_reporter_reopen enabled) to make any modifications
to the bug in question even when they didn't have permission to make
those changes.

This refactoring brings about a structural change to the bug update
process. Previously the update checked a field (or number of fields) and
then committed changes to the database before moving on to the next
field. Hence it was possible for some of the requested changes to be
committed to the database before a validation error kicked in,
preventing the remainder of updates from being committed.

The new structure of bug_update prevents partial commits from occurring
as all validation and access checks are done prior to ANY data being
committed to the database. If all the validation checks pass then the
user can be safe in knowing that all changes should be committed to the
database. If any of the validation checks fail, none of the changes have
been committed.

One remaining problem with this approach is the race condition whereby
the administrator updates access checks between the validation of a
field and the attempted committal of a field to the database. As access
checks are performed internally within bug_api (and elsewhere), these
could actually fail during committal (and after the validation steps in
bug_update) if the access levels have changed in the meantime. This is a
problem with requires rewriting much of the MantisBT codebase - all for
a problem that is unlikely to occur and which is of low severity.

Email notifications also need to be sorted out correctly some time in
the future as it is hard to determine what the expected course of action
should be. This update tries sending an email in this order: resolved,
closed, reopened, handler added, status changed, bug updated. Only one
email is sent so if the handler and status of an issue are updated at
once and a user has refused to receive handler notifications, they won't
get any email. This is because we currently give higher priority to
notifying users of the addition of a handler to an issue rather than a
change of status.

Issue 0012097: Refactor bug_update.php
Fixes 0009828: Reopen issue access check is wrong
Fixes 0010226: No email on 'update->assign'
Fixes 0011396: difference between closed and resolved
Fixes 0011804: allow_reporter_reopen lets reporter make any update
mod - bug_update.php Diff ] File ]

- Issue History
Date Modified Username Field Change
2008-11-17 17:13 olegos New Issue
2008-11-18 01:42 vboctor Note Added: 0019929
2008-11-18 01:42 vboctor Status new => acknowledged
2009-01-14 18:18 jreese Note Added: 0020622
2009-01-14 18:18 jreese Target Version => 1.2.2
2009-01-14 20:15 olegos File Added: bug9828.patch
2009-01-14 20:22 olegos Note Added: 0020626
2009-01-14 20:23 olegos Tag Attached: patch
2009-01-14 20:30 olegos Note Edited: 0020626
2009-04-25 10:48 grangeway Status acknowledged => assigned
2009-04-25 10:48 grangeway Assigned To => grangeway
2009-05-04 14:27 siebrand Target Version 1.2.2 => 1.x.x
2009-09-02 09:24 ahutta Note Added: 0022849
2009-09-04 07:16 dhx Note Added: 0022863
2010-01-18 20:55 dhx Relationship added related to 0011396
2010-05-22 00:02 Renegade Note Added: 0025587
2010-06-19 01:02 dhx Relationship added child of 0012097
2010-06-19 01:08 dhx Assigned To grangeway => dhx
2010-06-19 01:08 dhx Target Version 1.3.x => 1.2.2
2010-06-21 08:34 dhx Relationship added has duplicate 0012103
2010-06-22 21:40 dhx Changeset attached => MantisBT master 035a1302
2010-06-22 21:40 dhx Resolution open => fixed
2010-06-22 21:40 dhx Fixed in Version => 1.3.x
2010-06-22 22:50 dhx Target Version 1.2.2 => 1.3.x
2010-06-22 22:50 dhx Status assigned => resolved
2010-06-23 09:47 Renegade Note Added: 0025966
2013-04-05 17:57 grangeway Status resolved => acknowledged
2013-04-05 17:57 grangeway Note Added: 0036503
2013-04-05 18:04 grangeway Relationship added related to 0015721
2013-04-06 03:44 dregad Status acknowledged => resolved
2013-04-06 07:20 grangeway Status resolved => acknowledged
2013-04-06 09:26 dregad Tag Attached: 2.0.x check
2013-04-06 09:26 dregad Status acknowledged => resolved


MantisBT 1.2.16dev master-1.2.x-8c2bd07 [^]
Copyright © 2000 - 2013 MantisBT Team
Time: 0.1288 seconds.
memory usage: 2,897 KB
Powered by Mantis Bugtracker