-
-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
plone.api.get_roles(username=userid) breaks if username != userid #204
Comments
IIUC, the proper way would be to update all api methods that use the "username" parameter to also take the "userid" parameter (in cases where username does not equal userid). |
Yesterday @mattss and I discovered a potential bug in api.user.get that may indeed be related to the above issue. I will see if I can write some tests to expose this problem. |
Different userids and usernames are really common. |
We also had a problem once with the difference between userid and username. It would be nice to be able to use either username or userid/user_id |
Out current work around is to first use |
What needs to be done, and who is going to do it? |
IMO, what needs to be done is we should change the signatures of every function (except possibly |
Sorry, I've been too busy to look at this one recently. Anyone should feel free to take it on. |
the whole naming is crap, usally we have in authorization systems a login and a userid, and thats the confusion. THEN PAS uses the term login in its credentials, see So I would prefer to unify naming in Plone to
|
YES! Awesome! 💃 |
👍 |
Any takers? I would really love to see this resolved before shipping plone.api with Plone 5. |
When use with collective.emaillogin4, userid can be different from username.
So the api should be
plone.api.user.get_roles(userid=None, user=None, obj=None, inherit=True)
not
plone.api.user.get_roles(username=None, user=None, obj=None, inherit=True)
The text was updated successfully, but these errors were encountered: