maxhbr
commented
7 years ago 1) The users's email is something the user is in control of, not sw360. Internal ids should be something that sw360 is in full control of. If a user changes the email, the user's id (old email) and the new email would not match, which might lead to errors/confusion, e.g. when exposing users as moderators in other sw360 domain objects.
You are right, the email address should be saved in only one field of the User object. And I do not think that an user should not be able to change his email address.
The current behavior is: If an user changes his email address using liferay, he ends up having no user account in SW360 and thus sees nothing (like setup@sw360.org). After the next login everything works fine and a new user is created in SW360 with the new address but he is now longer owner of his projects.
2) This breaks the usual scheme of sw360 domain classes, all other classes have ids without other semantics
except licenses, which have their shortname as ID.
In the datahandler lib, a User has an id and an email. During creation the email is copied to the id, which is also used in the couchbase db as _id. IMHO this has several disadvantages:
1) The users's email is something the user is in control of, not sw360. Internal ids should be something that sw360 is in full control of. If a user changes the email, the user's id (old email) and the new email would not match, which might lead to errors/confusion, e.g. when exposing users as moderators in other sw360 domain objects.
2) This breaks the usual scheme of sw360 domain classes, all other classes have ids without other semantics
3) When exposing domain object ids in other APIs (e.g. a REST API on top of the Thrift API), email would not be the best practice. It might also be a security issue to expose real emails in publicly available URIs of a REST API.
The existing Thrift Userservice API: User getByEmail(1:string email) already fulfills the requirement that it must be possible to get a user by email, but it always should access the email attribute rather the _id. It should still possible that a user logs in using email as identifier, only the internal user id should be different.