Yesterday Martin reminded me that it was good practice to write down what you are planning to do before you do it, so that people can see what you are proposing and suggest improvements before it is to late. Therefore I wrote
If you are a regular reader of this forum, then you will know where most of those ideas came from! We have just tried to take the best of the suggestions and ideas that have emerged from the community since roles were released in Moodle 1.7, and make time to actually do them!
Hopefully this addresses most of the significant roles usability issues. If you think we have missed anything, or if you think and of our ideas can be improved, please tell us! I would particularly value comments from teachers who have grappled with roles, and people who have to train teachers to understand roles, but comments from everyone are most welcome.
Thank you in advance.
At present one must open the activity for updating and then click the roles tab.
Consider an override permissions icon also (visible by role as appropriate, this may be a bridge too far for complexity).
Override icon: Yes, probably.
These are a few things that spring to mind working with lots of real users:
* Most of the roles related terminology (that you mention at the start of the docs page) is meaningless to 'normal' users (read 'teachers'). They should not be subjected to it. In particular 'override' has to go!! It means nothing to teachers and actually (effectively) hides additional functionality.
* The user context is mysterious to almost everybody. It should be very well hidden or (even better) be made hideable by the admin. Currently most users I have seen intuitively assume roles are applied to users, not the other way round, and the User context promotes this idea.
* It's got to get a whole lot harder to break stuff with roles. I think it's a mindset thing, "what can happen if the user does this?". Some additional warnings may be prudent.
* Roles need to be watertight at the course category level. Most of this is nothing to do with roles though, it's missing or dodgy bits of UI. Being able to split up complex sites using Course Categories and Roles is a powerful feature but it's half a job at the moment.
* New feature... move users from Role A to Role B in a context. I see people needing to do that a lot, and if you have loads of users it's a major pain.
* I'm not sure if any of your changes feature this, but it would be nice to be flagged if you assign a user to a role but they are already assigned to a role in a different (or same) context that might affect this. (e.g., making a user a student when they are already a teacher in the same course or already an admin for the site)
* Assigning users to roles as hidden is very clunky, if you even notice the option at all.
* The User Policies administration page (mostly about role defaults) is a minefield of site-breaking potential. I'm not sure what I want to say here but this might need some dire warnings added or simply rethought so it isn't needed.
That's all I can think of for now...
1. What would you suggest instead? And since roles have now been there for over two years, asy suggestion would have to be dramatically better to justify the pain of changing.
2. Once the user's roles report is in core, that will be the first thing you go to when you click on the Roles tab in the user profile. And because of MDL-8312, the sub-tab that lets you assign roles in the user context will not appear, until the admin creates a role like Mentor or Parent that can be assigned in the user context.
3. You need to be more specific. We can only fix specific problems. Making it impossible to change doanything, or for admins to unassign themselves, will remove two of the biggest gotyas.
4. There are a whole bunch of bugs to do with roles at the category level, mostly to do with editing and moving categories. They are all assigned to me and targeted at Moodle 1.9.4, which is why they do not appear in the roadmap.
5. This is the first time I have heard of this feature request. Acutally, no, it isn't. It already exists. Look at Admin -> User -> Accounts -> Bulk user action.
6. Perhaps like in the groups page, where it puts the number of groups a user is already in next to their name. Will consider.
7. What do you suggest. I suppose the checkbox shoud stay checked when you click Add or Remove. Will do.
8. Again, we need specific suggestions.
1. I think somebody else mentions it in the thread, but the current reference to "override role" when what you *actually* mean is to find some more options for the activity is completely opaque to teachers. A simple "advanced" button/tab (or similar) would be much better IMHO. I'm sorry but the 2 years thing strikes me as a bit odd. If something has been wrong for two years so that nobody uses it, is that a valid reason for not fixing it? Some of this is subtle and I've been shouting for a long time - teachers don't understand roles, won't learn it, shouldn't have to, so what can we tweak/change to help? Sure, I can spend some time and make more specific suggestions but if everybody thinks I'm mad (possible, granted ) there's not much point.
3. Good, yes. I think I meant, "please somebody care about this!". Roles are complicated and can get people into a real mess. If you see an oportunity for a helpful message or warning....
4. Ok, excellent.
5. Learn something new every day etc.. I'm not sure that's in the most intuitive place...
6. I never really liked that "magic number next to..." thing. I'd settle for a little warning icon and a short "this user has previous role assignments that may affect this assignment" (you can think of something better I'm sure) message.
7. The annoyance is when you assign a bunch of users and then remember that they should have been hidden. I'd simply like to select them in the "enrolled" side of the tab and make them hidden/unhidden. BTW... while I think about it, when users are displayed (as hidden) it causes confusion to teachers. Rather than greyed out a bit of old-fashioned text saying "these users are hidden" might work better.
8. From posts in the forums, I've seen a lot of people getting into trouble by changing these settings to something silly. The cool thing would be to display a "do you realise this will make everybody an admin everywhere...." (for example) if they do a particular thing. However, just as effective might be "don't change the settings on this page unless you really know what you are doing". It have an idea that, perhaps, admin pages should be graded from "mostly harmless" to "don't press the red button"
Point 5. I did, it isn't there.
1) To enable the creation of simple checkboxs/drop downs for teachers - these set over rides in the background for the current context - but the teacher just sees a simple 'let students reply to this forum' checkbox.
2) Make an interface for administrators to add/delete/modify these using roles.
IMHO, some of the 'role improvements' still seem to assume that teachers will want to learn how the software works (thus we just need to give them more information) w/as IME, most teachers want to teach using the software (thus we need to give them a simple interface for new users, which can "easiliy"* be expanded by advanced users).
*without writing code.
This confuses as it's mixed up with thoughts about the Assignment module.
"Hidden role assignment" would be an improvement. Also a label in the interface that signals what the check box is for would be most helpful.
IMO the terminology used on a rather mix n match basis at the moment. Enrolment is really a pre-1.7 concept, post 1.6 users are assigned to roles. The course settings page hasn't really caught up with this. An example is Enrolment duration which is present in 2 areas - are Teachers "enrolled" on a course?
* Get rid of rename roles in a course (it doesn't work properly anyway) and replace it with the ability to change the role name for individual users in a course (it just needs an option in the "People" block, surely?). I think that's what users really wanted (a long lost pre-roles feature).
I thought the issues with course settings role aliases had been fixed.
The current name change thing is very restrictive. It *might* work if you could also alias a role within a course but, unless I'm missing something, you can't.
Really what people want is to simply be able to specify their title within the course they are teaching in. To allow them to do it themselves would *really* be the answer - simple and intuitive for users
I meant Role renaming in course settings
Anyway, I don't want to dilute my original point that, IMHO, it would have been much better (simpler even) if permitted users could simply change their own role name within a particular course or even context. I've actually yet to find a use for the current course based name customisation in the real world.
At the moment, it's boring and so time consuming to create n pupils' parents each year !
As a teacher and my school's Moodle administrator, I would like to create pupils' parents semi-automatically : relatively to newly created pupils list, press the button "create Parents", choose one or two parents, automatically enter the first name as "Parent, father or mother or tutor" by default, Parent's Name as pupils' last name +" "+ first name by default, mail address with the pupil's adress by default and go ! the system creates the selected pupils' context role link and default data.
Any other better means to complete the task welcomed .
Thanks to consult us.
OK I sat and read and re-read your so called improvements paper the other evening and thus am even more confused now about roles than I was in the past.
Historically we had an administrator - me, teachers - people who teach and students - people who learn and guests that we never ever used. That was all we ever really wanted or needed here in my small FE college. Now I accept that there are lots of other people who may have other needs and wishes, so presumably that is why Roles were created in the first place; but from our perspective all of our former teachers, who could 'invite' other teachers into their classrooms and invite students into their classroms very early in the year before MIS had managed to catch up with the register system now can't. By this time of the year - everyone had settled down and was doing their thing and the overnight .csv of staff/student changes was broadly empty, so the three key 'functions' (now called Roles) had served their purpose.
The introduction of Roles two years ago has meant that teachers are now not able (without a lot of messing about) to invite other teachers into their classrooms, course creators has given too much power to people who abuse it, non-editing teachers can achieve nothing meaningful - but is the only role permitted to teachers to give to others and becuase of all that kerfuffle two years ago students ceased to use what they viewed as a disfunctional Moodle, and unless we are very careful that problem may arise when we shift to version 2.0.
The solution, adopted summer 07 and now with a full years effective trial behind it wasd quite simple really - I have one administrator - me
I have created a special role called course leader - which has all the old rights of an editing tutor (no longer really use the standard teacher role)
and I have stuck with the default student - because, by and large, it works for us and our learners.
Rest of the roles I consider to be useless from our perspective so they are not used anywhere in our system.
I have however this year created a new role - Head of Department (HoD)- the idea being that since each course is organised with a category - and each category is equivalent to a Department (if you are in a big organisation read Department as Faculty) then the HoD could oversee any class where the teacher was on a course or sick or whatever and could do their own statistics, but since statistics don't sub-divide at the category level, only the whole VLE or the course, that was a bit of a damp squib, although it does allow the HoD to visit any class, see the participants and support them if the teacher is off, so that bit is working well.
I think you will take my point, Roles may be very helpful to some but for us pragmatists who just have to work with them, three or four Roles is more than enough and this new and increasing complexity just seems to be complexity for the sake of complexity rather than handy things for real people in real colleges to use.
end of rant
P.S. can someone please look at finding ways of giving us stats at the category level pretty please ?
I also agree (as I said above) that functionality at the Category level is something of an opportunity lost currently.
In Moodle 1.6, there was a separate setting (teacherassignteachers) that controlled whether teachers were allowed to assign other teachers in their courses. In Moodle 1.7+ there is effectively the same setting, except that it has just become one of several check-boxes on the Allow role assignments page.
Still, nothing wrong with a good rant
Thank you for your comments Tim and especially for pointing out this very useful 'teacherassignteacher' option which, like so many things is obviously well hidden but now I know what to look for, I may well be able to find it. As ever of course, time is the crippler which is why signposts to these sorts of changes would be/are so incredibly helpful and why people like me don't know that we did not have to adopt the (from my perspective) difficult Roles idea and could have stuck with the old system. Anyway as you say - the HoD is useful so I will stay where I am but useful to know I didn't need to change - genuinely felt the old idea had been ditched when Roles came along.
Anyway thanks for listening and bothering to reply to a rant - many would ignore such an approach. And again if any development of categories could be raised up the agenda I would be very happy.
A common complaint I here is the lack of ability to limit certain activities to just be used by one group. I see group based overrides as a possible (if not necessarily easy) way of achieving this.
Several of the comments make it clear that we have not stated what our goals are here. How usable do we hope to make the roles system? This is certainly a vital question.
Thinking about setting goals reminded me of about the bit about usability requirements in Mastering the Requirements Process (which I studied as part of OU course M883 Software requirements for business systems - good course if you have the time and money - or good book in its own right - sorry end commercial break). The two relevant bits are:
1. Rather than just talking about 'Usability' it is more helpful to distinguish 'easy to learn' and 'easy to use', or in other words learnability and efficiency. These are not mutually exclusive, they are just different aspects of usability with different implications, so it is helpful to consider them separately.
An example of a system where learnability is key is and ATM, where you go to get money out of your bank automatically. You just walk up to it in the street, and you aren't going to read a manual before using it. What to do should be entirely self-evident. And it says on the screen: 'Insert card'. So you do, and it guides you through the process making it very clear what you have to do at each stage. Actually, 'Insert card' is the convention I am used to from the UK. In a lot of Australian ATMs you have to 'Swipe your card through the slot', but I don't have any trouble using them becuase it tells you that on screen.
An example of a system that needs to be easy to use is my Eclipse IDE. I use it all day, every day, and what I care about is how efficiently it lets me get the job done once I have mastered it. I am happy to invest some bits of time reading parts of the manual, learning keyboard shortcuts, and adjusting the preferences because the time I spend learning and understanding the system saves me time in the long run. The same sort of consideration applied to other complicated applications like Photoshop, which a graphic designer might use all day, every day; or a fighter jet, where you would not expect to fly one without extensive training, but then you need to have split second control over it. (That is a really extreme example.)
Of course a learnable system should not be inefficient. Having to go through lots of unnecessary steps on an ATM would be a pain, that is why there is normally a button to withdraw $100 in a single action after you have typed your PIN. And an efficient system with a big learning curve should still provide you plenty of clues so you can work out how to scale that learning curve on your own with minimal effort - what people refer to as discoverability, progressive disclosure and so on.
2. The other concept is that you cannot specify your usability requirements without some idea who your users are. For our discussion, the key attributes would probably be:
- how computer/web literate are they in general?
- how much time are they prepare to invest in learning about roles in Moodle?
- how do they think about the concepts here? That is, the questions of who can get into which course, and what can they do when they get there. In particular, if you have users who have not used Moodle much before, what words do they use to describe these concepts and what is their mental model?
2. Moodle users are a very broad group in every respect. Most don't need to know that much about roles beyond e.g. this user is a student, students can do this and this. For those that do need or want to learn about roles finding a on size fits all collection of terms will be impossible IMO. Even seemingly similar organisations interpret the roles system differently.
Please don't make formslib any more insane that it already is
Tim, here are my answers to your questions:how computer/web literate are they in general?
From my experience as a Moodle instructor in Germany, the average teacher is not really that computer literate and has never seen a VLE in action before taking the 'Moodle-for-beginners'-course. One or two teachers per school usually get stuck with being admin and in addition to having to learn the basic functions of moodle they must also know the admin functions.how much time are they prepare to invest in learning about roles in Moodle?
It's not how much time they are willing to invest, it's how much time we are given to teach about roles. At the moment, we don't really have any time for that. (Our courses are taught during regular school hours, so there is a limit on how much time a teacher can be excused from class).
Most of the support calls I get have to do with roles - assigning roles in the wrong context, altering admin roles etc.
So here are my ideas: (Remember, I'm not a programmer, so I have no idea if this is even feasible)
For the novice users/admins, the default roles are more than sufficient as Neil mentioned above, so I would deactivate the users - permissons tab in the admin menu. The admin would not even know that roles can be altered and global roles can be assigned. By default the teachers should be given the right to invite other editing teachers to their course. All of this would be a sort of 'Moodle lite' (has been discussed somewhere else in the forum before, but I can't find it any more).
Then, as the admins become more proficient, they could activate a 'roles' tab (maybe under site policies) and then the 'users - permissons' would show up.
Don't get me wrong - I personally like the roles options and I have created some nice new roles for my school, but I also realise that for a novice user the system must be almost as easy as using an ATM (I like this analogy).
Already in Moodle 2.0, Petr Skoda collected has together all the options for the features you can turn on and off (like groupings, outcomes, RSS feeds, blogs, ...) into a single page called 'Optional subsystems' at the top of the admin tree, just under Notifications. (That may not be the best name, but we agonised about it for hours and could not think of anything better. Suggestions welcome.) So, a 'Configurable roles' would be a natural thing to add to that page.
I guess that would hide everything to do with defining and overriding roles, leaving just role assignments, and perhaps some of the new diagnostic tools, like the users roles report.
In 2.0 we are already planning to change it so that by default you can only assign the roles of admin and course creator in the system context, and you need to be able to do that, so it would be a mistake to remove system role assignments.
I would leave in category and activity level assignments too. By default you will only be able to assign course creators at category level, and that is useful and easy to understand. And at activity level, there are some useful things you can do by assigning a particular user Non-editing teacher rights (The first 4 of Helen's 12 useful things a teacher can do with roles: Useful_things_a_teacher_can_do_with_roles.
Optional doesn't mean "you can break stuff if you go here". That, surely, *has* to be implicit or there's not much point. It sounds a bit poncey too (sorry!).
Because they are not really "advanced".
- Administrator at system level only makes sense
- Course creator at system and category level are a sensible default (not system level only)
If you create too many "special case" defaults this will create an additional level of complexity to decipher and, potentially, unpick.
Teacher who just wants to teach: They need to be able to add Students and Non-editing teachers to their course with essentially zero training, other than having it mentioned as something you need to do as part of setting up your course.
Moodle admin of a basic site: This is the sort of example that Ulrike Montgomery mentioned, the teacher who is volunteered to be a Moodle admin. In addition to what teachers have to be able to do, they also need to be able to assign other admins and course creators, again with minimal thought.
My third category is a bit less clearly defined. It is people who need the functionality that roles makes possible. Some examples would be a school admin who has to set up a Parent role, or slightly adjust the default roles; a teacher or learning designer who wants to set up some interesting sequence of activities with people in different roles; and so on. They key thing here is that these users have a goal of their own, so they have an incentive to start learning about roles. For them, we need to make the learning curve as smooth as possible. For example, if you want a Parent role, you can Google it, and follow some fairly simple instructions on Moodle docs. Most of the diagnostic tools I am adding to Moodle 2.0 are aimed at this group, making it easier for them to work things out on their own, but being able to clearly see the consequences of the settings they change.
I think that with the idea of having a turn on/off configurable roles switch, and with our other proposed changes, we are not far off meeting these people's needs, with two exceptions:
1. Some of the wording could be improved, but it is hard to think of better wording. For example, "Assign roles", could be "Give users access", or "Let users in", or "Enrol students" (even though that is what you click to enrol other teachers too?).
2. Specific options that were lost from Glossary, Forum, etc. because they were replaced by role overrides. Does anyone have a list of these? I don't know what they are. Anyway, I think we should replace them as settings on the activity settings page that set up overrides behind the scene (teachers don't need to know that). But to do that, someone will have to give me the list of features we lost.
Why wouldn't the want to be able to add other teachers too?
1. Some of the wording could be improved...
Caution is required about making the changes too radical and creating an additional learning curve.
Forget any changes that include the word "users". "Users" is not a term that resonates with any teacher, trainer, instructor, facilitator I have met, it's terminology that is used/acceptable to administrators and programmers.
2. Specific options..
OK, but if this isn't to create confusion in the re-instead version you will need to include the ability to configure which roles these settings apply to. Pre-roles they we targeted at e.g. Students this will be meaningless if the course employs alternative roles.
And 'Adjust permissions' or 'Adjust capabilities' instead of 'Override permissions'? - that is my current best effort.
Also, no one has responded to my plea for a list of those options that have disappeared from the various activities, to be replaced by capabilities. I don't know, and unless someone tells me, I won't be able to do anything about it.
The only second thought I have is that Participants normally refers to students, people taking courses in general, whereas the managing aspect refers also to Teachers and other users. On the other hand, teachers are also participants from the perspective of administrators, and Manage participants surely beats Assign roles. Manage users would be too computerish.
I've commented further in the tracker at: MDL-17234
"Assign role" is at the heart of much confusion IMO as, correctly, users are assigned to a role.
Why not simply "Roles"?
The problem with roles, is that I cannot imagine a Teacher spontaneously using the word 'role' in this context. I can imagine them thinking things like 'I want to give students access to my course,' or 'I want to make Sarah an assistant Teacher in my course'. No, unfortunately, we can't use the words Student or Teacher, because we don't know which roles exits in the system. That is how I got to the word Participants.
Actually, having just typed the paragraph above, I can see that 'access' is a good potential word. How does 'Manage access' sound? (I really wish we have a good way to usability test these things with some real teachers.)
The other options would be to put the Groups-related tabs in the same tab-bar, so the Manage participants link did let you do all the things you would expect. (You could still leave the direct Groups link in the course admin block for convenience.)
Also "access" doesn't work for an activity in a course or a category for example and we need consistent terminology.
I understand your point about the type of terminology used but your examples are school based (I know they're only examples) where Moodle is used in many sectors.
"Roles" is generic and describes the functionality that is being accessed.
"Roles" matches the existing convention of a single word link.
There may be a case for combining the manage "participants" options but personally I think they should be left as they are.
OK. I have to admit that if I put on my techie shoes, I prefer roles, particularly that in that role, pun intended, I function only in English (as opposite to a few other languages as a user). Let's keep in mind that we are talking about the interface for end users not us techies.
I work with non-technical users across sectors all the time. "Participant" is used to describe people in a student / learner type role.
If we use a simple term like "Roles" then it's meaning is clear and it can be clearly interpreted across any sector.
The interface is used to manage roles - clicking "manage participants" to deal with roles adds another level of interpretation that is required i.e. teachers etc. will have to learn that manage participants means manage roles. Crazy!
I suspect this whole area of Moodle functionality is called "Roles" rather than "Participants".
Also we need a common set of terms that make sense in every (Moodle role) context.
No matter how many times I say it to my self "manage participants" doesn't make much sense when I think about managing roles for a category.
Sorry to be so strident here but the proposed tweaks here will achieve the opposite of their intention if care isn't exercised.
Me sitting here in a room full of developers am in the worst position to get this right. I want input from as many people as possible; and I want people to speak up and stop me if they think I am going to make a mistake.
That being said, it would be nice if the end result of the discussion was some sort of consensus. But actually implementing whatever is decided is easy, and can happily wait until much closer to the 2.0 beta release.
Risking going slightly off topic, But I hate "Create text page/create web page" for the same reason. While technically I understand that a page with markup language in it is a "web page" by definition. But it just confuses teachers. Do we realy still need a "text page" resource? Is there a more common sense term we could use?
I now return you to the scheduled discussion at and.
Absolutely concur with Ray here with regard to teachers enrolling other teachers as the default. Whilst we could invent a new 'course leader' role - the reality in this college is that we use the LDAP, auto enrol process to upload the course leader = lead teacher of any new course and then it is their job to enroll (as teachers) any other teachers in their course team into their Moodle classroom.
Slight aside: The function of non-editing teachers has always been a bit of a non-sequitur - teachers who can't edit, cannot effectively teach in any meaningful manner, and whilst this role may have a function for, and in this college has been tried with, for example learning support assistants, tutors, monitors, students acting in some 'higher' capacity or whatever, but whatever those people are doing, they are implicitly not acting in a teaching capacity and so cannot be non-editing teachers although obviously they can easily be non-editing members of the course - which I think is another way of describing students !!
I'm sorry that I'm not going to be able to agree with you on all of your post.
Regarding the non-editing teacher role. I think it's perfectly feasible for someone to teach within a framework that has been devised by another. Although they may not be able to add, delete or modify the nature of the course resources or activities they should be able to engage with the students in a manner that is flexible and pertinent to that cohort. Of course this relies on the standard of the course design on the first instance.
My third category is a bit less clearly defined. It is people who need the functionality that roles makes possible. Some examples would be a school admin who has to set up a Parent role, or slightly adjust the default roles; a teacher or learning designer who wants to set up some interesting sequence of activities with people in different roles; and so on.
A term I've just seen used in another system I'm working on here that might apply is System Designer. I can certainly recognise the three levels you outline in our institution (actually in a larger installation like ours we probably have four because we have departmental administrators between teachers and Moodle admins).
Like Ulrike a lot of our support queries are about participants and permissions many of which the requestor could do themselves. I am not sure whether this is because Teachers don't have the time or inclination to engage with roles, (something they may see as an administrative function), or because these features are hard to use.
Our Moodle Admins are very computer literate but they only really want to understand the roles we use, and how we use them in our setup, rather than engage with Moodle 'roles' as a concept of function. I agree the way Roles are exposed to them should be much simpler.
Which leaves your third category which is where analysis/design comes in. this group needs to fully understand the Moodle Roles architecture and functionality and how best to translate it into their Moodel organisation's usage. For many this will be the old legacy defaults, very stripped down. For other like us it might involve a high degree of customisation but the ability to ease this learning curve would be good.
One thing that might be useful is to be able to extract, or easily document the roles structure. I know you can duplicate roles, but the ability to export and import roles might make it easier for people to share their configurations and document the business rules decisions that go into them. I like to create a printable guide to the permissions assigned to each role as reference outside the system and to help with decision making and training. In addition to the contextual help mentioned it's often useful to explain these things outside the system.
I would like to see a printable guide/report, as well. Or, looking at A's verb tense, does this capacity already exist?
I have admin role in our Moodles, and it makes me very uncomfortable to be looking at live permissions just to see what a role can/can't do, might or might not be enabled to do.
2. Specific options lost
- Student Posting
- No discussions, no replies
- No discussions, replies allowed
- Everyone can rate/Only Teachers rate
- Students view everyone's ratings/Students view own rating
I can't remember if we had something similar for ratings in Glossary and Database, but that would make sense.
Speaking of Student Posting, one improvement I'd recommend for the next version of Moodle would be...
Bring back the ''No discussions, no replies" dropdown menu (in 'update forum').
In our courses, we have to turn forums on and off regularly. It used to be so quick and easy, but now I have to muck about with permissions. Can't we have both?
Assign roles to a group, instead of individual users. so all members of that group should get the privileges associated with that role
A couple of observations/suggestions.
References to "has_capability" should ideally be rewritten to make them more friendly to non-developer users. I don't have time to think about alternatives at the moment but if you want to throw this around in the tracker or here I'm happy to comment.
I can guess why you've set the context order as you have but it's counter intuitive as it currently stands i.e. the highest context should be at the top of the table.
Anyway, would the interface that I mock up on Development:Redesigning_the_override_roles_page make the override role concept more understandable by more people?
1. We are a UK secondary school, about 1000 students, 90 teachers.
2. I am an IT technician and the main moodle admin. Active directory is used to authenticate logins. Users and initial enrollments are done in bulk each year.
3. I am the only person to worry about roles - I dread to think about a staff meeting where I might have to introduce moodle roles. I would be looking at a sea of glazed eyes.
4. I do spend time reading forums - but it's not my main priority
5. I know I don't understand roles well. For example I don't understand why a system course creator shows up as a participant in all courses. (I know this is discussed somewhere else - I just use it as an example.)
6. I've created one new role I called scholar - for a small group of youngsters who have teacher's permissions in one particular course. They can do (almost) anything in the context of that course.
7. I support the idea that changing roles is 'advanced', or rather, should be labelled as avanced.
8. The existance of the remarks about users being assigned to roles, rather than the other way about is imho evidence that ordinary teachers should not have anything to do with roles.
If an course creator creates a new course by default he wil be assigned to this course as a teacher to have editing rights. This is defined in "users>permissions>user policies -> Creator's role in new courses = Teacher".
As far as i understand this is just an automatical done lokal role assignment, so it should be visible within the courses lokal roles. But it isn't, so in past i often lost the overvierw.
Also it should be possible to see wich role/capabilities i have at any point in the system. On my system i have installed the module "me" that shows me my actual role. But, it's only on course level and if i don't have access to a certain course i can not find out my role/capabilities.
Also there should be something like a role-debug-mode, administrated by the administrator, which allows me, if switched on, to see all my capabilities and roles and from which role wich capabilitie is inheritet and so on. This should be possible for all courses and categories even if i have acces or not.
This would make the role debugging much easier to the administrator.
Also there should be something like a role-debug-mode, administrated by the administrator, which allows me, if switched on, to see all my capabilities and roles and from which role wich capabilitie is inheritet and so on.
Yes - you can in Moodle 2.0 You can check the permissions of someone to see what they are and what they are not allowed to do - and you can also run a Capability Report to see which roles are allowed (or have been overriden to be allowed) to do certain activities.