If I go to personal preferences and change my email, i must now use this new email to log in.
I understand the logic here; however, in site setup/security the wording there I think contradicts this action (copied from that section):
++ Use email address as login name
Allows users to login with their email address instead of specifying a separate login name. This also updates the login name of existing users, which may take a while on large sites. The login name is saved as lower case, but to be userfriendly it does not matter which case you use to login. When duplicates are found, saving this form will fail. You can use the @@migrate-to-emaillogin page to show the duplicates.
++Use UUID user ids
Use automatically generated UUIDs as user id for new users. When not turned on, the default is to use the same as the login name, or when using the email address as login name we generate a user id based on the fullname. {MY NOTE: The last section in the sentence states if email logins are used, then a user id generated from full name. if so, why does changing my email change my login??)
I understand the logic of using the new email as login, I just think the wording above is confusing. also, I would suggest we find some way to make this more obvious that changing your email changes your login (as obvious as some may find this)
The user id is there to be able to identify the user (its objects, its permissions, its group memberships, ...) across login name changes. Thus, if you change the email adress, you get (in your case) a new login name but you keep the user id.
Thus, nothing is wrong with the wording.
As a side note: creating the user id based on the fullname might be dangerous: marriage often changes the fullname - but maybe, the user id is stored permanently (and independently from the whatever it was computed from in the first place), then there will be no problem.
@dieter thanks for the reply.
Beauty and clarity are in the eyes of the beholder I just didn't think it was clear and thought posting might help someone else.
However, note that in your "as a side note" , you end by saying "but maybe the user id is stored permanently... then there will be no problem" . I believe this shows there is ambiguity in the idea of a user name vs id. I'm sure I'm just looking too deeply as no one else has responded to this post. i guess I'm just worried if the light really goes off when i close the refrigerator door. !
But I don't see why this should be an issue, regardless of using the name or email. if a true uid is created, and this is used to associate a user with their content, pwd, etc. this uid would be invisible to the user and never changes, regardless of changing email or user name.
Isn't that what a UID is for?
Anyway, I don't want to eat up too much of anyone's time, I just found this interesting.
You are right. Almost surely, the id is stored permanently (and it is then not relevant how it has be created). However, the id is not "invisible": it will be part (for example) of the member folder url.
Everything, you can do via a menu, you can do programmatically as well.
Roughly, there are two approaches for this: HTTP automation (you emulate user interaction with a script speaking via HTTP with your Plone) and calling the respective Plone view or the corresponding backend infrastructure in an interactive session (bin/{instance|client1} debug).
I just didn't think it was clear and thought posting might help someone else.