Hi folks,
I wish to provide a cut down site administration role to our education advisors which allows them access to the Users/Accounts menu options, and Courses/Add/edit courses menus.
I have created a new role called education advisor, but not sure which options I should ALLOW in the list of permissions.
Could someone help me with this?
Thanks in advance,
Grant Beevers
ACNM, Brisbane
Hi Grant,
Your "education advisors" (their job title, not a role) need permissions in two different contexts to do their job.
For their course creation responsibilities, you can use the predefined Course creator role to them in a Category context. It already has the needed permissions (there are only four permisions). By default the top level category is called Miscellaneous, so you could assign the role there. You may want to have one education advisor per category. A course creator becomes a Teacher in a newly created course, and is therefore allowed to assign roles to users within the course. This ability comes from the Teacher role, not the Course creator role. They can not assign roles in courses they did not create. This is the standard Moodle role architecture. If that doesn't work for you, we will come up with a different design.
For account creation and maintenance, education advisors need permission in the System context. I would create a new role called Account manager with
Do not create one fat role called Education Advisor that can do everything. As time goes by, you will want to give education advisors additional responsibilities (I'm sure your list is incomplete), and you can do this be creating additional roles and assigning the roles in the appropriate context. If you create one fat role, you will have to assign it in System, and you will surely give the education advisors too much power.
Always start by identifying the responsibilities that you want to give to users, exactly as if you were writing up a job description. Then gather the list of permissions, identifying the lowest possible context in which each permission is needed. Then allocate those permissions to multiple roles. The more roles you have, and the "thinner" they are, the more reusable they are. For example, you can phase in responsibilities by adding new role assignments to individuals, or revoke responsibilities by removing role assignments.
Your "education advisors" (their job title, not a role) need permissions in two different contexts to do their job.
For their course creation responsibilities, you can use the predefined Course creator role to them in a Category context. It already has the needed permissions (there are only four permisions). By default the top level category is called Miscellaneous, so you could assign the role there. You may want to have one education advisor per category. A course creator becomes a Teacher in a newly created course, and is therefore allowed to assign roles to users within the course. This ability comes from the Teacher role, not the Course creator role. They can not assign roles in courses they did not create. This is the standard Moodle role architecture. If that doesn't work for you, we will come up with a different design.
For account creation and maintenance, education advisors need permission in the System context. I would create a new role called Account manager with
- moodle/site:upload users ("Upload new users from a file") = Allow
- moodle/user:create ("Create users") = Allow
- moodle/user:delete ("Delete users") = Allow
- moodle/user:update ("Update user profiles") = Allow
- moodle/user:viewdetails ("View user profiles") = Allow
- moodle/user:viewhiddendetails ("View hidden details of users") = Allow
- and all other permissions Not set
Do not create one fat role called Education Advisor that can do everything. As time goes by, you will want to give education advisors additional responsibilities (I'm sure your list is incomplete), and you can do this be creating additional roles and assigning the roles in the appropriate context. If you create one fat role, you will have to assign it in System, and you will surely give the education advisors too much power.
Always start by identifying the responsibilities that you want to give to users, exactly as if you were writing up a job description. Then gather the list of permissions, identifying the lowest possible context in which each permission is needed. Then allocate those permissions to multiple roles. The more roles you have, and the "thinner" they are, the more reusable they are. For example, you can phase in responsibilities by adding new role assignments to individuals, or revoke responsibilities by removing role assignments.
Hi John,
Thanks for this. This is what I did. Created a new user (for testing). Gave them Course Creator. Created a new system role Account Manager. Gave it the permissions outlined above. Gave the new user system access to this role.
I can see the User menu when I log in, so that takes care of that. However, I can't see Course menu at all. Under the course creator role, what should the ALLOW permissions be as I when I look at this role in the system , it appears that this role does not have the right permissions set.
Grant
Thanks for this. This is what I did. Created a new user (for testing). Gave them Course Creator. Created a new system role Account Manager. Gave it the permissions outlined above. Gave the new user system access to this role.
I can see the User menu when I log in, so that takes care of that. However, I can't see Course menu at all. Under the course creator role, what should the ALLOW permissions be as I when I look at this role in the system , it appears that this role does not have the right permissions set.
Grant
Grant,
You should assign the Course creator role to users in a category context. Users will not see a Courses link in Site administration. They need to enter their category, where they will see an Add course button. You don't want course creators bumping into each other. Give each one responsibility for his/her own category. There are lots of other responsibilities I would probably give them within their categories (e.g., the ability to manage the category structure, ability to assign roles within the category, etc.), but you only asked for the ability to create courses, so that's all I gave you.
Do not modify the Course creator role. It is just fine. It should have four permissions Allow and the others Not set. The most important permission is moodle/course:create ("Create courses") = Allow.
You should assign the Course creator role to users in a category context. Users will not see a Courses link in Site administration. They need to enter their category, where they will see an Add course button. You don't want course creators bumping into each other. Give each one responsibility for his/her own category. There are lots of other responsibilities I would probably give them within their categories (e.g., the ability to manage the category structure, ability to assign roles within the category, etc.), but you only asked for the ability to create courses, so that's all I gave you.
Do not modify the Course creator role. It is just fine. It should have four permissions Allow and the others Not set. The most important permission is moodle/course:create ("Create courses") = Allow.
Ok, you lost me here. With respect to courses, all I need the Ed Advisor role to do is add the newly created user into the relevant course that they should be enrolled in. Nothing more. The Account Manager role gives them the ability to create the new user, however, now I need them to be able to assign them to a relevant course in the category structure. They will not add/create/delete courses at anytime.
all I need the Ed Advisor role to do ....
Ed Advisor role? I never mentioned an Ed Advisor role. I mentioned two roles:
You original post said that ed advisors needed access to the Courses/Add/edit courses menus. From this, I deduced that they needed to be ble to Add and Edit courses. Probably not an unreasonable assumption. Now you say They will not add/create/delete courses at anytime, which seems to contradict your original post.
This discussion has gotten sufficiently tangled that it needs to start over. Make a list of the responsibilities that you want to give to ed advisors.
Ed Advisor role? I never mentioned an Ed Advisor role. I mentioned two roles:
- Course creator -- a predefined role
- Account manager -- for adding new accounts to the system
You original post said that ed advisors needed access to the Courses/Add/edit courses menus. From this, I deduced that they needed to be ble to Add and Edit courses. Probably not an unreasonable assumption. Now you say They will not add/create/delete courses at anytime, which seems to contradict your original post.
This discussion has gotten sufficiently tangled that it needs to start over. Make a list of the responsibilities that you want to give to ed advisors.
Ok, no problems, here's the scenario.
We have education advisors whose job it will be to create a new user manually in the system, and assign them to a class. They will then send the login details out to the student so they begin studies.
I don't want to give them all of the Site administration functionality, so what i thought I would do was duplicate the Administrator role, and remove relevant permissions from this so that all is left is the ability to create/update/view a user, and secondly, from a course perspective, add them to a class.
Cheers,
Grant
We have education advisors whose job it will be to create a new user manually in the system, and assign them to a class. They will then send the login details out to the student so they begin studies.
I don't want to give them all of the Site administration functionality, so what i thought I would do was duplicate the Administrator role, and remove relevant permissions from this so that all is left is the ability to create/update/view a user, and secondly, from a course perspective, add them to a class.
Cheers,
Grant
Very good. Education advisor responsibilities:
For requirement 2, create a new role called CanAssignStudentsToCourses with moodle/course:view ("View courses") = Allow and moodle/role:assign ("Assign roles to users") = Allow and all other permissions Not set. Make an entry in the Allow role assignments table, allowing CanAssignStudentsToCourses to assign the Student role. Assign the role to education advisors in either the System context or in a category context.
For requirement 3, no additional permissions are needed (the education advisor gets the information needed to notify the student when creating the account and enrolling the student in the course).
It is a terrible idea to copy the Administrator role (or any other predefined role for that matter). You want to give the user the fewest permissions needed to do their job. For this problem, it turned out to be a very small number of permissions -- fewer than 10. Why start with 200 and undo 190 of them, when you can start from a clean slate and add just the ones you need? If you do the former, you'll almost certainly end up giving too many permissions, which will have unintended side-effects.
- creates new users manually
- assigns them to courses
- notify students of course assignment (notification will include instructions how to login, enroll in course)
For requirement 2, create a new role called CanAssignStudentsToCourses with moodle/course:view ("View courses") = Allow and moodle/role:assign ("Assign roles to users") = Allow and all other permissions Not set. Make an entry in the Allow role assignments table, allowing CanAssignStudentsToCourses to assign the Student role. Assign the role to education advisors in either the System context or in a category context.
For requirement 3, no additional permissions are needed (the education advisor gets the information needed to notify the student when creating the account and enrolling the student in the course).
It is a terrible idea to copy the Administrator role (or any other predefined role for that matter). You want to give the user the fewest permissions needed to do their job. For this problem, it turned out to be a very small number of permissions -- fewer than 10. Why start with 200 and undo 190 of them, when you can start from a clean slate and add just the ones you need? If you do the former, you'll almost certainly end up giving too many permissions, which will have unintended side-effects.
Hey John,
I think we are getting closer
I followed your instructions, however, this is what the admin menu for the ed advisor looks like (see image 1 in doc attached)
The table looks like this (see image 2 in doc attached)
What am I missing here??
Cheers,
Grant
I think we are getting closer
I followed your instructions, however, this is what the admin menu for the ed advisor looks like (see image 1 in doc attached)
The table looks like this (see image 2 in doc attached)
What am I missing here??
Cheers,
Grant
The Site administration is exactly what I expected. I can see that you assigned the CanAssignStudentsToCourses role in the System context. That's why you have the Front Page sub-menu. If you had assigned CanAssignStudentsToCourses in a category context, it would not be there. Not a big deal, but realize that your ed advisors can assign students to the front page, which is beyond the scope of their responsibilities, and why I suggested assigning the role in a category context).
So what's the problem? This is exactly what you want. The ed advisor uses the Site administration -> Users menu to browse/add/delete/upload users. To assign students to courses, the ed advisor must go to the course (any course). I can't see what the rest of your front page looks like, but maybe there's a course list or a combo list. Have them click on any course.When they get to the course, they will see a Course administration block with an Assign roles link.
So what's the problem? This is exactly what you want. The ed advisor uses the Site administration -> Users menu to browse/add/delete/upload users. To assign students to courses, the ed advisor must go to the course (any course). I can't see what the rest of your front page looks like, but maybe there's a course list or a combo list. Have them click on any course.When they get to the course, they will see a Course administration block with an Assign roles link.
Fantastic John, thanks for that. For some reason I was expecting the add to courses functionality to be on the site menu, but understand it's at the course level.
Thank you very much for help in resolving this.
Regards,
Grant
You're welcome!
Hey John,
One final question - could I not just create 1 new role called Educational Advisor to replace the Account Manager and CanAddtoCourse roles?
Grant
One final question - could I not just create 1 new role called Educational Advisor to replace the Account Manager and CanAddtoCourse roles?
Grant
You could, but the two-role solution is a better design than a single fat role. My design criteria are (1) giving the fewest permissions needed to satisfy the requirements (2) giving each permission in the lowest possible context (3) reusability of roles (3) maintainability of the design as requirements evolve.
The two roles have completely separate concerns (registering, enrolling). Each one of them is inherently reusable. For example, suppose you get a new requirement tomorrow for a "teacher registrar" who (1) registers teachers and (2) assigns teachers to courses. You already have (1), so you only need one new role. If you make fat roles, then you will end up with two fat roles with redundant components (the registering part). If you decide to change the registering permissions, you must make the same change in two roles, rather than in one.
Two roles can be assigned to the same user in different contexts. A fat role must obviously be assigned in a single context -- in your case, the System context. I recommended assigning CanAssignStudentsToCourses in category context to avoid the nasty Assign roles link on the front page.
If the requirements change and you need to add responsibilities to the education advisor, do it by defining new roles and assigning each of them to the advisors in the appropriate context. You can give some advisors more responsibilities than others. You can't do this with a single one-size-fits-all fat role.
You can't really appreciate the advantages of a multiple-role solution as long as you have a static view of requirements.
The two roles have completely separate concerns (registering, enrolling). Each one of them is inherently reusable. For example, suppose you get a new requirement tomorrow for a "teacher registrar" who (1) registers teachers and (2) assigns teachers to courses. You already have (1), so you only need one new role. If you make fat roles, then you will end up with two fat roles with redundant components (the registering part). If you decide to change the registering permissions, you must make the same change in two roles, rather than in one.
Two roles can be assigned to the same user in different contexts. A fat role must obviously be assigned in a single context -- in your case, the System context. I recommended assigning CanAssignStudentsToCourses in category context to avoid the nasty Assign roles link on the front page.
If the requirements change and you need to add responsibilities to the education advisor, do it by defining new roles and assigning each of them to the advisors in the appropriate context. You can give some advisors more responsibilities than others. You can't do this with a single one-size-fits-all fat role.
You can't really appreciate the advantages of a multiple-role solution as long as you have a static view of requirements.
Thanks John. Great advice!
Cheers,
Grant
Hi again John,
One thing I have discovered as a result of all of these new roles is that anyone of up to 13 ed advisors may have the responsibility of adding the user to a course. As such, when you go into participants, you see all of these people listed as part of the class, which is very confusing for the students as well as for the tutor who may say, want to send an email out to the whole class etc.
Is there anyway of not displaying these ed advisors in the Particpant's list?
Cheers,
Grant
One thing I have discovered as a result of all of these new roles is that anyone of up to 13 ed advisors may have the responsibility of adding the user to a course. As such, when you go into participants, you see all of these people listed as part of the class, which is very confusing for the students as well as for the tutor who may say, want to send an email out to the whole class etc.
Is there anyway of not displaying these ed advisors in the Particpant's list?
Cheers,
Grant
Hi Grant,
You can prevent ed advisors from being displayed on the participants list by making them hidden assignments. Please see the section on hidden assignments in the assign roles documentation for more information.
You can prevent ed advisors from being displayed on the participants list by making them hidden assignments. Please see the section on hidden assignments in the assign roles documentation for more information.
Fantastic Helen. Thanks heaps!
Grant
Is this still possible in 1.9? There aren't as many options in the User section. I tried it and checked similar functions in the "system" section but I was not able to make it work. Need the solution now but will also be ugrading to 2.0 in the next few months.