allow_user_to_change_mail_address=false blocks admins as well
Steps to reproduce
- Set
allow_user_to_change_mail_address=false - Try
curl -u adminuser@adminpassword -X PUT 'https://cloud.example.com/ocs/v2.php/cloud/users/testuser' -d key="email" -d value="[email protected]" - See it failing
Expected behaviour
Admins should be allowed to change the email addresses of users, even if normal users are not allowed to change their own addresses.
Actual behaviour
Failed with:
<?xml version="1.0"?>
<ocs>
<meta>
<status>failure</status>
<statuscode>997</statuscode>
<message/>
</meta>
<data/>
</ocs>
Server configuration
ownCloud version: 10.9.0
@xoxys allow_user_to_change_mail_address=true - do you mean false ?
It looks like similar happens for allow_user_to_change_display_name
I will make some test scenarios that demonstrate the problem.
Ah yes of course sorry, fixed.
Note that the https://github.com/owncloud/core/blob/9d263e43682b7eb9866ee8d520f9f2b66a0dac92/core/Migrations/Version20210928123126.php migration is a bit buggy: the default value is the empty string, not null.
This means that, although the allow_user_to_change_display_name is missing, the allow_user_to_change_mail_address will be set to the empty string. It doesn't affect the behaviour because you still can edit the email, but the config entry shouldn't appear.
This behaviour is also visible in new installations.
Another question - what is the requirement for subadmins? If allow_user_to_change_mail_address=false and/or allow_user_to_change_display_name=false then should a subadmin still be able to change the email and/or display_name of users that they have subadmin rights to?
@pmaier1
PR #39688 has test scenarios that demonstrate the issue.
It looks easy enough to fix - I added server code fixes to #39688 The question is what exactly are the requirements?
If allow_user_to_change_mail_address=false and/or allow_user_to_change_display_name=false then should a subadmin still be able to change the email and/or display_name of users that they have subadmin rights to?
Good catch, thanks! Yes, admins/subadmins should always be able to change these values for other users in the user management / provisioning API.
good - PR #39688 does that. I just need to add a few unit test cases to make sure the permutations are covered.