| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0012097 | mantisbt | bugtracker | public | 2010-06-19 00:56 | 2014-08-05 16:36 |
| Reporter | dhx | Assigned To | atrol | ||
| Priority | high | Severity | minor | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Product Version | 1.2.2 | ||||
| Summary | 0012097: Tracking issue for the refactoring of bug_update.php | ||||
| Description | This issue tracks the issues surrounding the refactoring of bug_update.php. The major aims of the refactoring are to:
| ||||
| Tags | No tags attached. | ||||
| parent of | 0011804 | closed | dhx | allow_reporter_reopen lets reporter make any update, not just reopen |
| parent of | 0011967 | closed | dhx | Problems with EVENT_UPDATE_BUG |
| parent of | 0009828 | closed | dhx | Reopen issue access check is wrong |
| parent of | 0011396 | closed | dhx | difference between closed and resolved |
| parent of | 0010226 | closed | dhx | No email on 'update->assign' |
| parent of | 0012215 | closed | dregad | Write to target_version field may fail due to unhandled access check |
| parent of | 0011758 | closed | dhx | Adding a bug note should not change the status of the issue |
| parent of | 0012205 | closed | dhx | Do not leave feedback status when the handler adds a note |
| parent of | 0012489 | closed | daryn | resolution is not updated on re-open |
| related to | 0014443 | closed | dregad | Status changed to resolved and not to the desired value |
| related to | 0015653 | closed | dregad | APPLICATION ERROR 1303 when trying to reopen an issue |
 |
Is there a regression here in bug_update.php from issue 0010647? |
 |
Removed assignment. dhx will not contribute to this issue in near future. |
 |
Changing issue to minor since it is mainly around code cleanup. Also cleared out the target version. |
|
|
Closed the issue. All related issues are resolved or closed. |
|
MantisBT: master 035a1302 2010-06-22 20:44 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 | ||
|
MantisBT: master 373d998a 2010-06-22 22:53 Details Diff |
Issue 0012097: Remove usage of update_mode parameter bug_update.php no longer relies upon a hidden update_mode parameter and therefore this parameter can be removed from other parts of the MantisBT codebase. |
Affected Issues 0012097 |
|
| mod - bug_update_advanced_page.php | Diff File | ||
