Fix(Users): allow login update

[Rom1-B]

Checklist before requesting a review

Please delete options that are not relevant.

• I have read the CONTRIBUTING document.
• I have performed a self-review of my code.
• I have added tests that prove my fix is effective or that my feature works.
• This change requires a documentation update.

Description

• It fixes !39438

On a user profile, the login field was only editable in the interface under certain conditions. However, this restriction caused issues, for example, when a user changed their name and, consequently, their login in the external authentication system. Allowing this modification prevents the need to create a new user in the database and preserves the existing links established before the login change.

Screenshots (if appropriate):

[trasher]

Should not that target 10.0/bf?

[cconard96]

This seems a little risky. In most cases an external user should be synced by a unique ID/GUID, not their username. If you change their username and choose to sync by username, then it is rightly considered a new user.

There may be a case where an external user should allow changing the username, but I do not think making the field freely editable is the best solution.

[Rom1-B]

This customer connects to GLPI in SSO via Azure using the UPN. One of their users on Azure has changed their name, which has changed their UPN and therefore their login. It is still the same person, and the customer does not want any breaks in links before and after the login change, which is understandable and relatively common.

The current solution involves modifying the database directly, which seems riskier to me as it is not logged.

[cedric-anne]

This customer connects to GLPI in SSO via Azure using the UPN. One of their users on Azure has changed their name, which has changed their UPN and therefore their login. It is still the same person, and the customer does not want any breaks in links before and after the login change, which is understandable and relatively common.

The current solution involves modifying the database directly, which seems riskier to me as it is not logged.

Maybe we should remove the ability to change the login of any user in the user form and instead propose a specific action named "change the login" that displays a form containing a warning about the consequences of such a change.

[cconard96]

Well it sounds like the plugin doesn't separate the concept of a login field and sync field like we do for LDAP, but I don't know if that is a technical limitation of the providers or if there was another reason.

If the plugin did implement it, we could say on the core side that if a user's login field is the same as the sync field that the username can be updated (with a warning still of course).