Possibility to change the username in admin user view or by themselfs

[ghost]

Hi,

Some users of my cloud are using their emailadress as usernames. Because some users changed their primary emailaccounts they want to change their username in owncloud also. Could you make it possible for the users to change their usernames - or that the admin can change it?

Thank you and keep up the great work!

[Bugsbane]

I'm looking for this functionality, too.

[Wikinaut]

+1

[enboig]

+1

I have done a look to the database and I think a possible roadmap to add this could be:

1. add "id" field to users table, make it primary key (and auto numeric) and make "uid" field "unique".
2. change all core functions so they identify users by id and not by uid.
3. add the option to change usernames, but also make an option to disable it so "legacy/old" 3rd party apps continue to work.

[enboig]

Maybe a "less traumatic" approach would be adding a "username" field, and just change validation functions and user edit functions to use it. The big headache here would be how to build a upgrade path for existing installations.

[ghost]

I’m closing this issue because it has been inactive for a few months. This probably means that it is not reproducible or it has been fixed in a newer version. If it’s an enhancement and hasn’t been taken on for so long, then it seems no one has the time to implement this.

Please reopen if you still encounter this issue with the latest stable version and then please use the issue template. You can also contribute directly by providing a patch – see the developer manual. :)

Thank you!

[Wikinaut]

Please reopen. The issue is still valid.

[i68040]

+1

[stevejordi]

+1 URGENT... This is a basic functionality...

[stevejordi]

