It is necessary. The original fix did not cause an error but did not update the dict.
On Jun 21, 1:48 am, Yarko Tymciurak <[email protected]> wrote: > On Jun 21, 1:31 am, mdipierro <[email protected]> wrote: > > > The fix was wrong but the problem was there. I think I fixed it in > > trunk. Please check it. > > Actually, I'm not sure the fix was wrong (I ran in debugger, and the > Field key was properly referenced in update_record(); > > In any case, this will work too, although I'm not sure the extra > gyrations (make a dict; unwrap a dict) are necessary. > > Thanks for catching this, Nick! > > - > > > > > On Jun 21, 12:41 am, Yarko Tymciurak <[email protected]> > > wrote: > > > > On Jun 20, 5:52 pm, NickFranceschina <[email protected]> > > > wrote: > > > > > Version 1.79.2 (2010-06-08 22:45:26) > > > > > was browsing through the code implementing some custom authentication > > > > and noticed this on line 1809 of tools.py: > > > > > user.update_record(password=form.vars.new_password, > > > > registration_key='', reset_password_key='') > > > > > where a few lines above you see this: > > > > > passfield = self.settings.password_field > > > > The auth table is created with a name for the password field, as set > > > by settings.password_field > > > > > so I assume line 1809 should actually be: > > > > > user.update_record(passfield=form.vars.new_password, > > > > registration_key='', reset_password_key='') > > > > You are absolutely correct - while this bug will not show up if the > > > password field is left at its default of 'password', this will fail in > > > any other circumstance. > > > > I believe you are correct - and your correction seems proper. > > > > Massimo - can you review, and make this correction? > > > > - Yarko > > > > > -Nick Franceschina
