Disabling all the optional preferences

Disabling all the optional preferences

by Frank Black -
Number of replies: 13

Transitioning from Moodle v2.4 to v3.2


I've never really grasped the permission system (despite reading the docs and forum for hours on this one topic).

I'm setting up a new site and I want to disable a lot of functionality sitewide for two separate real-life groups of users - staff and children. And by 'a lot' I mean nearly everything. Users should not be able to customise anything on the site or change any preferences; every user must see exactly the same thing as each other when they log-in and browse different areas of the site (at least in the beginning; I might give the adults more options and features later, whilst keeping the children's options completely locked down).


For example, the first couple of things that I need to turn off completely for both groups sitewide are:

· No-one should be able to edit their dashboard. The 'customise this page' button has to disappear.

· No-one should be able to edit their profile - in fact all the preferences under the profile cog icon have to disappear before I take the site live. Hopefully if I turn off all the preferences, the cog itself will disappear too!


The way I did this sort of thing before, on a previous v25 site, was to just massively edit the default authenticated user role, setting everything to 'prevent'. I'm not sure that was the 'best' way though, and this time I would like to be able to give back the staff group some extra sitewide permissions later on.


So I'm thinking the way to start off this time is to create two new sitewide roles ('staff' and 'child') both with the 'authenticated' archetype, then set every preference I can find to 'prevent', and finally assign the users respectively on the 'assign system roles'. Would this be the most correct way of doing it?


Also, the main thing I don't understand is the cascading of roles:

How can I make my two new roles take precedence over the default authenticated user role, and completely override it everywhere on the site?

Similarly, if I made a new 'Limit Course Teachers' role restricting what staff can do inside courses, how would I make those options take precedence over the default teacher role?

Lastly, I don't quite understand how the default authenticated user is a sitewide system role, but it is not listed with 'manager' and 'course creator' system roles?


Thanks for any clarification you can give. Please bear in mind I've already read the docs several times and I've already got them all bookmarked. So just referring me to the docs is not going to be very fruitful, although if you want to refer to them or quote from the docs to further explain their meaning, that would be great.


Average of ratings: -
In reply to Frank Black

Re: Disabling all the optional preferences

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

The easiest way is to edit the existing Staff, Student and Authenticated User roles. You can add new ones - you just need to make sure you assign those roles when you enrol users on courses. If making new ones, make sure you set them up so they can be assigned in courses (or whatever). It's in the - *cough* - docs. 

There is a setting "Default role for all users" that sets the role you get as soon as you log in. Currently "authenticated users". That works as it says on the box. When you log in you get that role until you go into a course and get something else or have a sitewide role. However, I normally say that the "User policies" settings should be left alone unless you know what you are doing wink

It's a bit tricky when somebody says "I read the instructions and don't understand them". It might be more helpful to refer to particular bits that don't make sense. Then we can improve them.

Average of ratings: -
In reply to Howard Miller

Re: Disabling all the optional preferences

by Frank Black -

> It might be more helpful to refer to particular bits that don't make sense. Then we can improve them.

There's nothing wrong with the docs. It's my tired old brain, and an ability level too low for administering a Moodle site.


> You can add new ones - you just need to make sure you assign those roles when you enrol users on courses


OK, so this is one point where I'm fuzzy and confused. Let's target my need to disable everyone from editing their dashboard...


· Ideally I don't want to touch any of the default roles - all my own edits should be in roles that I create.

· So I create a new system role called 'limitations' and put everyone into it on the 'assign system roles' page.

· In the 'limitations' role (which has all permissions initially set to 'unset') I then find all the permissions connected with editing or managing the dashboard and set them to 'prevent'.


At this point, when a user logs in and lands on their dashboard, they have the default 'authenticated user' role and my 'limitations' role.

Where I'm fuzzy is that if the authenticated user role says they can edit their dashboard, and my 'limitations' role says that they can't, where about in Moodle can I dictate precedence for the 'limitations' role over the authenticated' role? I would call this a 'cascade', where one permission overrides another because one role takes precedence over another. But I've never been able to work out how or where Moodle does this.

