You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
disable allow_user_to_change_display_name, admin can't change name in user panel #642
As #1302 has been closed as duplicate of this issue, I'd like to throw in my support for enabling email modification independently from OC_User::canUserChangeDisplayName. There are in fact use cases where changing the display name should be disabled while changing email should be enabled.
After some discussion with @blizzz , it might be necessary to consider that user_ldap overwrites the email value in oc_preferences in case emails are present in LDAP. So for example the user_ldap backend could provide the email set-ability depending on whether an LDAP email attribute is set or not.
@MorrisJobke It would be great to know what you have in mind about how to implement this :)
I suggest:
'allow_user_to_change_display_name' => false,
should only prevent USERS from changing their DisplayName Settings and not automatically also their e-mail settings, so maybe an additional setting could be implemented like:
'allow_user_to_change_email_address' => false, ???
MUCH MORE IMPORTANT: this very important feature (when set to "false" should not impact ADMINS from changing or setting UserScreenName and UserEmail as well as it functions right now (I'm using 12.0.0. beta3 !!)
ettings/users
I can't change any details on this screen...
Have you set allow_user_to_change_display_name to false? If so: remove this line from the config and it should work again. That's currently a limitation we have.
The config that is built automatically doesn't include that line at all.
Specifically when I add that line = true then there is no change.
I can't make changes to user full name or add an email address, all I can do is allocate the user to groups and set them as admin for those groups.
Ideally, I'd like a screen similar to my own ./index.php/settings/personal page that would all of these settings to be changed for each user by the server admin
I can't make changes to user full name or add an email address, all I can do is allocate the user to groups and set them as admin for those groups.
Yes. This is sadly how it is implemented currently. 🙈 Somebody™ needs to fix it, but as this is a rarely used feature currently other issues are higher priotized. We are happy about contributions that fix this bug.
In my case, I am an admin and I can access the Admin panel, but I don't have access to the Nextcloud server files on our server. So I could only go to http://<our_ip>:8080/nextcloud/index.php/settings/admin in the browser and change it there.
Hi there. @MorrisJobke: Please reopen this ticket.
@dan-nkl, @revolter: I totally agree with you. Same problem with me. I am using a Nextcloud hoster for my company and I dot not have access to the config file. In order to be able to block users from 1. changing their screen name and 2. changing their e-mail address I really need this function to be part of the user interface.
If the company behind Nextcloud really has the goal to be used by many people, then you need to add many more functions to the user interface. Just take a look at Rocket.Chat and the amount of settings it offers for administrators with no access to any config file.
Activity
nickvergessen commentedon Aug 3, 2016
Well that is the way the config is designed at the moment, however I can see cases where this would not be the intended behaviour.
blizzz commentedon Dec 7, 2016
@focparty Display Name and Username are two different things. Could you elaborate?
GitHubUser4234 commentedon Dec 7, 2016
As #1302 has been closed as duplicate of this issue, I'd like to throw in my support for enabling email modification independently from
OC_User::canUserChangeDisplayName. There are in fact use cases where changing the display name should be disabled while changing email should be enabled.After some discussion with @blizzz , it might be necessary to consider that user_ldap overwrites the email value in
oc_preferencesin case emails are present in LDAP. So for example the user_ldap backend could provide the email set-ability depending on whether an LDAP email attribute is set or not.@MorrisJobke It would be great to know what you have in mind about how to implement this :)
githubos1 commentedon May 17, 2017
I suggest:
'allow_user_to_change_display_name' => false,
should only prevent USERS from changing their DisplayName Settings and not automatically also their e-mail settings, so maybe an additional setting could be implemented like:
'allow_user_to_change_email_address' => false, ???
MUCH MORE IMPORTANT: this very important feature (when set to "false" should not impact ADMINS from changing or setting UserScreenName and UserEmail as well as it functions right now (I'm using 12.0.0. beta3 !!)
Regards,
Oliver
OutbackMatt commentedon May 22, 2017
11.0.3 seems to NOT be working from ./index.php/settings/users
I can't change any details on this screen...
MorrisJobke commentedon May 22, 2017
Have you set
allow_user_to_change_display_nametofalse? If so: remove this line from the config and it should work again. That's currently a limitation we have.OutbackMatt commentedon May 22, 2017
The config that is built automatically doesn't include that line at all.
Specifically when I add that line = true then there is no change.
I can't make changes to user full name or add an email address, all I can do is allocate the user to groups and set them as admin for those groups.
Ideally, I'd like a screen similar to my own ./index.php/settings/personal page that would all of these settings to be changed for each user by the server admin
MorrisJobke commentedon May 22, 2017
Yes. This is sadly how it is implemented currently. 🙈 Somebody™ needs to fix it, but as this is a rarely used feature currently other issues are higher priotized. We are happy about contributions that fix this bug.
radiantwave commentedon Jul 5, 2017
I really need this feature to control if the users can change the displayname or e-mail. And this independently.
In my usecase I need to disallow the displaynamechange for the users. The E-Mail should be still changeable.
At the moment I use a workaround that removes the form from the template. But this is only a visual removal!
radiantwave commentedon Aug 4, 2017
This is not a Milestone anymore?
9 remaining items
revolter commentedon May 8, 2018
Is
allow_user_to_change_display_nameable to be changed from the Admin page instead of theconfig/config.phpfile?radiantwave commentedon May 8, 2018
Would be much better.
allow_user_to_change_display_name should be a setting in the UI.
nickvergessen commentedon May 8, 2018
I don't think so, because it's normally a one-time setting.
revolter commentedon May 8, 2018
Regardless, it should be in the UI.
In my case, I am an admin and I can access the Admin panel, but I don't have access to the Nextcloud server files on our server. So I could only go to
http://<our_ip>:8080/nextcloud/index.php/settings/adminin the browser and change it there.radiantwave commentedon May 8, 2018
And I hope that the suggestions from @githubos1 has been seen..
'allow_user_to_change_email_address'
'allow_user_to_change_display_name'
really should be two separate settings..
I'm wishing this feature since I was using Owncloud..
GoetheG commentedon Apr 12, 2019
Hi there. @MorrisJobke: Please reopen this ticket.
@dan-nkl, @revolter: I totally agree with you. Same problem with me. I am using a Nextcloud hoster for my company and I dot not have access to the config file. In order to be able to block users from 1. changing their screen name and 2. changing their e-mail address I really need this function to be part of the user interface.
If the company behind Nextcloud really has the goal to be used by many people, then you need to add many more functions to the user interface. Just take a look at Rocket.Chat and the amount of settings it offers for administrators with no access to any config file.
MorrisJobke commentedon Apr 12, 2019
@GoetheG Please open a new issue for this. We then can evaluate again if this makes sense or not (also from a maintainability point of view)