Prevent editing own password - Docs method doesn't work

Prevent editing own password - Docs method doesn't work

by Frank Black -
Number of replies: 5

I am trying to limit user capability in v32. I read this page: https://docs.moodle.org/32/en/Roles_FAQ

It says:

> How can I prevent a user from changing their own password?

> The Authenticated user role (which is assigned to users in the System context) has moodle/user:changeownpassword = Allow by default,

> so you have two choices:

> 1. Edit Authenticated user, setting moodle/user:changeownpassword = Not set

> 2. Create a new role CannotChangeOwnPassword with moodle/user:changeownpassword = Prevent


Choice 2 was exactly what I was trying to do, but using 'prevent' doesn't work. I have to use 'prohibit'.

Can anyone else confirm that they need to use 'prohibit' to stop users changing their password; that 'prevent' doesn't work?


If confirmed, does anyone know what has changed to make the docs inaccurate?

I'm really struggling to understand the permissions hierarchy and this little disparity doesn't help my understanding. smile


Thanks!

Average of ratings: -
In reply to Frank Black

Re: Prevent editing own password - Docs method doesn't work

by Helen Foster -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators

Hi Frank,

I just tried on the Sandbox demo site and can confirm that you do indeed need to use 'prohibit' to stop users changing their password.

Please feel free to correct the Roles FAQ (simply log in with your moodle.org username and password then you'll be able to edit pages), otherwise I can do it.

I can't think of anything that has changed recently to make the docs wrong. It's possible that it has been wrong for a while but nobody noticed or thought to mention it. Thus, thank you for pointing it out. smile

Average of ratings: -
In reply to Helen Foster

Re: Prevent editing own password - Docs method doesn't work

by Frank Black -


I changed just the one word in the docs (Prevent to Prohibit).
I'm surprised that there isn't a 'conversation' page for editors to explain why changes were made (like wiki).


But Helen, maybe you can help me understand how the system-role hierarchy is supposed to work. We have 'authenticated user', 'manager', 'course creator', and our own custom system-roles. How are we supposed to work out which role overrides the other roles? After all, they are all in the same 'context'. Do you have any insight into this?


Thanks.

Average of ratings: -
In reply to Frank Black

Re: Prevent editing own password - Docs method doesn't work

by Frank Black -

> I'm surprised that there isn't a 'conversation' page for editors to explain why changes were made (like wiki).

OK, found it and worked out how to add a comment (I think).

Question stills stands: We have 'authenticated user', 'manager', 'course creator', and our own custom system-roles. How are we supposed to work out which role overrides the other roles? After all, they are all in the same 'context'. Do you have any insight into this?


Thanks.

Average of ratings: -
In reply to Frank Black

Re: Prevent editing own password

by Helen Foster -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators

Thanks Frank for correcting the documentation.

How are we supposed to work out which role overrides the other roles?

Good question Frank!

Normally roles are assigned in different contexts e.g. the role of manager is assigned in the system context and the role of teacher is assigned in the course context. However, if a user has more than one role in the same context, you would have to look at which permissions each role provides.

As we've found for users with the role of authenticated user and a cannot change own password role, if for a particular permission one role has Allow and one has Prevent, then Allow will win. If you don't want Allow to win, then you need to use Prohibit. Otherwise, depending on what you require, you could change Allow to Not set.

For further information, please see the documentation Override permissions.

Average of ratings: -
In reply to Helen Foster

Re: Prevent editing own password

by Frank Black -

OK. Thanks.


The way I imagined it would work would be that 'authenticated user' would be the highest, broadest (authenticated) role in the System context.

Then custom roles would automatically be seen as being more specific, and so a 'prevent' in a custom role would override the 'allow' in the 'auth user' role. The benefit of this is that in an ever lower, more specific role like a course, you could override the custom role if you wanted to.

As it stands just now, it seems that if you have to use a 'prohibit' in your custom role to override the 'auth user' role's 'allow', then you can't override it again lower down. So you end up having to edit the 'auth user' role, which is probably what you were trying to avoid in the first place with your custom role.

Anyway, I stopped working on my custom roles that were meant to override the 'auth role', and just decided to edit the 'auth user' role directly. It removes a layer of complication!


Thanks for your help.

Average of ratings: -