View Issue Details

IDProjectCategoryView StatusLast Update
0011396mantisbtfeaturepublic2014-12-08 00:34
Reporterjl88 Assigned Todhx  
PriorityhighSeverityfeatureReproducibilityN/A
Status closedResolutionfixed 
Product Version1.1.8 
Target Version1.3.0-beta.1Fixed in Version1.3.0-beta.1 
Summary0011396: difference between closed and resolved
Description

At the moment there is no difference between a closed and a resolved Issue.
It would be a nice feature to allow a reporter only to reopen a Issue when the Issue is resolved. When the Issue is closed then the Reporter should do not open the Issue only a Manager.

http://www.mantisbt.org/forums/viewtopic.php?f=3&t=9708

Tagsresolved

Relationships

related to 0009828 closeddhx Reopen issue access check is wrong 
related to 0015721 closedgrangeway Functionality to consider porting to master-2.0.x 
child of 0012097 closedatrol Tracking issue for the refactoring of bug_update.php 

Activities

grangeway

grangeway

2013-04-05 17:57

reporter   ~0036506

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

Related Changesets

MantisBT: master 035a1302

2010-06-22 20:44

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
Affected Issues
0009828, 0010226, 0011396, 0011782, 0011804, 0012097
mod - bug_update.php Diff File