Closed (fixed)
Project:
Password Policy
Version:
6.x-1.0-alpha2
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Reporter:
Created:
15 Oct 2009 at 18:34 UTC
Updated:
30 Apr 2010 at 04:10 UTC
Jump to comment: Most recent file
Comments
Comment #1
tomho commentedComment #2
tomho commentedHas anyone looked at this?
Seems like a really critical bug if it is triggering wrong emails.
Comment #3
tacituseu commentedConfirmed, happens only when unblocked from /user/%/edit, doesn't when done via /admin/user/expired or bulk operations, the culprit is call to
_password_policy_unblock()from op inhook_user(), which is redundant since in D6 there is following code inuser_save():Attached patch fixes that, also changed
_password_policy_unblock()for consistency.Comment #4
tacituseu commentedForgot to check status.
Comment #5
bjcool commentedsubscribe
Comment #6
afreeman commentedRerolled to work with latest dev release, backed out change that removed password reset mail code from _password_policy_unblock()
Comment #7
tacituseu commentedYou can't have both
user_save($account, array('status' => 1));and password reset mail code in _password_policy_unblock() as it would recreate this problem at /admin/user/expired.Comment #8
deekayen commentedWell I just committed #6, so please submit a fixed patch on what's in HEAD now.
Comment #9
tacituseu commentedWould like to know what was the reasoning behind afreeman's change first, was #4 causing any problems ?
Comment #10
afreeman commentedImperfect understanding of what these mails represented and when they're typically sent. I get it now. #7 is accurate.
Comment #11
afreeman commentedComment #12
deekayen commented