I suddenly find myself in the position of needing to convince a large group of Moodle users to learn about Roles and Capabilities. Can you help me put together a "top ten" list of reasons? My audience consists of both teachers and admins who have been using Moodle since 1.5. They recently upgraded to Moodle 1.8, but are not yet using any of the Roles and Capabilities features.
Hi John,
Somewhere in the documentation on Roles, we made a nice list of scenarios/cases where new roles would be needed. That will be a good starting point. Some other examples I have used are...
Somewhere in the documentation on Roles, we made a nice list of scenarios/cases where new roles would be needed. That will be a good starting point. Some other examples I have used are...
- allowing students to create quizzes but not enter the gradebook
- allowing students to edit their forum posts indefinitely
Hi Don,
I really appreciate your reply. I have seen the items in docs that you mentioned, but I'll review them again. I was actually looking for some very high-level reasons (I'll settle for three
. "Achieve greater flexibility" is certainly one reason, but many will say "We already have all the flexibility we need," and I need more compelling reasons to use with them. For example, would it be fair to say that in the future, new activities will require parameterization through capabilities? I'm thinking of the evolution of Forum, in which parameters like "Students can rate posts" have been removed from the Forum settings, forcing you to override Student to get pre-1.7 behavior.
I really appreciate your reply. I have seen the items in docs that you mentioned, but I'll review them again. I was actually looking for some very high-level reasons (I'll settle for three
I'm afraid that any reason you can give for using roles basically reduces to 'Achieve greater flexibility'. But really that is a million reasons.
In the past, it was fixed: Only a teacher can do these things. Students should only be allowed to do those things. The only way you could change that was to change the code - with the exception of a few places like forums where options had been added manually. Of course, the pre-programmed roles were well designed, so most of the time, this inflexibility did not get in the way.
Now, teachers and administrators have the flexibility to decide what things whey want particular categories of users to be able to do. Of course, you still have the same tried and tested defaults, but when you want to step beyond them, you just have to twiddle some configuration settings. Don't want students to see their grades on this course? Tick. Want a few trusted students to moderate that forum? Tick. The possibilities are limited only by the teachers imagination. As I said above, there is only one reason for roles, but it is really a million reasons.
I've just finished reading the 2nd Edition of Helen and Jason's book (http://docs.moodle.org/en/Using_Moodle_book). In every chapter, they talk about the relevant capabilities, and ways you might want to override them. (John, I know you are an expert Moodle user, but I would recommend you get hold of this book - you probably want copies to leant to the teachers you are training - and then read it yourself first. It will tell you lots of things you already know, but the 'Effective Moodle Practices' section in each chapter has a lot of good ideas that it is worth reminding yourself of.)
Above, I say 'limited only by the teachers imagination'. I have to admit that that is not totally true. I think we are still slightly hampered by the user interface for managing roles. It keeps getting better, and it is certainly much better in 1.9 than it was in 1.7, but I think everyone agrees that there is more work to do.
In the past, it was fixed: Only a teacher can do these things. Students should only be allowed to do those things. The only way you could change that was to change the code - with the exception of a few places like forums where options had been added manually. Of course, the pre-programmed roles were well designed, so most of the time, this inflexibility did not get in the way.
Now, teachers and administrators have the flexibility to decide what things whey want particular categories of users to be able to do. Of course, you still have the same tried and tested defaults, but when you want to step beyond them, you just have to twiddle some configuration settings. Don't want students to see their grades on this course? Tick. Want a few trusted students to moderate that forum? Tick. The possibilities are limited only by the teachers imagination. As I said above, there is only one reason for roles, but it is really a million reasons.
I've just finished reading the 2nd Edition of Helen and Jason's book (http://docs.moodle.org/en/Using_Moodle_book). In every chapter, they talk about the relevant capabilities, and ways you might want to override them. (John, I know you are an expert Moodle user, but I would recommend you get hold of this book - you probably want copies to leant to the teachers you are training - and then read it yourself first. It will tell you lots of things you already know, but the 'Effective Moodle Practices' section in each chapter has a lot of good ideas that it is worth reminding yourself of.)
Above, I say 'limited only by the teachers imagination'. I have to admit that that is not totally true. I think we are still slightly hampered by the user interface for managing roles. It keeps getting better, and it is certainly much better in 1.9 than it was in 1.7, but I think everyone agrees that there is more work to do.
Thanks for your comments, Tim. I haven't seen the new Cole and Foster. It sounds like a good reference.
Flexibility is an obvious selling point, but not strong enough to convince the holdouts. Roles came with the guarantee that "Moodle will operate exactly the same before and after the upgrade" (from the Moodle docs article Development:roles). As a result, there are a lot of people who were quite happy with the way Moodle 1.6 worked and are only upgrading to stay current with bugfixes, etc. One user with YEARS of Moodle experience told me
"However I am finding the roles & capabilities system very confusing in Moodle and I try to keep away from them as much as I can. Also I have little use for them except from time to time."
Flexibility is an obvious selling point, but not strong enough to convince the holdouts. Roles came with the guarantee that "Moodle will operate exactly the same before and after the upgrade" (from the Moodle docs article Development:roles). As a result, there are a lot of people who were quite happy with the way Moodle 1.6 worked and are only upgrading to stay current with bugfixes, etc. One user with YEARS of Moodle experience told me
"However I am finding the roles & capabilities system very confusing in Moodle and I try to keep away from them as much as I can. Also I have little use for them except from time to time."
I need arguments to convince these people that they are living in a fantasy world. But maybe they're right and I'm the one living in the fantasy world
"I need arguments to convince these people that they are living in a fantasy world..."
If roles were so wonderful and valuable, you would not need to convince people...roles would sell themselves and that's simply not happening. The fact that you feel people need convincing says a lot about their perceived value.
Yes, people are going to be required to use them to some extent if they want basic functionality, but the entire system is so complicated and counter-intuitive that convincing people they "need" to use roles may be a lot easier than convincing them to spend the considerable time it will take to learn and understand roles. I don't know anyone around here that knows roles better than you John. I would bet that you have spent untold hours studying, experimenting, thinking, analyzing, all in an effort to make sense out of the roles system. No teacher I know will spend even a fraction of that time trying to understand this. I think you would agree that a person could do some "serious" damage by clicking the wrong checkbox in a role. If people are going to use them (especailly site admins and role creators/editors), they have better understand them well.
This doesn't even touch on the problems with knowing what any particular role can and can't do in a given context...imagine having two admins on a Moodle site and one of them walks in one day and says, "Oh, by the way, I was experimenting with roles the other day and made some changes just to see what would happen. I think I got them all back to their normal settings." That would make me a little uncomfortable if I was the other admin responsible for that system.
Roles was a good idea that was very poorly implemented. Developing a dozen or so, predefined roles instead of this "flexible" roles and capabilities system would have been a much wiser route. Roles are "administrator and tech geek toys" that has resulted in a major headache for teachers (and some admins) who want a simple interface.
Roles has resulted in tremendous complexity with little to no payoff for most users....that's simple fact...no fantasy involved.
Of course, those who don't like it can always go elsewhere...
My advice to teachers (and admins) who don't want to spend all their spare time fixing problems is use them when you must and only to the degree that you must. Teachers will need to do some overrides to get back some basic functionality that was a simple drop-down or check-box selection in earlier versions. Anything more than that and you are taking a change of getting bit.
I'm not sure this exactly fits into your top 10 reasons, but if you want to add an 11th (oh, by the way), feel free to use any of this
Steve
Hi Steve,
I have heard your arguments before, and I agree with many of them. Even when I don't agree, I respect your opinion. But I still need seven (or is it eight?) more reasons
Roles are too complicated, and the payoff so far has been minimal, while the dangers from misuse are many. Roles were a much-needed change to the Moodle architecture, intended to give it greater flexibility and extensibility. It was such a fundamental change that a difficult transition was to be expected. I believe that in time, roles will get better, more useful, and easier to use. But a long as we are in this transitional period, I think people need to understand the current system, not bury their heads in the sand. The attitude of the person that I quoted in my last post is all too common. How can we convince such people, not necessarily that they need to "use" roles, but that they need to learn at least enough to avoid shooting themselves in the foot? So I'm still looking for a few more good reasons....
I have heard your arguments before, and I agree with many of them. Even when I don't agree, I respect your opinion. But I still need seven (or is it eight?) more reasons
Roles are too complicated, and the payoff so far has been minimal, while the dangers from misuse are many. Roles were a much-needed change to the Moodle architecture, intended to give it greater flexibility and extensibility. It was such a fundamental change that a difficult transition was to be expected. I believe that in time, roles will get better, more useful, and easier to use. But a long as we are in this transitional period, I think people need to understand the current system, not bury their heads in the sand. The attitude of the person that I quoted in my last post is all too common. How can we convince such people, not necessarily that they need to "use" roles, but that they need to learn at least enough to avoid shooting themselves in the foot? So I'm still looking for a few more good reasons....
Steve - there's an important aspect that perhaps you are not taking into account.
If there was a large chunk of the community "still in love" with 1.6, we'd see a strong "1.6.x maintainership" group -- moodle admins and developers that are deeply invested in 1.6.x and fix its bugs and keep the 1.6 branch alive.
When this happens and is really strong, sometimes you even see new feature work based on the "oldie-but-goldie" branch, perhaps as unofficial patches, etc.
None of those things have happened as far as I can see (and mind you, I'd be delighted to find there's a "silent maintainer" to 1.6, uploading patches to the tracker). My conclusion is that anyone who is interested in Moodle enough to "do something" uses that time to figure out roles and work on top of a current moodle, instead of turning that "do something" time into "a better 1.6".
Moodle development is carried on the shoulders of people who get stuff done. Those aren't clustering around 1.6 as far as I can see.
You can post contrarian views on the forum, but... how do facts line up? Until the download numbers for 1.6 start gaining on 1.7~1.9, and independent developers start showing their preference for 1.6.x, yours is a bit of a funny position. And it's not like we haven't seen people vote with their feet -- ask the Apache developers about how noone cared for v2.0 for years. It does happen. And yet, it's not happening here.
You like 1.6.x better -- that's great -- but you cannot claim that there is consensus that it is better.
(I do like 1.6.x too, but not as much as v1.9 with all that goopy performance and sticky sweet mnet stuff )
My advice to teachers (and admins) () is use them when you must and only to the degree that you must.
Hey! I agree with this. Fiddling with roles is fiddling with the configuration of how Moodle works -- by default, only admins can fiddle with roles, notice a parallel? My advice about moodle configuration is the same as yours.
Perhaps there's a misunderstanding here - roles are increadibly useful, but those aren't controls meant to be touched each day. They are core configuration. Teachers doing overrides in their courses is a bit of a power-user maneuvre, again, not for everyday...
Ca răspuns la Martín Langhoff
Re: Top ten reasons for learning about Roles
de către Robert Brenstein-
Martín, I read Steve's post quite differently than you. He does not seem to be against the roles and he does not seem to claim that 1.6 is better. And your argument about programming activities does not hold the water.
Moodle needed roles and nobody can argue against that seriously. The implementation, or may be just the formidable interface to control them, is another story. I am not afraid of digging through Moodle's code and changing it, but role setting is something that I haven't fully figured out yet despite visiting those pages a number of times and following related discussions. And judging from a number of role-related questions still posted, lots of people are still confused, which that should tell you something.
Furthermore, the power of role system should be used to customize student roles within a course. Some of the course and activity settings, for example, should and could be done through the role system. However, this is a bit scary proposition at this time considering that all teachers would have to actively use the role system on daily basis.
Moodle needed roles and nobody can argue against that seriously. The implementation, or may be just the formidable interface to control them, is another story. I am not afraid of digging through Moodle's code and changing it, but role setting is something that I haven't fully figured out yet despite visiting those pages a number of times and following related discussions. And judging from a number of role-related questions still posted, lots of people are still confused, which that should tell you something.
Furthermore, the power of role system should be used to customize student roles within a course. Some of the course and activity settings, for example, should and could be done through the role system. However, this is a bit scary proposition at this time considering that all teachers would have to actively use the role system on daily basis.
Ca răspuns la Robert Brenstein
Re: Top ten reasons for learning about Roles
de către Nicolas Connault-
I don't think that the argument of roles being too difficult to learn is a valid one, unless it is better qualified by those who complain about it this way. In my opinion, the more powerful a tool, the more complicated it is, and the more time it will take to learn to use it. There is a sort of stereotype surrounding web applications in general, that if they present a steep learning curve (to use the popular, though incorrect jargon), they are not "user-friendly" nor "intuitive", and are therefore poorly implemented. This may stem from the fact that we all learned the web first as a set of static web pages, where all we had to do was click links and fill forms.
So, maybe I could compare the attitude of many admins regarding roles, to that of a real estate agent who does all his record-keeping on paper. Then a friend comes along and shows his computer, explaining how powerful and flexible it is, and how much easier his job will be once he has learned how to use it. But the agent just says: "I'm very successful in my business using my current methods, I don't see why I should invest time learning something so complex as a computer".
Of course, he is perfectly entitled to stick to paperwork, if it works so well for him. It's likely even that, while he learns to use a computer, his productivity will decrease. But it's also likely that the rest of his industry will adopt the new technology, leaving him behind as a very efficient real estate agent, but only as far as paperwork agents go.
If I was a Moodle admin, I would consider learning about each new feature of Moodle as part of my job description, if I recognised that it was needed, no matter how much effort it would take to learn it.
So, maybe I could compare the attitude of many admins regarding roles, to that of a real estate agent who does all his record-keeping on paper. Then a friend comes along and shows his computer, explaining how powerful and flexible it is, and how much easier his job will be once he has learned how to use it. But the agent just says: "I'm very successful in my business using my current methods, I don't see why I should invest time learning something so complex as a computer".
Of course, he is perfectly entitled to stick to paperwork, if it works so well for him. It's likely even that, while he learns to use a computer, his productivity will decrease. But it's also likely that the rest of his industry will adopt the new technology, leaving him behind as a very efficient real estate agent, but only as far as paperwork agents go.
If I was a Moodle admin, I would consider learning about each new feature of Moodle as part of my job description, if I recognised that it was needed, no matter how much effort it would take to learn it.
In my opinion, the more powerful a tool, the more complicated it is, and the more time it will take to learn to use it.
Well, I couldn't disagree more. I don't know any serious developer of anything who believes that...just the opposite, in fact. I hope that's not a commonly shared opinion by Moodle developers...if so, I can't wait for 2.0...maybe I'll need to enroll in another degree program just to learn enough to be able to create an account.
Steve
So what you're saying is, as Moodle grows with more features, more possibilities, more functionality, it should become easier and easier to learn?
You say you disagree with me, but you don't say why. Would you care explaining with a counter-argument, instead of a supposition that you know the opinion of every "serious programmer" of everything?
You say you disagree with me, but you don't say why. Would you care explaining with a counter-argument, instead of a supposition that you know the opinion of every "serious programmer" of everything?
So what you're saying is, as Moodle grows with more features, more possibilities, more functionality, it should become easier and easier to learn?
Show me where I said that? Point to a place in this thread (or any other) where I said that.
Now....let's look at what you said...
"...the more powerful a tool, the more complicated it is, and the more time it will take to learn to use it."
That's a direct quote. See the difference? I still haven't met a single serious developer of anything who believes that. But, maybe some of your fellow Moodle developers do believe it...I'm waiting to hear them chime in and support you.
If you want an example, just look at PC development...if PC development followed your philosophy people would need a degree from MIT to use a computer today and in the future they would be so complex no one would be able to use them. Of course, if I have to explain, I don't expect you would understand, but at least I can try 
Steve
So what you're saying is, as Moodle grows with more features, more possibilities, more functionality, it should become easier and easier to learn?
Show me where I said that?
Here:
In my opinion, the more powerful a tool, the more complicated it is, and the more time it will take to learn to use it.
Well, I couldn't disagree more. I don't know any serious developer of anything who believes that...just the opposite, in fact.
I think you make a good point Steve. The aim should always be to make things easier to use and good design will achieve that as a goal. The iPod in particular comes to mind as a triumph of simplicity over enormous underlying complexity. However, even among Global big players, Apple is unusual in having achieved this and its certainly not easy. I'd go so far as to say that its probably the hardest part of the design process.
However, the iPod as an comparison to Moodle also doesn't quite cut it, and neither does the PC. iPods only have one or two real functions, so simplicity is not far off in theory from the start. PCs are multi-function, much more like Moodle, but maybe we forget the time, so long ago now, when we were. Complex systems do take time to learn (and design) or else degrees from MIT would not be necessary at all.
Brings to mind this famous quote:
"I would not give a fig for the simplicity this side of complexity, but I would give my life for the simplicity on the other side of complexity."- Oliver Wendell Holmes
Google came immediately to my mind after reading this thread. I agree with those who think simplicity is good.
I'm a little confused...you seem to be waffling a bit. So, just to be clear, are you supporting Nicholas' development philosophy?:
In my opinion, the more powerful a tool, the more complicated it is, and the more time it will take to learn to use it.
Steve
Ca răspuns la Steve Hyndman
Re: Top ten reasons for learning about Roles
de către Victor M. Alvarez-
Sorry, I thought it was clear enough. Google is powerful, simple and intuitive, and a good example of the type of tool I like to use.
Regards,
Victor.
Regards,
Victor.
Ca răspuns la Victor M. Alvarez
Re: Top ten reasons for learning about Roles
de către Nicolas Connault-
How do you define "powerful"? In what ways is Google "powerful"? I assume you are talking about the search engine here. In this regard, at least I have to agree that it is simple and intuitive: there is one input field and a submit button! But how much control do users have over the way their request is handled?
The way I used "powerful" was in the sense of how much control users have over the application, and how many different ways the tool can be put to work. Under this definition, the Google search engine fails miserably, unless you get into the advanced search features, which are not as intuitive and not as simple.
The way I used "powerful" was in the sense of how much control users have over the application, and how many different ways the tool can be put to work. Under this definition, the Google search engine fails miserably, unless you get into the advanced search features, which are not as intuitive and not as simple.
In what ways is Google "powerful"?
You can't be serious?
Steve
Under this definition, the Google search engine fails miserably, unless you get into the advanced search features, which are not as intuitive and not as simple.
Yea, I see what you mean...looking at the screen below I don't know how anyone would ever be able to figure out how to use it <sarcasm intended>
That forms looks more complicated, less intuitive to me than the basic google search. I don't see the need for sarcasm or argument here: it gives the user more power and control over his/her search, but adds a layer of complexity to the user interface.
I agree with you. What I also see, its that hardly any one is using these extra layers of Google. To give you a good example: Lots of teachers are heavy users of Google but also complaining that they do not now how to find royalty free materials. If you show them the filter option in Google they are supprised and say: 'thank you'. The next day they use good old simple Google box and complain how difficult it is to find...
Ca răspuns la Victor M. Alvarez
Re: Top ten reasons for learning about Roles
de către Steve Hyndman-
My reply (question) wasn't to you Victor...it was to Matt. I happen to agree with you...powerful, simple, and intuitive is always better and is (or at least should be ) the goal of all serious developers of anything.
Steve
Hi Steve,
to clarify, I meant to say that although I love simplicity where I find it, I have to support Nicholas' view that complex things will necessarily be more difficult to use than simple things. I don't think this is avoidable and the Google example illustrates this. The front page is powerful only insomuch as it performs a single function from a single input. Its powerful and simple in comparison to other search engines, which clutter up the search page, but as soon as you add functions, it becomes more complex as your screenshot shows. Still relatively simple and I agree, not too confusing, but it still only performs one function, just with more inputs this time. Moodle's roles system (for example) performs many functions with a very large range of inputs and there is only so far you can simplify such a system before you have to remove features to continue the process.
I think we have to embrace both views - your point that simplicity and intuition should be the ultimate goal for all system development, but within the limits that Nicholas outlines - some systems will never be as easy to use as Google because of their complex nature, no matter how well designed.
Matt
to clarify, I meant to say that although I love simplicity where I find it, I have to support Nicholas' view that complex things will necessarily be more difficult to use than simple things. I don't think this is avoidable and the Google example illustrates this. The front page is powerful only insomuch as it performs a single function from a single input. Its powerful and simple in comparison to other search engines, which clutter up the search page, but as soon as you add functions, it becomes more complex as your screenshot shows. Still relatively simple and I agree, not too confusing, but it still only performs one function, just with more inputs this time. Moodle's roles system (for example) performs many functions with a very large range of inputs and there is only so far you can simplify such a system before you have to remove features to continue the process.
I think we have to embrace both views - your point that simplicity and intuition should be the ultimate goal for all system development, but within the limits that Nicholas outlines - some systems will never be as easy to use as Google because of their complex nature, no matter how well designed.
Matt
Ca răspuns la Nicolas Connault
Re: Top ten reasons for learning about Roles
de către Robert Brenstein-
Moodle is in general quite easy to learn and use. If so many users, and we are not talking just beginners, can't easily wrap their heads in this issue, there is something wrong. Note that I am not saying that roles per se are difficult. I think the problem is with the interface and presentation of concepts and information for roles and capabilities. Moodle 1.9 has some improvements and John added a bug tracker entry with suggestions of some interesting improvements. This should be the direction of this discussion: how to improve things so roles are more clear and intuitive to use. That will eliminate a need for coming up with arguments to convince people to "learn" the role system.
Ca răspuns la Nicolas Connault
Re: Top ten reasons for learning about Roles
de către Michael Penney-
One thing that would be nice is a 'Role to Drop down' functionality - so that a commonly used role settingn for an activity could be converted to a nice drop down in the interface.
Most common example is the old forum settings that now require role overrides. If an admin/power user could create a couple of configurations and then provide those as a drop down in the forum type screen, that would be nice.
Hear, hear! This is similar to my idea about role "presets". If it wouldn't be too hard to implement, it would solve a lot of problems in the area of allowing instructors to set roles on individual activities/resources.
atw
atw
I can tell you honestly that I do not understand (at least not well enough to explain, except in an extremely superficial way) how permissions are resolved in a context, particularly in the presence of overrides. When I get to that part, I just mumble and hope no one follows up with a probing question. The only people who really understand this IMO are people who know Moodle internals, and they can only explain it in terms of data structures and algorithms.
I also have a problem with "User context." According to the docs, User and Course (or Front page) are disjoint contexts. But when I view my user details, I see something different depending on how I got there. Am I in a User context? A Course context? The Front page context? Or somehow in two contexts at the same time? In user/view.php I see moodle/user:viewdetails being checked a course context as well as a user context. Is this a compatibility hack, or a basic misunderstanding on my part of the context model? The question is not academic. It comes up when you explain to a Teacher how to assign the Parent role in a User context.
In both cases, I have posted questions to Roles and Capabilities forum. I dearly appreciate the responses that I have gotten, but they have done little to clarify my understanding. I have tried reading the source code and dumping $User->access, but my php reading skills are limited I hit a wall with 2,000-line source files and functions that span several pages. You really need an Eclipse environment to fully understand roles.
Roles are too much of a black box. We need to improve the transparency of roles through enhancements to the user interface (e.g., MDL-13228) and more and better documentation.
If I could rate my own post, I would give it a "Way off topic"
I also have a problem with "User context." According to the docs, User and Course (or Front page) are disjoint contexts. But when I view my user details, I see something different depending on how I got there. Am I in a User context? A Course context? The Front page context? Or somehow in two contexts at the same time? In user/view.php I see moodle/user:viewdetails being checked a course context as well as a user context. Is this a compatibility hack, or a basic misunderstanding on my part of the context model? The question is not academic. It comes up when you explain to a Teacher how to assign the Parent role in a User context.
In both cases, I have posted questions to Roles and Capabilities forum. I dearly appreciate the responses that I have gotten, but they have done little to clarify my understanding. I have tried reading the source code and dumping $User->access, but my php reading skills are limited I hit a wall with 2,000-line source files and functions that span several pages. You really need an Eclipse environment to fully understand roles.
Roles are too much of a black box. We need to improve the transparency of roles through enhancements to the user interface (e.g., MDL-13228) and more and better documentation.
If I could rate my own post, I would give it a "Way off topic"
"Roles are too much of a black box. We need to improve the transparency of roles through enhancements to the user interface and more and better documentation."
Off topic or not, I second that.
Off topic or not, I second that.
But when I view my user details, I see something different depending on how I got there. Am I in a User context? A Course context? The Front page context? Or somehow in two contexts at the same time?
As you've stated, it depends on how one gets to your user details. If it's yourself viewing your own profile, we are on user context. If it's someone else viewing the details of course participans, then we are in course context. If it's someone else viewing the details of site users, then we are in site context.
The information is always the same (your user details), but it's being accessed from different places. Each of those places is a different context. Depending on the context (where do you access the information from) you want to show/do different things.
For example, with your Parent role, you don't want to assign it 'moodle/user:viewdetails' in the course context, because that would allow the parents with that role to see the user details of any course student, not just the child of the parent. By assigning the role in the user context (more specifically in the user context of the child user), you grant access to that information only if accessed from the user details page (i.e., the profile), but not when viewed from the course participants list.
Clear as mud, isn't it
Saludos. Iñaki.
You seem to say that only a single context is applicable at any time; however, the technical explanation of how roles are effected
http://moodle.org/mod/forum/discuss.php?d=66782#p300774
seems to imply that all contexts come to play.
http://moodle.org/mod/forum/discuss.php?d=66782#p300774
seems to imply that all contexts come to play.
http://moodle.org/mod/forum/discuss.php?d=66782#p300774 seems to imply that all contexts come to play
Not all contexts, but only those which are above a given context come into play when determining what a user can do in that context. For example, a Course context is nested within a Category context, which is nested within either another Category context or within the System context. User contexts are nested directly within the System context. Therefore Course contexts and User contexts are disjoint. You can't possibly be "in" both at the same time.
So the question remains: How can my permissions in a User context possibly depend on the course I jumped there from?
If your permissions depended on the path you took to get to a particular context (e.g., I jumped there from the Participants block of a specific course), then the roles system would lose referential transparency. It would be impossible to predict what a user could do in a given context, since the permissions would be determined dynamically, rather than statically. That would be a disaster.
Not all contexts, but only those which are above a given context come into play when determining what a user can do in that context. For example, a Course context is nested within a Category context, which is nested within either another Category context or within the System context. User contexts are nested directly within the System context. Therefore Course contexts and User contexts are disjoint. You can't possibly be "in" both at the same time.
So the question remains: How can my permissions in a User context possibly depend on the course I jumped there from?
If your permissions depended on the path you took to get to a particular context (e.g., I jumped there from the Participants block of a specific course), then the roles system would lose referential transparency. It would be impossible to predict what a user could do in a given context, since the permissions would be determined dynamically, rather than statically. That would be a disaster.
How can my permissions in a User context possibly depend on the course I jumped there from?
I think the basic misunderstanding here is confusing the user context with the user page.
You can view the user details page in different contexts. User context is just one of them. Others are course and site.
So when you are in a course (Course context) and click on the details of a participant, you are accessing the user page in the context of the course.
So permissions don't depend on the path you took to get to a particular context (the context hasn't changed, you are still in course context), but they depend on the path you took to get to a particular page: you can think of the context as that particular path.
Therefore permissions are determined statically with respect to the context, but they are not with respect to the page.
Saludos. Iñaki.
HI Iñaki,
Thanks for your comments. You made me think, and I think I have it sorted out. I think there is a fairly clean separation between User context and Course context, as required by the context model. A user cannot be in both at the same time. The key is to realize that certain course-related information resides in the User context (along with profile, blog entries, and other obviously user-related information).
Suppose a user enters a course in which he is enrolled as a Student. He clicks the Grades link in the Administration block. The user is shown the grade report for the course. When viewing this page, the user is no longer in the Course context, and he is not even a Student! He is only an Authorized user and he is in a "compartment" of his User context -- a compartment which is separated by imaginary walls from adjacent compartments which contain the grades for his other courses. When the user returns to course (say, using the back button), he returns to the Course context and regains his Student role.
If the same user enters a second course in which he is enrolled as a Student and clicks the Grades link, he sees the grade report for THAT course. Once again, he is in a compartment of his User context, and he is viewing the grade report for that course as only an Authorized user.
Within the Grade report there are activity links. If the user clicks one of these links, he is transported back into the Course context (actually, into a Module context within the Course context) and he regains the roles he had in the Course context.
If a user clicks his name in the Online users block of the Front page course, he is once again transported to his User context as Authorized user. Here he will see links to all the courses in which he is enrolled. If he clicks any one of these links, he is NOT transported to the course; rather, he is is shown another page with links to areas of his User context where information relevant to that course is stored. Clicking an activity link in an activity report will transport the user into the Course context, where the user becomes a Student.
The forum posts that a user has made also live in compartments of the User context. When you're looking at a page of forum posts (listed in reverse chronological order under the Forum posts tab), you're looking at them as Authorized user only. You can't reply or edit or do anything that you can normally do inside a Forum itself. You can click "See this post in context" and jump into the Forum, becoming a Student in that course.
We have similar scenarios for the Parent who jumps to the child's User context via a link in the Mentee block. The parent sees Activity reports as a Parent (which is not too different from an Auth user). The Parent can see
I will do some experimenting in the next few days, but so far this explanation appeals to me because it doesn't violate the context model (course and user contexts are disjoint in the model). I suspect that in reality it isn't that clean, and that there is some leakage between contexts.
Thanks for your comments. You made me think, and I think I have it sorted out. I think there is a fairly clean separation between User context and Course context, as required by the context model. A user cannot be in both at the same time. The key is to realize that certain course-related information resides in the User context (along with profile, blog entries, and other obviously user-related information).
Suppose a user enters a course in which he is enrolled as a Student. He clicks the Grades link in the Administration block. The user is shown the grade report for the course. When viewing this page, the user is no longer in the Course context, and he is not even a Student! He is only an Authorized user and he is in a "compartment" of his User context -- a compartment which is separated by imaginary walls from adjacent compartments which contain the grades for his other courses. When the user returns to course (say, using the back button), he returns to the Course context and regains his Student role.
If the same user enters a second course in which he is enrolled as a Student and clicks the Grades link, he sees the grade report for THAT course. Once again, he is in a compartment of his User context, and he is viewing the grade report for that course as only an Authorized user.
Within the Grade report there are activity links. If the user clicks one of these links, he is transported back into the Course context (actually, into a Module context within the Course context) and he regains the roles he had in the Course context.
If a user clicks his name in the Online users block of the Front page course, he is once again transported to his User context as Authorized user. Here he will see links to all the courses in which he is enrolled. If he clicks any one of these links, he is NOT transported to the course; rather, he is is shown another page with links to areas of his User context where information relevant to that course is stored. Clicking an activity link in an activity report will transport the user into the Course context, where the user becomes a Student.
The forum posts that a user has made also live in compartments of the User context. When you're looking at a page of forum posts (listed in reverse chronological order under the Forum posts tab), you're looking at them as Authorized user only. You can't reply or edit or do anything that you can normally do inside a Forum itself. You can click "See this post in context" and jump into the Forum, becoming a Student in that course.
We have similar scenarios for the Parent who jumps to the child's User context via a link in the Mentee block. The parent sees Activity reports as a Parent (which is not too different from an Auth user). The Parent can see
I will do some experimenting in the next few days, but so far this explanation appeals to me because it doesn't violate the context model (course and user contexts are disjoint in the model). I suspect that in reality it isn't that clean, and that there is some leakage between contexts.
Model-view-control.
Deep inside Moodle you have the model. On top of that you create views (mostly pages) and controls (mostly buttons and fields-to-fill)
if you think of a role, you think of the set of views and controls a user needs for fullfilling all the possible acts in his role AND you try to offer these views/panes in such a way that it fits/follows the normal behavior of person in that role.
To help the user to get grip on the complete set of views and controls, you sell him a metaphor:
- the core pane of the Moodle metaphor is the section (over)view
- the student can zoom-in/zoom out one section (here the first users in the forums start to complain: can't we switch that off..
)
- the next panes for the resources and activities are one-level-deep (clever design), and you can always jump-back to the mainscreen.
- if tools have flaws in the interface (like the first screen of questionnaire, people vote with their feet for other tools and move to feedback)
- around this main set you see more and more disjunct views:
- for the user profile page you need the metaphor that you can explain your wishes and express your self in Moodle: do it here.
(If I offer the user extra choices, I add them on this page.) - the my page: is this an extension of the user profile or not: it is the page where you organise your learning life in Moodle, so here I must be able - as a user - to choose all the information i find important on this page. (The central colum option for blocks helps a lot). One of the options I added was to give the user a switch on the profile page to swith the course messages in the central list on or off on the my page... it can be overwhelming.
- The my Page also helps to avoid (extra) visits to other screens, for example the hierarchy of categroies..
- the monitor views: there are too many to make a choice, but you must connect them to the other activities in a user-logical way: reports, grades.. etc..
- for the user profile page you need the metaphor that you can explain your wishes and express your self in Moodle: do it here.
"Teachers doing overrides in their courses is a bit of a power-user maneuvre, again, not for everyday..."
Disagree. This isn't power use:
http://moodle.org/mod/forum/discuss.php?d=88701
And neither is this:
http://moodle.org/mod/forum/discuss.php?d=84499
I don't think I mentioned 1.6 in my post, and although I could reply to those points, I'm not sure how that applies to this discussion, so I won't.
Steve
Hello Steve,
We are using Moodle in real life: we have several schools on the same moodle with one superadmin (yes me ). One of the wishes we had in the past was having admins with more rights than coursecreators but less rights then the superadmin. To realise that I had sometimes to hack five or more levels deep and on more then 10 different places. 1.4 1.5 1.6 ... with sometimes strange side effects!
Now we go to 1.9 and use your golden rule: stay away from role-creation.
By doing that we can build on our experience from the pre 1.7 era.
By exception we create a new role, like the one above and with less surprises then with my blind hacks. When in doubt we use your golden rule.
our next role will be a parent account: we want to give parents to look at a course with the eyes of their child, seeing the grades in the context of their offsprings work and so on: but how can we tune what they see and when they can interfere (= outside office hours).. a special kind of mentor account?
Are there people out there having good examples of parent accounts?
Ca răspuns la Martín Langhoff
Re: Top ten reasons for learning about Roles
de către Visvanath Ratnaweera-
Hi all
I was not aware of this discussion when I started the other thread http://moodle.org/mod/forum/discuss.php?d=93089
> If there was a large chunk of the community "still in love" with 1.6, we'd see a strong "1.6.x maintainership" group -- moodle admins and developers that are deeply invested in 1.6.x and fix its bugs and keep the 1.6 branch alive.
> When this happens and is really strong, sometimes you even see new feature work based on the "oldie-but-goldie" branch, perhaps as unofficial patches, etc.
> None of those things have happened as far as I can see
If the P2V idea I've mentioned in the other thread - LAMPM virtual machine per school, all the virtual machines on one Windows server - hits the ceiling I'll have to fall back to 1.6. Admittedly you can't call that "large chunk of the community in love with 1.6", still there is somebody who might have to stay with 1.6 out of neccessity.
> (and mind you, I'd be delighted to find there's a "silent maintainer" to 1.6, uploading patches to the tracker).
Follow-up in the thread mentioned above.
I was not aware of this discussion when I started the other thread http://moodle.org/mod/forum/discuss.php?d=93089
> If there was a large chunk of the community "still in love" with 1.6, we'd see a strong "1.6.x maintainership" group -- moodle admins and developers that are deeply invested in 1.6.x and fix its bugs and keep the 1.6 branch alive.
> When this happens and is really strong, sometimes you even see new feature work based on the "oldie-but-goldie" branch, perhaps as unofficial patches, etc.
> None of those things have happened as far as I can see
If the P2V idea I've mentioned in the other thread - LAMPM virtual machine per school, all the virtual machines on one Windows server - hits the ceiling I'll have to fall back to 1.6. Admittedly you can't call that "large chunk of the community in love with 1.6", still there is somebody who might have to stay with 1.6 out of neccessity.
> (and mind you, I'd be delighted to find there's a "silent maintainer" to 1.6, uploading patches to the tracker).
Follow-up in the thread mentioned above.
One of the things that I have seen about the roles is that it is a bit of an exhaustive list of things to choose from. Is there anything about redoing this process to make it easier to use. That is what has stopped me from working with the roles to customize them is the list of options and the inability to make quick changes and configs without very indepth knowledge to all of the list of options.
You might want to start a separate discussion in the Roles and Capabilities forum, since your comment is not directly related to my question. I'm assume that the Roles and Capabilities system will stay pretty much the way it is now, and I'm looking for arguments to convince people (like you!) that they need to bite the bullet and learn the system ... today.
But thinking about your point, another argument might be, "Users who admit that they do not understand the system, and who assert that they do not plan to use it, will inevitably do something role-related that seems harmless, but which gets them into trouble that can only be fixed by ... someone who understands Roles and Capabilities
If you doubt it, read some of the discussions with titles like "Help, I've lost my administrator privileges"
But thinking about your point, another argument might be, "Users who admit that they do not understand the system, and who assert that they do not plan to use it, will inevitably do something role-related that seems harmless, but which gets them into trouble that can only be fixed by ... someone who understands Roles and Capabilities
If you doubt it, read some of the discussions with titles like "Help, I've lost my administrator privileges"
I'm sorry I don't have time to look, but you could search feature requests or do a search of these forums looking for terms like capability prior to the introduction of roles. If I recall, there was a different feature requested every week or so that would require a tweaking of roles.
In the end, I have found almost everyone has a slightly different conception of how each module should function. Having a consistent and well abstracted role system is intimidating at first, but much easier to understand than a hodge podge of settings and hacks and it allows the modules to function in as many ways as there are teachers.
In the end, I have found almost everyone has a slightly different conception of how each module should function. Having a consistent and well abstracted role system is intimidating at first, but much easier to understand than a hodge podge of settings and hacks and it allows the modules to function in as many ways as there are teachers.
As an adjoinder to this, I do not need convincing that learning about Roles and Capabilities is 'a good thing' but can I find useful documentation - No (when I say useful, I mean useful to me, I am a bit of a dummy when it comes to reading and understanding. Doing and understanding works - but I don't want to experiment without someone being there that can answer the 'what if questions'.
Ian
Hi, John! Back to the topic.
Today I thought of a reason I needed roles. And I remembered an old reason.
1) I would like to set up a system where some teachers were "super teachers" and had the capability of setting roles for activities and such in their courses. If you did not want/need such capability, you wouldn't have it. This would help slightly as it would hide role assignment from users who did not need it, but make the roles assignment feature available for teachers who DID need it. If I could combine that with some simple presets that were a few checkboxes, I would think that terrific!
2) I did, last summer, create a role for student preceptors. It was really just a clone of the student role (no additional capability), but (if I remember correctly) it did set those folks apart and make them visible as preceptors in the participants list. It also, interestingly enough, allows me to track statistics based on the role. That is part of the default statistics package available to admins.
Or have I forgotten what this thread was originally for?? Sorry!
atw
Today I thought of a reason I needed roles. And I remembered an old reason.
1) I would like to set up a system where some teachers were "super teachers" and had the capability of setting roles for activities and such in their courses. If you did not want/need such capability, you wouldn't have it. This would help slightly as it would hide role assignment from users who did not need it, but make the roles assignment feature available for teachers who DID need it. If I could combine that with some simple presets that were a few checkboxes, I would think that terrific!
2) I did, last summer, create a role for student preceptors. It was really just a clone of the student role (no additional capability), but (if I remember correctly) it did set those folks apart and make them visible as preceptors in the participants list. It also, interestingly enough, allows me to track statistics based on the role. That is part of the default statistics package available to admins.
Or have I forgotten what this thread was originally for?? Sorry!
atw
"Roles" or "tools"?
In e-learning environment we're trying to persuade students that they do not possess a distinct student "role" but, by teaching others, they will learn better. Isn't that the basis of social constructivism, the theory where Dougiamas based upon in order to develop the first moodle version?
By having this in mind, should we distinguish roles or should we offer the meaning and best practice usage of various tools moodle generous hands us? I see lots of technical issues discussions but little of best practice, principles and methods of how moodle (the tool) will assist a teacher in his/her job, to do it easier, more effective and efficient. Let's focus in education by using moodle and not so much in the tool by itself. After that we can drive easier tool's changes in order to be more productive.
In e-learning environment we're trying to persuade students that they do not possess a distinct student "role" but, by teaching others, they will learn better. Isn't that the basis of social constructivism, the theory where Dougiamas based upon in order to develop the first moodle version?
By having this in mind, should we distinguish roles or should we offer the meaning and best practice usage of various tools moodle generous hands us? I see lots of technical issues discussions but little of best practice, principles and methods of how moodle (the tool) will assist a teacher in his/her job, to do it easier, more effective and efficient. Let's focus in education by using moodle and not so much in the tool by itself. After that we can drive easier tool's changes in order to be more productive.
Ca răspuns la Christos Karakirios
Re: Top ten reasons for learning about Roles
de către Ger Tielemans-
The role of a student is getting graduated and/or learn a lot.
You look at all the Moodle tools and wonder which set of tools in Moodle fits best these goals. in a profile (called role in Moodle, profile would be a better word ) you set the rights for all these separate mini-tools on global level. Then you organise on course level the way you offer these mini-tools in combination. Different combinations can have complete different effects.
The role of a teacher is to set/manage the conditions of learning ("feed-forward") for the student, to monitor the process and coach the student ("feedback") and to guard the quality. Despite the nice idea of students working as tutors it is in most institutions a tradition, that only real teachers have access to the final grading system. This asks for a strong separation between the role of teacher and student. Having the model-roles as grey prompts in the role system is a nice way of helping me to determine which role I can tune best..
Ca răspuns la John Isner
Re: Top ten reasons for learning about Roles
de către Visvanath Ratnaweera-
I know, I'm late to barge in to this discussion.
> My audience consists of both teachers and admins who have been using Moodle since 1.5. They recently upgraded to Moodle 1.8, but are not yet using any of the Roles and Capabilities features.
I don't know the details of this particular situation. But generally, if somebody is not interested in something, telling him "we know what you want" amounts to imposing one's will on that person. Nobody likes that, teachers the least, unless they have become the sheep of some political game
> My audience consists of both teachers and admins who have been using Moodle since 1.5. They recently upgraded to Moodle 1.8, but are not yet using any of the Roles and Capabilities features.
I don't know the details of this particular situation. But generally, if somebody is not interested in something, telling him "we know what you want" amounts to imposing one's will on that person. Nobody likes that, teachers the least, unless they have become the sheep of some political game