Another example - I understand some contexts are contained within other (Eg. category -> course -> block -> activity) and so there is cascading of roles there. But what if in a course a user has the 'teacher' role *and* my custom 'teacher limitations' role. They are in the same context (course), so how can I get my custom role to override the default teacher permissions?


Thanks.

Average of ratings: -
In reply to Frank Black

Re: Disabling all the optional preferences

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

No.... (to most of it)... 

* When you log in, you are given the 'Authenticated user' role site-wide. This give you rights to do almost nothing. As it stands, is there anything outside of a Moodle Course that you don't want users to do? I suspect not. In which case, leave Authenticated user and site-wide roles alone. You are only interested (I think) in what happens when people go into a course. 

* In order to add someone to a course, you need to Enrol them and give them a role (student or teacher usually). This is where you want to add restrictions. Why not just take away capabilities from the student or teacher role?

Or am I missing something...?

Average of ratings: -
In reply to Howard Miller

Re: Disabling all the optional preferences

by Frank Black -

Thanks for your reply Howard.

I've been doing some experimenting:

· I created a system role called 'limit staff' and added the staff into it using 'assign system roles' page.
· Then I'm going through and setting some items to 'prohibit'.

Eg. 

Edit own user messaging profile

Edit own user profile

Edit a block's settings

Manage Dashboard page blocks

Edit own user messaging profile

Manage blocks on own public user profile

These are all permissions which make menu items and cogs for various preferences disappear.


After I've finished taking all the preferences away and locking things down as far as they'll go, I will create a system role called 'limit children' based on the staff one. Then I have the option of giving the staff back some preferences whilst keeping the children's preferences to a minimum; I wouldn't be able to do that if I had just simply edited the 'authenticated user' role directly.


The only thing that is puzzling me, as I stated before, is why I have to use the 'prohibit' setting in order to override the authenticated user permissions. I don't understand the cascade or inheritance of the system-level roles...

In my mind, the authenticated user role is the broadest permission, whilst the 'manager', 'course creator' and my 'limit staff' roles are all more specific. So, in my mind, I should have been able to use the 'prevent' setting instead of 'prohibit'.

But then taking this further, if I am in the 'manager' role but also in the 'limit staff' role, which of these roles takes precedence in case of a conflicting permission? I don't know how this is handled, because (in my mind) they are at the same level of inheritance, under the authenticated user role.


What I've done so far is working, but I still feel like I have a misunderstanding of the permission system, especially where hierarchy/cascades are concerned.

Average of ratings: -
In reply to Frank Black

Re: Disabling all the optional preferences

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

I've no idea why you are so determined to add people to system-wide roles. It's overthinking it. Add people to roles where they need to be added. Which is generally in courses. 

Average of ratings: -
In reply to Howard Miller

Re: Disabling all the optional preferences

by Frank Black -


> When you log in, you are given the 'Authenticated user' role site-wide. This give you rights to do almost nothing.

