View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0017925 | mantisbt | public | 2014-11-26 14:28 | 2015-01-25 18:17 | |
Reporter | vboctor | Assigned To | dregad | ||
Priority | high | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Product Version | 1.2.18 | ||||
Target Version | 1.2.19 | Fixed in Version | 1.2.19 | ||
Summary | 0017925: Order of notes in email notifications seem to be based on user who triggered the action | ||||
Description | Rather than the order of the emails being dependent on the preference of the user that the email is being generated for, it is being dependent on the user who triggered the action. I noticed this behavior in email notifications generated for 0017811 by the reporter and @dregad. | ||||
Tags | No tags attached. | ||||
Same problem for 1.2.18. Please fix this ASAP. Users get notes in the alerts in the unpredictable order - this is irritating. I have to switch back to 1.2.17 until this is addressed. |
|
Changing product version/target and priority based on feedback from @aavagyan |
|
This is a regression caused by fix for 0009885. According to git bisect: 76a1d203b94a94b1b55ca09fb99bab942db53a0a is the first bad commit Corresponding commit in master branch is 0f030fd725b8139aa39e47365fe3433a2f12dda8 |
|
I believe the issue is caused by user_pref_get_pref() which relies on a cache for the current user's preferences. Since we change the current user without clearing the cache, the function returns the wrong result. Solution 1 (quick workaround): clear the cache, either directly in email_build_visible_bug_data() as we change the current user, or more elegantly by defining a new API to sets the global variable and clear the cache at the same time. Solution 2 (probably better in the long run, but more complex): get rid of $g_cache_current_user_pref and refactor $g_cache_user_pref to store UserPreferences objects instead of DB rows. |
|
Thank you for solving the problem. Do you plan to make patch or one should wait for the next release? |
|
The patch is attached to this issue (see Changesets below). Feel free to apply it locally. |
|
Sorry, I don't see patch attached. I see only change-sets... |
|
The changeset is the patch (click on [diff] link) |
|
Sorry for newbie question. I also learned that appending ".patch" to GitHub commit URL does some magic. Yes, the patch is fixing the problem. Thank you Damian! |
|
Pardon, Damien. :-) |
|
No problem :-) |
|
MantisBT: master-1.2.x 559ba4e4 2014-12-09 06:23 Details Diff |
New API current_user_set() The function sets the $g_cache_current_user_id global variable, and clears the user preferences cache ($g_cache_current_user_pref) if necessary. Using this new API to set the current user as opposed to working with $g_cache_current_user_id makes sure we always get the correct data from get_user_pref(). Resolves an issue where the order (as well as the number) of bugnotes in email notifications is based on the user who triggered the action, instead of the email's recipient. Fixes 0017925 |
Affected Issues 0017925 |
|
mod - core/authentication_api.php | Diff File | ||
mod - core/current_user_api.php | Diff File | ||
mod - core/email_api.php | Diff File | ||
MantisBT: master 257c1fe1 2014-12-09 06:23 Details Diff |
New API current_user_set() The function sets the $g_cache_current_user_id global variable, and clears the user preferences cache ($g_cache_current_user_pref) if necessary. Using this new API to set the current user as opposed to working with $g_cache_current_user_id makes sure we always get the correct data from get_user_pref(). Resolves an issue where the order (as well as the number) of bugnotes in email notifications is based on the user who triggered the action, instead of the email's recipient. Fixes 0017925 (porting 559ba4e43a2dc6c9f8fd6491f6279379734ac549) |
Affected Issues 0017925 |
|
mod - core/authentication_api.php | Diff File | ||
mod - core/current_user_api.php | Diff File | ||
mod - core/email_api.php | Diff File |