View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0004914 | mantisbt | bugtracker | public | 2004-11-28 20:55 | 2004-12-11 03:01 |
Reporter | packeteer | Assigned To | thraxisp | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 0.19.1 | ||||
Fixed in Version | 0.19.2 | ||||
Summary | 0004914: On reopen, notification mail is sent to the old handler instead of the new handler. | ||||
Description | The bug is the logic of function bug_reopen updates Status, Resolution and Note, but it doesn't update new handler_id. The proper fix should be in the function bug_reopen of ../core/bug_api.php. As I am reluctant to change the core functions, a quick fix can be implemented in bug_update.php instead. The fix is, before calling bug_reopen in bug_update.php, add the line as follows:
I suggest this be fix in ../core/bug_api.php in the next version. | ||||
Tags | No tags attached. | ||||
fixed in CVS |
|
It's not clear whether the fix was made on the core function bug_reopen. Please feedback |
|
The fix was made in bug_update.php, rather than core/bug_api.php. The other functions in bug_api tend to just update the status and email the status change, The possibility of updating the assignee was introduced in 0.19.0 as a side effect of consolidating the changes in status to bug_change_status_page.php. bug_update.php handles most of the mechanics of any change policies. |
|
It's your call at the end of the day where to put the fix in. What we suggest is that new handler_id should be updated in bug_reopen together with Resolution, Status and Note. So that, together these items can be passed onto the mail notification at reopen. |
|
The mail notification refetches the bug data (from cache) when it generates the message. It's really not necessary to pass things like the handler_id to the email routine. |
|