This is not only philosophical but a real necessity. When accounts are automatically created via an LDAP connection, then, if someone gets married/divorced and change his/her name, this will automatically create a new empty account. Moving the content of the former directory + rescan won't help as all shared links will be lost. We have 4,500 users and can't manually manage the rename process with SQL commands after reverse engineering the database schema (which I'm not even confident with). All this on a production environment.

[blizzz]

Requires https://github.com/owncloud/core/issues/21282

[karlitschek]

usernames can't be changed because they are used in a lot of places in the DB, filesystem, logfiles and external systems/references. This can't be done.

The way to go is to see usernames as what they are. Internal references only that should be invisible to the users. I fact the only place where they are currently still visible is the login form. In the near future we will support login via email so this will be done too.

[stevejordi]

Well, I couldn't disagree more.

Usernames are not only visible in login. They are on the file system, they are spread tens of times in the database. That means the database is poorly designed as the username is used as an index. Indexes should never carry any kind of information whatsoever. Worse: it's used as an index now and then, when sometimes, it's used with a record id (which should be the only way) An index that is just autoinc would solve the problem: you change the username in one place and keep the same recordID and it'd done. The unique identifier can be managed internal without effect on the end-user, no matter how many times (s)he changes names.

Switching to email in the future will just prove as inefficient as currently since emails also carry information. Maria.Doe@... gets married and her email changes into Maria.Stewart@... then we start again, the entire login process will create a new empty environment?

If we had a real Database diagram with all indexes, that could help setup a 3rd party solution. And switching to email as login, will you provide a migration tool?

I just spent a full week trying to reverse engineer the database to provide our admins a way to rename users. We have user renaming every week, so since we have put owncloud into production we have a lot of people now that have lost every link they shared with others. For entire departments, we can't just answer "we can't change your name"

The decision has now been made to fully abandon the product whereas we were evaluating getting the professional licence a couple of months ago. But this specific problem is just something no-one believes could not be done.

I am the one recommending the product to our institution (4500 users) but have now been charged in finding an alternative. That's too bad. As I already did this in the past, and ownCloud was the most promising and matching our needs. But this rename thing is so basic that it slipped my mind during the test process. My mistake.

Steve

On Mar 19, 2016, at 22:30, Frank Karlitschek notifications@github.com wrote:

usernames can't be changed because they are used in a lot of places in the DB, filesystem, logfiles and external systems/references. This can't be done.

The way to go is to see usernames as what they are. Internal references only that should be invisible to the users. I fact the only place where they are currently still visible is the login form. In the near future we will support login via email so this will be done too.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/owncloud/core/issues/6984#issuecomment-198787577

[karlitschek]

again. Why do you insist to rename the username when no end-user actually sees it? This is an internal idea where a lot of things break if you play with it. Do you mixup displayname with username?

[stevejordi]

When Maria A works with ownCloud, everything is in the Maria_A folder.

She gets married, and is named Maria_B. The next time she logs in via LDAP, she has to type in Maria B as the username. She has no choice at all, Maria A doesn't work anymore.

This will be seen as the first login and will therefore create a NEW EMPTY environment, in Maria_B. She doesn't have access to the content of Maria_A anymore.

If, as a sysadmin, we move the files from Maria_A to Maria_B, and force a rescan, she will be able to see the files. But ALL the shared links are lost.

The display name is not important, we don't care at all about it.

Steve

On Mar 20, 2016, at 17:19, Frank Karlitschek notifications@github.com wrote:

again. Why do you insist to rename the username when no end-user actually sees it? This is an internal idea where a lot of things break if you play with it. Do you mixup displayname with username?

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/owncloud/core/issues/6984#issuecomment-198956757

[karlitschek]

As said before the solution for that is to enable login via email which can be changed anytime.

[stevejordi]

As I said before, how to we switch 4500 existing accounts to email login without losing anything? Is there a migration tool to take care of that?

And as I said before, what happens when the email changes? maria.a@... becomes maria.b@...

Isn't it just reproducing the same problem? How will the existing account be linked to the two email? Historically?

If it works, then fine if we can move 4500 accounts.

On Mar 20, 2016, at 17:37, Frank Karlitschek notifications@github.com wrote:

As said before the solution for that is to enable login via email which can be changed anytime.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/owncloud/core/issues/6984#issuecomment-198960289

[karlitschek]

login with email will be an option 9.1 automatically without the need to change anything. emails can be changed manually or via ldap at any time

[stevejordi]

It's too late for us, but out of curiosity, What about existing accounts? None of them were created manually nor were there created with any kind of email info. Will it be possible to link the existing 4500 account to the email info transparently?

On Mar 20, 2016, at 17:49, Frank Karlitschek notifications@github.com wrote:

login with email will be an option 9.1 automatically without the need to change anything. emails can be changed manually or via ldap at any time

— You are receiving this because you commented. Reply to this email directly or view it on GitHub

[blizzz]

When Maria A works with ownCloud, everything is in the Maria_A folder.

She gets married, and is named Maria_B. The next time she logs in via LDAP, she has to type in Maria B as the username. She has no choice at all, Maria A doesn't work anymore.

If you're using the LDAP backend, you have other issues.

First, the login name is decoupled from the user name (and this is even so for local users, only it is not that radical). I hope changing the name in LDAP does not create a totally new record. The username for every LDAP user does not change once it is mapped. You can specify anything to login with, even including the email attribute. You can also specify a dedicated attribute to refer to the user folder. Usernames really should not be your problem at all.

[Wikinaut]

(I reopened this issue some time ago).

Permanent coupling (locking) an account to e-mail addresses is evil (like Apple ID). For example, when Yahoo announced to stop their OpenID services, they also announced that they will "free" e-mail addresses after a cooling down period. (This allows identity-takeover and is very evil, too). So any change to an e-mail address is impossible, but when the e-mail address is changed to someone else, you as the "old address owner" do not have any chance and lost control of your account.

It should always be possible for users, or at least admins, to change the associated (to a user account) e-mail address (at least, as long as you own the old one).

With MediaWiki, you can do this: A user has an account, which is an auto-incremented database ID, to which a username (mandatory, because this is used for the login), a common name (optional) and an e-mail address (optional) are associated, which both can be changed with secure procedures.

[stevejordi]

If you're using the LDAP backend, you have other issues. First, the login name is decoupled from the user name (and this is even so for local users, only it is not that radical). I hope changing the name in LDAP does not create a totally new record. The username for every LDAP user does not change once it is mapped. You can specify anything to login with, even including the email attribute. You can also specify a dedicated attribute to refer to the user folder. Usernames really should not be your problem at all.

Well, if we rename someone in the LDAP directory, everything is renamed, the email, the short name, etc... That means each time someone changes name, the next login creates a new empty environment and everything is lost. I have done this tens of times, and besides copying the files, all the rest is gone.

Whereas a rename function in the admin console that would replicate the modification to each links and keys, would simplify things and let the end-user still have valid share links with others: just grab everything from "Maria_A" and make it "Maria_B". That's it

[blizzz]

Well, if we rename someone in the LDAP directory, everything is renamed, the email, the short name, etc...

The UUID should not. If DN changes, this is used to identify a user. By default we use the LDAP vendor's attribute, but this can be overridden. If an attribute is used that is not unique, or changing, then it won't work, obviously.

That means each time someone changes name, the next login creates a new empty environment and everything is lost. I have done this tens of times, and besides copying the files, all the rest is gone.

Use the native UUID in and you should be fine. It will only work for newly mapped users though. In your case it would be probably best to clean the mappings and start over again…

Whereas a rename function in the admin console that would replicate the modification to each links and keys, would simplify things and let the end-user still have valid share links with others: just grab everything from "Maria_A" and make it "Maria_B". That's it

… and suddenly you do not need to care about such magic.

[stevejordi]

The UUID should not. If DN changes, this is used to identify a user. By default we use the LDAP vendor's attribute, but this can be overridden. If an attribute is used that is not unique, or changing, then it won't work, obviously.

Well, we can't use "0-03-73687-846365-91614-93735" as a login for the end users. That's why we use the "shortname". And that's why we need to be able to rename a user.

Use the native UUID in and you should be fine. It will only work for newly mapped users though. In your case it would be probably best to clean the mappings and start over again…

With 4500 users? They have been using it for 6 months now. We can't start over with the existing solution

… and suddenly you do not need to care about such magic.

Well, I'm a software developper and sys engineer since 1980. In 37 years I have never stumbled upon such a problem. But I just found a study made in a institute of technology for a Bachelor in Computer Science that talks about the owncloud problem database design. I asked a copy. I might then write a quick app to rename users. I'll make it available to the community.

But in the meantime, I have been asked by our director board to move to another solution.

I don't understand why renaming a user seems to cause such a trauma and rejection from ownCloud. It's a basic feature not a caprice.

[blizzz]

Obviously you would not need to login with the UUID. It's all just a misconfiguration. Getting assistance earlier, also from our sales team, would have helped to get a properly running instance up. Frankly, what a username is, what to login with, and what uuid settings mean is all written up in the docs. If anything is unclear, bug reports against the documentation are welcome.

[cgogolin]

I would just like to add to this that the static, immutable user name is exposed to the user even if email login is used (at least through third party apps on 8.1).

The shared calendars CalDav links look like

http(s)://server:port/owncloud/remote.php/caldav/calendars/UserA/calendar-name
http(s)://server:port/owncloud/remote.php/caldav/calendars/userB/calendar-name_shared_by_userA

Users are hence reminded of the name of her/his divorced husband/wife when she/he wants to share a calendar with another user, even if she/he can login with her new email address.

I don't know how this is handled in 9.x. But since calendars have, if I remember correctly, been moved into the core, if this behavior has not changed, then this is now even a problem with core Owncloud.

[octacian]

I think we need to quite arguing. This is a very important feature. Right now, I want to change my ownCloud username. To do that, I'm going to have to create a new user and manually move all my content followed by "re-sharing."

The real problem is, usernames are a identifier created by the user, almost as a nickname, to remove the need of typing in an email. Yes, both should be an option, but username's are not what the who referencing system should be based off of.

The referencing and URL system, should use a unique id or uid to identify users. The login system would then point emails and usernames to the id, allowing these to be changed whenever the user wanted. This would mean that usernames and emails would have to be unique, but they should be anyways.

Another way would be to update the references with the username, which should also be very simple if ownCloud properly users one central resource for such references.

Overall, the task is very simple. Even updating plugins is simple. In fact, I will put some time into this myself when I get time. (if that ever happens.) This is ridiculously simple, come on guys.

[ffuentes]

+1

Would be nice that the username could be changed.

[stevejordi]

Unfortunately, to implement such a feature they would first have to hire a real DBA who knows what a database is. This database model is out of control, has been hastily cobbled together to meet the personal needs at the beginning by someone with no DB experience. As the solution grew bigger, it dragged that constrain along. The DB is a resource hog, it generates more than 60% of the ownCloud overhead. When you have strings holding information that can change used as keys, something is screwed from the beginning. It has to get back to the drawing board before any other feature.

[octacian]

@stevejordi I think that anybody could take the basic idea I mentioned earlier, and rework the database following along that. As I said before, this is a very simple problem. I am by no means a DBA, but from taking a look at the database, it may not have been designed the best and does need some work, but it's nothing major. It does the job, except for in this case. Making it work here is simple as well.

Once again, if I ever get time, I'll try and do something about this :smiley:

[stevejordi]

What would have been nice would have been a DB diagram with primary and foreign keys. I'm ready to write a small app myself to make the changes in the DB if I don't need to reverse-engineer the entire stuff.

Steve

On Sep 12, 2016, at 16:13, Elijah Duffy notifications@github.com wrote:

@stevejordi https://github.com/stevejordi I think that anybody could take the basic idea I mentioned earlier, and rework the database following along that. As I said before, this is a very simple problem. I am by no means a DBA, but from taking a look at the database, it may not have been designed the best and does need some work, but it's nothing major. It does the job, except for in this case. Making it work here is simple as well.

Once again, if I ever get time, I'll try and do something about this 😃

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/owncloud/core/issues/6984#issuecomment-246524853, or mute the thread https://github.com/notifications/unsubscribe-auth/AMHTYsZyvc0vYN4OiiwdahC6QV-tSSz1ks5qpdyNgaJpZM4BdJsL.

[Pazu]

I would like to point out one place where the username is visible. If user foo shares a calendar named bar, then other users see that calendar as "bar(foo)".

[atelierscym]

@stevejordi I think the app which parses the DB to change user names, should also have an option to send an email to all users who share things with the user which changes name (such as calendars). If I can be of any help to write such an app please ask.

[TrapperPhD]

Any news on that one? Impatiently waiting for solution allowing to change user name.

[archont00]

Luckily I do not use many functionalities apart from simple file storage, carddav and caldav - so hopefully simple copying files and export + import would suffice.

[PVince81]

Using account ids instead of user ids everywhere would allow this: https://github.com/owncloud/core/issues/29503

[sscholl]

+1

[PVince81]

and here's an overview of some tables to look at in which the username would need to be changed if one would want to do this manually: https://github.com/owncloud/core/issues/29993

the additional challenge is that if third party apps are using user ids as well they'd need to know as well that we want to rename so their own tables also get updated (hook?)

In any case, it sounds like first moving to account id is the better solution. Once this is done, renaming a user id is only a matter of a single table.

[butonic]

closing in favor of https://github.com/owncloud/core/issues/29503