nextcloud
Change/rename login name
Hi,
I would like to rename/change my login name and we can't do that for now on Nextcloud. Can you support it?
Each Nextcloud user has two names: a unique Login Name used for authentication, and a Full Name, which is their display name. You can edit the display name of a user, but you cannot change the login name of any user.
Thanks,
No - the login name for now is our internal ID. We will not support this. You could also login via your email address (if it is only used once in the instance)
I would like to raise this issue again, because it is a very important Nextcloud limitation, especially for the following cases:
- trans folks who transition and want to eliminate their deadname (aka old first name, the name they were assigned that doesn't match their gender) in their username,
- folks who marry or divorce and want to eliminate their old last name in their username.
Other popular software like GitLab and Mattermost support changing the username without any problems.
If it's really not possible to change the "userid" at all for technical limitiations, it would be nice if it could still be overwritten virtually, so that the "userid" doesn't appear anywhere (except internally).
/cc @schiessle @rullzer @MorrisJobke
Depending on the case it is even a legal obligation. see https://gdpr-info.eu/art-16-gdpr/ (right to rectification)
Usernames almost never stick around for the entirety of someones life. Some are young and choose dumb, embarrassing names like xXNoobKiller69Xx, and some may regret using their real name as their username. Of course it's their own fault, and they could always create new accounts, but the more services support a simple means to rename your account, or migrate everything to a new account under a different username, the many more hours are saved for many people. That's what I think, anyway. Obviously the trans stuff is also quite relevant right now, but that was already mentioned. P.S., is it fair to call and flag this as "technological debt"? I believe the current best practice is not to let users choose their uniquely identifying name, but rather assign each a random numeric value. Then there's also what I'd call the "Discord approach", where users choose only a display name, and get a randomly assigned, smaller numeric value, however still with a unique number it maps to under the hood.
Also facing this question/issue.
Could a workaround be to have a function or feature that transfers ownership of all files/folders/tasks etc. from one user to another? That way, the workaround could be:
- Create a new account with the desired username 'UsernameB'
- Transfer ownership of all data from account 'UsernameA' to 'UsernameB'
- Delete 'UsernameA' account.
Not ideal, but might be easier from a technical standpoint?
@pjrobertson do you know if there is any way to do this? Esp. with things like calanders, export/import is difficult.
I don't know. The above suggested workflow was hypothetical. I see occ has files:transfer-ownership and dav:move-calendar. Those may work
For me, this would also be a very important function. Especially now that there are problems with the current Android version --> "Server not available" occurs when the username contains a space.
Edit: I know i can login with my e-mail address but than i have to reconfigure my account and syncs 😞
I don't know. The above suggested workflow was hypothetical. I see
occhasfiles:transfer-ownershipanddav:move-calendar. Those may work
If I'm right, this only transfers the files and calendars. But what happens with the remaining data of other apps?
Did anybody ever try to change the username directly in the database, table nc_accounts? Unfortunately, I don't have a test instance to try this safely.
Usernames are only used in two places: the database and the data folder. So it ‘only’ requires a find-and-replace in every database table and recursively in the data folder.
What would be better though, is assigning an ID for each user upon account generation, and have the username appear in one place in the database…
No - the login name for now is our internal ID. We will not support this. You could also login via your email address (if it is only used once in the instance)
@MorrisJobke Maybe you should reconsider this statement. It is fine to say "we don't support this at the moment" for the reasons given (username used as internal ID). But on the other hand using a user-facing string as internal ID is almost always a bad design choice. So in my opinion it would be much better to admit that this should be reworked and fixed in the future, though this might not be an easy task. I'm really tempted to reopen this, but maybe someone else wants to voice their opinion first.
@fschrempf I'm not working full time on this project anymore and my spare time is quite limited.
I also fully understand that this is a problem, still moving away from this has a huge potential of breaking many many instances out there and is a far from trivial task. There are options to mask the authentication methods (see LDAP for example where the user ID is by default a UUID) and there it is also not a problem. Still there should be all potential user facing elements being moved over to the display name instead of the internal ID. But then this would be fine.
That's basically it what we came to in the past years. Could I ask you to keep me out of further discussions?
So if we don't want to change the login name, b/c it's used as "internal UID", we could introduce a "visible name" to override it, this wouldn't break anything, as the "internal UID" could be a save fallback.
What I don't get is that it seems to already exists? When you create a new user you can already chose a display name.
This UI is available at URI /settings/users
So if we don't want to change the login name, b/c it's used as "internal UID", we could introduce a "visible name" to override it, this wouldn't break anything, as the "internal UID" could be a save fallback.
I think this is the solution!
What I don't get is that it seems to already exists? When you create a new user you can already chose a display name.
This UI is available at URI
/settings/users
So it's more a UX problem: how can Nextcloud expose the function of the display name more, and especially during the creation of the initial user.
You can change the display name, but the overview is very confusing; why not a separate column for the display name?
So it's more a UX problem: how can Nextcloud expose the function of the display name more, and especially during the creation of the initial user.
Even if the UI would use the display name everywhere, we would need to get rid of the username being used internally as ID, or turn it into some non-readable, random UID.
On Tuesday, 11 January 2022 19:48:33 GMT Frieder Schrempf wrote:
Even if the UI would use the display name everywhere, we would need to get rid of the username being used internally as ID, or turn it into some non-readable, random UID.
But that's easy, no? It's a question of using the user id field in a different way. Switch to using UUIDs instead or something like that such that this simply becomes a non-issue.
The beauty of it is it can even be done on existing instances gradually, just start using it this way for new users.
-- Best, r
Use the display name in the interface, and use the username in the background for a unique hash!
What about the desktop sync clients? They are often authenticated with usernames (I always log in to the web instance with username btw, so that should become impossible then and only allow an email address?).
On Tuesday, 11 January 2022 20:18:33 GMT dr. Matthijs Berends wrote:
What about the desktop sync clients? They are often authenticated with user names (I always log in to the web instance with username btw, so that should become impossible then and only allow an email address?).
Using e-mail addresses as login IDs is a good practice anyway -- most people will remember their e-mail address, but will forget their username on some random service they have to log into maybe twice a year.
-- Best, r