I respectfully disagree. I think the default settings give each user far, far too many personalisation options. Once 400 children (who generally have no idea what they're doing and just click around curiously) have changed their interface and preferences beyond recognition, and have randomly enabled and disabled features, it is impossible to deliver training or troubleshoot why half a class aren't able to see Mrs Applebee's homework assignments, or view a course calendar, or... a hundred other things. For a school, Moodle needs to be locked down, at least in the beginning, and features introduced and tested one at a time in a controlled manner.


Did you take a look at the list of the kind of permissions that I am disabling?

They are all at system level. You can't, for instance, disable profile or dashboard editing from the course role/context.

Basically, I need to disable all customisation, personal preferences and messaging sitewide, in a way that I can partially re-enable some options for selected people later on. Using 'prohibit' seems to be doing the trick in overriding the 'authenticated user' permissions. But as I say, I don't understand which roles take precedence at the system level, and how conflicting permissions are resolved. 

Average of ratings: -
In reply to Frank Black

Re: Disabling all the optional preferences

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

You're scary - but I take your point big grin

In which case modify the Authenticated user role to take these capabilities away. Your administrator is unaffected as they always have ALL capabilities. And Managers assigned at site-level (if you have any) will  not be troubled by the restrictions either.

If you want some students to have extra capabilties you can create a custom role with just those capabilities and add them to that. 

I would think in terms of *giving* users the capabilities not taking them away with prohibit. 

Do all consider that you will be pushing Moodle into modes of operation that have never been done and never tested so tread carefully. You can get some very peculiar bugs by making extensive changes to roles. 

Average of ratings: -
In reply to Howard Miller

Re: Disabling all the optional preferences

by Frank Black -

> You're scary - but I take your point

Oh no... I'm just an ignorant, harmless old goat. Pay no attention.


> I would think in terms of *giving* users the capabilities not taking them away with prohibit. 


So I should edit the 'authenticated user' role to disable the functionality for everyone, and then in the 'staff' system role, set some things back to to 'allow'?

I do like your suggested approach, for a couple good of reasons. But my question is then - how do you know that the 'allow' permission in my custom 'staff' role will override the 'unset' or 'prevent' permission in the 'authenticated user' role?


Thanks for your continuing input.

Average of ratings: -
In reply to Frank Black

Re: Disabling all the optional preferences

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Yes - that. Create a staff role and add individuals to it that require additional features. 'Allow' will always override 'unset'. It won't override 'prevent' but you have no need to set anything to prevent that I can see. Removing the required 'allows' from the authenticated user role will have the result you need. 

Average of ratings: -
In reply to Frank Black

Re: Disabling all the optional preferences

by Chris Bedford-Gay -

Hi Frank,


Trying to do something similar... did you ever find a permission that removes access on the Users Preferences page to hide Forum Preferences?


I want users to be able to access the page but only to limited items on it.



Average of ratings: -
In reply to Chris Bedford-Gay

Re: Disabling all the optional preferences

by Frank Black -
I'm sorry, no I didn't. The permission system, for all its complexities and convolutions, kept failing because it did not cascade or prohibit correctly with certain core modules, and the permissions for some features are 'bundled' together (so if you try disabling one thing, it disables several others options that you didn't want disabled). In fact, I actually got further with locking down Moodle by hiding the nuisance menu items and buttons with CSS, and then by creating a block for the staff with some of the hidden links put back in for them as a static menu. But it's quite time consuming if you don't know CSS thoroughly.


However, as a school, we actually gave up on Moodle and are currently moving to Google Classroom for this September. I'm not sure it will be much better though (I remember testing Google Suite for Education five years ago, and thinking it was quite a mess). We also evaluated Office365 Education and quickly decided that Microsoft have lost the plot.


The important thing for me is that I have managed to get out of this hellish role, and with any luck will have nothing to do with our school's VLE from now on. I'm actually looking forward in September to having people come to me with their technical issues, and being able to shrug my shoulders and tell them that it's not my problem anymore! Just thinking about it makes me smile.

Average of ratings: -
In reply to Frank Black

Re: Disabling all the optional preferences

by Chris Bedford-Gay -

Ah ha, I can dream of that day.

I'm a developer but got roped into setting up an LMS (you know, to make some money) but they make me wanna curl up and hide.

CSS idea was one I was working up.  Just I need slightly more granuality as it's a Iomad install and each company within it is likely to have difference settings.  Company specific theme might do it but....

Anyhow, enjoy your escape and thanks for getting back to me smile

Average of ratings: -
In reply to Chris Bedford-Gay

Re: Disabling all the optional preferences

by Robert Claypool -

Chris,

Please keep us appraised of your progress.  I also would like to lock down a user and prohibit the ability to do anything EXCEPT take a particular course where I provide the link.

A few years back, someone said the only way to do this was with CSS.


Average of ratings: -