Updating display_name (using SQLAlchemy)
kvaml
While the complicated change email address logic worked, the change
password did not - except when the email address was also changed.
I added display_name to the fields and got updates to work by getting
a fresh user object. To do this I had to first import my projects
model in addition to register_model.
from MYPROJECT import model
Then I changed update_users:
def update_user(self, display_name, email, old_password, password1,
password2, user_name=None):
"Updates the users information with new values."
#user = identity.current.user
user = model.User.get(identity.current.user.user_id)
The identity.current.user belongs to a different session, so the
changes were not applied. Getting a fresh User object gets around
that problem. (I don't know if this was an issue with SQLObject)
Patrick Lewis
> I noticed that display_name was omitted from the edit_user screen.
> While the complicated change email address logic worked, the change
> password did not - except when the email address was also changed.
display_name not being included was a design decision; I figured most
sites wouldn't want users to be able to muck with their 'public' name
('bad' users could change their name to try and mask their identity,
or try and impersonate someone else). Not saying one can't do as you
have done, but just that I don't think it would be the default.
>
> I added display_name to the fields and got updates to work by getting
> a fresh user object. To do this I had to first import my projects
> model in addition to register_model.
>
> from MYPROJECT import model
>
> Then I changed update_users:
>
> def update_user(self, display_name, email, old_password, password1,
> password2, user_name=None):
> "Updates the users information with new values."
> #user = identity.current.user
> user = model.User.get(identity.current.user.user_id)
>
> The identity.current.user belongs to a different session, so the
> changes were not applied. Getting a fresh User object gets around
> that problem. (I don't know if this was an issue with SQLObject)
That is kind of baffling to me. I don't understand why the first user
= identity.current.user call would fail, but using the user_id of the
same object would be ok. If anything, it looks like an identity bug.
Was this something you consistently saw? Is it possible that the
browser was caching form fields? (sorry, grasping at straws)
Lloyd Kvam
That call worked and got a user object. However (at least with
SQLAlchemy/MySQL) the changes were not applied automatically. When I
tried to force a save I got a session error. (I did not save the exact
exception.) Changing the password also did not get saved.
It was the session oriented exception that got me to try creating a
fresh user object within "my" session.
> but using the user_id of the
> same object would be ok. If anything, it looks like an identity bug.
> Was this something you consistently saw?
Yes, it was consistent. Could it be changes in SQLAlchemy since you
were testing? I don't think I fouled up the original registration logic
while making changes for my needs.
> Is it possible that the
> browser was caching form fields? (sorry, grasping at straws)
No. I was checking against the database. All of the hard parts (email
confirmation) worked beautifully.
Since it is a surprise to you, I'll do a careful test over the weekend
and make sure that I did not have some other error that was blocking the
identity code from executing properly.
>
>
>
--
Lloyd Kvam
Venix Corp
DLSLUG/GNHLUG library
http://www.librarything.com/catalog.php?view=dlslug