Moodle in English: Roles and Permissions architecture

Greetings all.
As the OU slogs its way towards our first use of Moodle in May (we're doing the usual behind the scenes integration stuff as well as a few goodies), we've done a lot of thinking about roles and permissions. While we have a particular need for a more flexible model, I think we've got a few ideas which would benefit everyone.
We started with the Nov, 2004 proposal for roles and permissions and tried to map it to what we hope to do with Moodle. The issue we ran into was the granularity of role assignment in the current proposal. Currently, roles are assigned on a course basis. We want to be able to assign permissions on every level down to a single instance of a module. For example, we tried the following use cases:

1) Regular student in a course: A student signs up for acourse with a simple interaction model. They have the same priviledges as everyother regular student in every course. The priviledges are set sitewide.

2) Tutor / Teaching Assistant: An tutor on a course has moderator priviledges on their group's forums. They canalso create sub-groups and assign roles to students within the group (groupforum moderator, group wiki editor). Anypriviledge changes within the group context do not apply at the course level.

3) A staff tutor: A staff tutor is assigned to monitorserveral tutors on several courses. They are allowed to read all of the activitiestheir tutors are involed in, but cannot make edits to content or changeconfigurations.

4) Participitory quiz: A course team decides to change thepermissions on a quiz to allow studentsto write their own questions. For a period of two weeks, anyone with a studentrole in the course can add questions to the quiz pool. At the end of the time,the quiz is made available for students to take and they can no longer addquestions. Students cannot add questions to any other quiz in the course exceptthis one during this timeframe.

5) Glossary editor: After scoring well on a vocabulary quiz,a student is granted editor privileges on a glossary in the course. Only thisstudent can add new definitions and make comments on exisiting definitions. Thestudent only has these priviledges on this glossary, not on any other glossaryin the course.

The use cases illustrate the need forcontext sensitivity in the role definitions. Maximum flexibility and power canbe gained by creating the ability to determine roles at all levels of thesystem, from system wide roles to roleswithin a single instance of a module. A combination of role and context ofinteraction will determine the capabilities of a given user at a moment intime.

This level of flexibility will greatly improve the abilityof Moodle to full implement the learning design specification. Scripting interactionwill require different students to have different privileges at differenttimes.

It also brings up an issue of roles vs module configuration: Many of the capabilitiesinherent in roles are also currently configuration options within a module. Forexample, the ability to upload attachments in a forum is currently set for theentire module instance. There is no mechanism for a course designer to restrictthe ability to upload attachments to a designated group leader (e.g. a teachingassistant or leader of a group project).

To maintain the simplicity of the Moodle interface, we suggest atwo-tier model. The existing module configuration interface will remain thesame, except for hiding those capabilities the author does not have. Forexample, if there is a site-wide restriction on file uploads, a course authorwill not see the option to allow attachments in a forum. Otherwise, allconfiguration options will still be available. The configuration options setfor a module instance will override priviledges set at a higher level.

Advanced users will be able to configure modules based on agiven role. A course author may create a glossary editor role which will havemore capabilities than a regular student. This role could then be assigned to agroup of students for a given glossary.

If there is a specific role defined for a module instance,that role overrides the configuration options.

We've begun to look at how to implement this technically. Right now, we think we can look at adding context to the ideas presented in the November 2004 proposal. The base architecture would be the same, but be sensitive at a more granular level.
I'd welcome feedback, thoughts, expressions of emotion.
I'd also like to hash this through a bit more in the developer call on Friday if possible.
Thanks!
Jason

Average of ratings: -

Re: Roles and Permissions architecture

by Matt Oquist - Thursday, 2 February 2006, 2:30 AM

Jason,

Can you provide a URL to the November, 2004 proposal that you reference?

Also, the new access_control module (which -- full disclosure -- I wrote) should be able to help store and manage data related to who gets to do/not do what. It's available in the contrib subdirectory of the portfolio module, and it includes API documention (also visible here). Also, you automatically get the interfaces to grant/revoke access. (Screenshots here.)

With regard to your examples:
2) Tutor / Teaching Assistant

This could be done a couple different ways, but one way is to set up an access_control instance like this (pseudo-code):
$ac->ftable = forums;
$ac->access_type = 'moderator'; // this type specified in access_control/plugins/
$ac->designee = $tutor_userid;
$ac->fkid = $forumid;
$ac->yesno = 1; // grant this access

Then set that access, and you can use the access_control APIs to test for it, change it, etc.

Then:
$ac->ftable = groups;
$ac->fkid = $groupid;
$ac->access_type = 'create_subgroup';

And set that access.

Then:
$ac->access_type = 'assign_roles';

And set that access.

3) A staff tutor

This is exactly the sort of thing I'm going to be using the access_control module to do for the portfolio module. (See further discussion below.)
WRT the lack of editing and config changing permissions, if you use the access_control module then you just don't specify those accesses for the tutors.

4) Participitory quiz

One of the things I mean to have in the access_control module that isn't there yet is group support. But once we add group support this would be very easy, because the group of students can be granted question_add access to the given quiz by adding one record in the access_control table, and that access can be removed after the two weeks.

5) Glossary editor

Also easy.
$ac->ftable = 'glossary';
$ac->fkid = $glossary_id;
$ac->designee = $student_userid;
$ac->access_type = 'create_new_definition';
$ac->yesno = 1;

Set the access.

$ac->access_type = 'comment_on_definition';
Set the access again.

If you use the access_control module, you have APIs available so you can easily test for access when presenting form controls ("Do I show the 'Add comment' button or not?) and when processing form data ("I got a new quiz question; is this user allowed to submit one?").

One of the next things I need to do for the portfolio module is implement a way for there to be "portfolio advisors" who have world publicaton access. Here's the usage scenario: School wants to make sure that everything published on their website (to unauthenticated users) has been reviewed by a responsible party, so they don't grant world-publication access to students. There is one person who is set as the default advisor for portfolios, but each student can also have her own advisor. When a student thinks a portfolio artifact is ready for publication, she goes to the publication interface and selects "Publish to world", and her advisor gets a message asking that the portfolio artifact be reviewed, and if appropriate, published.

I was planning to do this by adding a table to the access_control module so that for any given table/role a default user (we'll call that user a "reviewer" here, though they could also be a publisher, or a course creator, etc.) can be specified, and for any user an alternative "reviewer" can be specified.

(As an aside: I named the field in the access_control table 'ftable' because I was using it to specify a database table to which access is being granted/denied. But this is just a string, and it could also contain the name of a role or anything else.)

Given that there's some existing roles architecture in Moodle, I'd like to find out more about it.

Average of ratings: -

Re: Roles and Permissions architecture

by Jason Cole - Friday, 3 February 2006, 10:14 PM

Thanks Matt. We'll take a look at this.

The original proposal we were working from is here. http://moodle.com/development/plans/roles.html

Average of ratings: -

Parents and criminals

by sam marshall - Friday, 3 February 2006, 11:27 PM

An interesting case that was mentioned on today's chat is for schools and is that of a parent, who has special access to information about their child. This could be handled by extending the 'contexts' that roles apply to - courses, groups, module instances, etc. - in order that you can assign a role based just on a user ID. So user MrsBloggs could have the 'parent' role when concerned with user KimBloggs.

One other fun use case which isn't quite a realistic one, but might be before long, for our university is the 'prisoner' role. Sometimes people in prisons study OU courses, although as I understand it they aren't currently allowed to go online. Anyhow, supposing they were allowed to go online (perhaps restricted to our site) we might need to apply additional restrictions. Consequently these people would be assigned the 'prisoner' role which applies to that user throughout the site. Then, even on courses where they have student permission, the 'prisoner' role would prevent them from engaging in certain activities. E.g. prisoners would be allowed to do a quiz, but they wouldn't be allowed to post in a forum as they aren't allowed to communicate directly.

By the way I have a diagram of one way to view our slightly-more-complicated roles architecture, but I'm not sure whether I ought to post it here, or whether we are supposed to be coming to agreement internally first

Average of ratings: -

Re: Parents - criminals?

by Ian Usher - Wednesday, 15 February 2006, 7:35 AM

There is a definite case (btw, hello from the world of schools!) for a "parent" role in here somewhere... typically this person would be assigned to a student user (but note that it could be more than one - different kids in different years, or twins, triplets, etc...) and be able to access (it's late and this is off the top of my head, but...) the following

their activity report
their grades (possibly including their marks in quizzes , or even their answers, definitely their assignment marks, and possibly read-only access to what they submitted - after the assignment has closed?)
I'm not sure about whether a 'parent' should be allowed to see what a pupil has posted in forums - I know an activity report shows that, but who knows...

...maybe. Like I said, it's late.

My guess is that a site (in our case an individual school's instance of Moodle) should be able to set a policy about what a 'parent' can see - in a similar way to how a teacher setting a quiz can determine what elements of the quiz (feedback, correct answers, marks, etc.) students can see, and when. Sort of a matrix of checkboxes that would apply across the site. This would also mean that the school could customise the parents "role" (i.e. the role which they play in their child's learning) in conjunction with any policies they already have in place.

However, as we are using single-sign on for our Moodles, this would (in theory) mean that we as an LEA would have to offer "parent" accounts (ick!) - either that or we take a mixed-authentication route and we provide schools with staff and pupil accounts and the schools create their own accounts for parents (again messy when as a parent you've got different kids in different schools). But hey, that's another day's headache...

As is the whole area of child protection in a VLE... logging on using your child's username and password, talking to their friends as "them"... again, it's too late for this... mixed

Also, there's definitely a case for a role of "examiner" or "inspector" that could be created for a school's Moodle, rather than giving the Ofsted inspector CDs, or stuff to read, give them a login instead... I know some schools do this already but there's scope for a "site wide non-editing teacher" role (if I may phrase it in the current paradigm of roles) which schools would love to offer to inspectors and/or examiners. I think the "examiner" role would come into play more with ePortfolio-based courses such as DiDA or AVCE qualifications - this may be a similar role to the "inspector" one, but I'd need to think about it at a different time of the day... sleepy

Average of ratings: -

Re: Parents - criminals?

by Anthony Borrow - Saturday, 18 February 2006, 11:02 PM

A number of good points are raised here. I have some thoughts on some of them. There definitely needs to be a distinction between a parent and the student. The parent should not login as the student. Regarding the issue of parent accounts - I'm wondering if it might not be simpler to create a field like password_parent in the user table and then use a username of $username_parent. Check for the _parent extension and if it matches the user prefix then give that person access to that child's information. This would prevent doubling the size of the user database. It would allow a parent to look at the information for one child at a time (a possible limitation) but perhaps a good one. It would also facilitate dealing with legal issues about releasing information to a non-guardian parent. If the guardian of a child changes, then the school can change the password and give the new password to the guardian. My fear is that if you have multiple parent accounts it will get too complex to effectively administer.

I think that parents should be able to see the student grades; however, I ask my students to do a fair amount of personal writing and would want some type of privacy. If the parent insists on seeing information I think they should go through the child to get it. For similar reasons, I would not necessarily want a parent to be able to see the posts that a students is making. It is the student's work and we try to encourage student responsibility. However, as you said this is one of those things were each place will want a certain level of control.

I am interested in what others think about the parent role and how it can best be implemented.

Average of ratings: -

Re: Parents - criminals?

by Art Lader - Saturday, 18 February 2006, 11:16 PM

This entire conversation makes me very nervous... I know that parents will want to be able to see grades, lesson plans and some other stuff. And that is legitimate.

But forum posts, assignments, etc? Yikes! And the stuff that other students have contributed? That simply cannot happen - at least where I live.

It's a problem... I guess we could require our students to pseudonym whenever they post anything. That might help, I suppose.

Anyway, I am eagerly following this discussion. If we all put our heads together, we should be able to figure this out!

-- Art

Average of ratings: -

Re: Parents - criminals?

by Stephen Catton - Monday, 20 February 2006, 5:02 PM

Hello All

I have been thinking about parent access for some time now. I know that the UK Gov is making moves to enable parent access to their childs work. I for one would like to know what home work has been set.... ( I've lost my hand book, no home work tonight, I've lost the sheet, I need flour, eggs, oats sugar and golden syrup for tomorrow morning..... spring to mind). I would also like to check their attendents record if only to check for the EMA status.

I have attached a PDF from Mindgenius (If you want a copy please email me) of my thoughts and wishes on a course layout. Parents could have access to the Course at Meta level.

MindMap_Moodle_Course.pdf

Average of ratings: -

Re: Parents - criminals?

by Ian Usher - Monday, 20 February 2006, 8:19 PM

Art said:

But forum posts, assignments, etc? Yikes! And the stuff that other students have contributed? That simply cannot happen - at least where I live.

...absolutely... so if we could agree on a minimum "core" set of things that a 'parent' could do/see/access and then allow the edges of this to become a little fuzzy - for when Art's environment differs from mine and my friend Bob's differs from both of ours.

Of course, this is all restricted to the parent's own child - there should be no way of allowing a parent access to what others have said or contributed.

...but.... the more I think about this, the more it feels like we need to remove the parents from the mechanics of the course (with all its interactions and complex interrelationships) and allow them a level of access to their child's portfolio of work - which might include attendance details for a parent. The e-portfolio / personal learning environment / whatever-you'd-like-to-call-it-this-week is surely what most parents would want to see, as it's all on a plate for them, they don't need to wade through a course structure they may not understand just to find what's going on.

As part of our presentation on the it's-just-an-idea Kampus learning environment at the UK MoodleMoot last year, Drew and I posted the idea of having a "pseudonym" field / icon in a student's profile so that a teacher could specify if a course would at any point use students' pseudonyms and, within this course, whether a partcular activity (like a forum) would be undertaken by "real names" or "pseudonyms"...

I might well be wrong though! However, if we get this discussion "right" the parent role could be a very very powerful tool...

Average of ratings: -

Re: Parents - criminals?

by Miles Berry - Tuesday, 21 February 2006, 2:54 PM

Just a few observations here:

I absolutely agree that parental access needs to be limited to just their own child's activitiy.
I think their is an interesting role for Moodle in providing virtual PTA space of some sort: dicsussion forums, policy documents, photo galleries (maybe), newsletters, announcements, sort of thing.
Many learners would feel constrained in their forum posts by knowing their parents would read what they put - it's one thing to admit to peers and teachers that you don't get something, quite another to tell your parents: if the quality of discussion in forums is diminished by letting parents have access, then perhaps the price is too high.
I'm interested in how the Data Protection Act relates to this in the UK. I am not a lawyer, but I believe the subject access right applies to the child, not the parent, unless the child has given consent, or is too young to make an application; I don't think there's any age limit defined. Furthermore,

"Personal Information about Someone Else ... will not normally be released to you without that persons consent. However, the DPA does allow such information to be disclosed without consent if this is reasonable in all the circumstances. In deciding whether it is reasonable, the controller must consider in particular whether a duty of confidentiality is owed to the other person, what efforts have been made to obtain the persons consent, and whether the person is capable of giving consent or has expressly refused it." [ref, qv]

I think there are issues relating to children's rights here which may be being overlooked in an entirely appropriate desire to get parents more involved in their children's education. Thinking of Moodle as a virtual classroom helps clarify this for me: I'm happy to let parents know whether their child was there in a lesson, and how they're getting on. I've no particular problems with them looking through their child's exercise book or exam papers. I'm not so happy about a pupil's parent watching the lesson, unless there's a good reason, as this seems to impact on their child and all the others, or in supplying a transcript of everything their child has said in my class.

Average of ratings: -

Re: Parents - criminals?

by Don Hinkelman - Sunday, 28 May 2006, 8:48 AM

This thread looks like it is trying to find a statically defined parent role. Actually, we don't need to decide a universal parent role. Each school, each culture, each government has different rules, values, and communication protocols. Rather we need a flexible way to design any role for any case. "Parent" is actually not one case but an eventual evolution of thousands of possible use cases.

The original title of this topic is Roles and Permissions Architecture, and this debate about parents illustrates that we do *not* need to design a few new roles to add the 3-4 we have now. Rather we need an architecture to design an infinite number of roles.

Average of ratings: -

Re: Parents - criminals?

by Josep M. Fontana - Sunday, 28 May 2006, 10:29 PM

>The original title of this topic is Roles and Permissions Architecture, and this
>debate about parents illustrates that we do *not* need to design a few new roles
>to add the 3-4 we have now. Rather we need an architecture to design an
>infinite number of roles.

This observation is crucial. Perhaps it is a good idea to have a few predefined roles but it is fundamental that the roles and permissions architecture be flexible enough to easily configure many other roles (or alter preexisting ones) simply as specific sets of permissions. What Don says about the "parent" role actually might apply to other roles as well.

Josep M.

Average of ratings: Useful (1)

Re: Parents - criminals?

by Peter Kupfer - Monday, 29 May 2006, 11:02 AM

Do you see that architecture coming any time soon?

Average of ratings: -

Re: Parents - criminals?

by Miles Berry - Friday, 28 July 2006, 3:55 AM

I've been doing some more digging around this since my post above. Whilst the data protection act stuff is true as far as it goes, I've subsequently discovered that parents do indeed have an independent right of access to their child's educational records.
Obviously, children's records must not be made available to other parties, including the parents of other children in the same class. Thus it would be necessary to associate parent accounts with their own child's accounts in such a way that they could, if so desired, have read access to their child's grades, answers and contributions, but generally not those of other children - this may be problematic in the case of wiki activities or forum posts.

Average of ratings: -

Re: $username_parent - super!

by Ne Nashev - Tuesday, 21 February 2006, 2:39 AM

$username_parent - it is beautiful idea!

It remove work for registering, manteining and administrating of all parent accounts! It make parent's account as simple additional child's mode, that can be supported by modules as additional (like for Guest) restrictions to normal child work!

Super idea!!!

If parent have more then one child - he (she) can look at him separatelly. When child have more then one parent (strange, yes? )- we are any way havn't any reasons to try separate his work in logs?

Average of ratings: -

Re: $username_parent - super!

by Anthony Borrow - Tuesday, 21 February 2006, 7:23 AM

Since the parent should simply be monitoring a child's work (IMO) I would not see a need to separate between multiple parents; however, multiple password hashes could be stored in a single field similar to how multiple answers are stored in the quiz module delimited either by , or :

During login the various hashes could be placed into an array, step through the array and find which parent it is. Then log entries could be username_parent_# - assuming a varchar length of 32 for each hash plus the delimiter would allow for up to 7 parents with parent_password field type of varchar (255). Although at that point it would probably just be better track the parents in a separate table. I was thinking if multiple parents have access there would be no need to track which parent accessed the information. I'm not sure how all of this fits in to what is being planned for roles. But it is always good to brainstorm and bounce ideas around.

Average of ratings: -

Re: $username_parent - super!

by Ne Nashev - Tuesday, 21 February 2006, 6:52 PM

I think all of child parents may have one (system-mantained) login and _one_ password for this login. I can't see why we can want to make more then one anonymous parent's login for child.

System with $username_parent - is may be maked without "roles" subsystem. And now i think that's good.

Average of ratings: -

Re: $username_parent - super!

by Will Gillen - Wednesday, 1 March 2006, 2:14 AM

I personally think this is a bad idea both from a system architecture and pedigogy standpoint. I think Moodle should continue to view the parent as a key role in the learning experience (especially within the K-12 area). Making the parent their OWN USER may mean a little more overhead from an enrollment management standpoint, but it allows for SO MUCH more parental involvement in the child's learning process and development. Previously, online learning was thought of having only 2 roles: teacher, and student. This paradign is changing, and there are really 3 roles now: teacher, student, and parent!

Take a look at the laws within the U.S. (particularly FERPA) which state that parents MUST have access to student records. This means, that if Moodle is to survive in the U.S. secondary school system, the role of parent must be integrated. Assigning permissions on the role of parent can be adopted at an implementation level (give each school the ability to configure parental interaction at a configuration level). What I mean is this: make the parent a full blown "user" in the system. Then, assign which students they are parents for, and allow them access to view all their student's progress (assignments, grades, etc.) In U.S. secondary schooll systems, parents should be considered as much a part of the learning process as the student and teacher are. This allows the teacher to communicate with both the student and the parent, and you will see the parental involvement in the learning process become greater and greater.

Personally, I think this is the correct way to go, don't just plug in a new column; make the parent a part of the core online learning experience.

-- Will Gillen

Average of ratings: -

Re: $username_parent - super!

by Michael Penney - Wednesday, 1 March 2006, 3:15 AM

So long as it is easy to switch off at 18, where FERPA requires student privacy.

Plugging in the new column now might make it possible to have a standard level for parental access now, once roles are implemented then site admins can create parent roles for their particular local laws and politics.

Average of ratings: -

Re: $username_parent - !super

by Andrew McMillan - Wednesday, 1 March 2006, 5:01 PM

One problem with depending on a "_parent" extension to the username would be that it is too specific to dealing with parents.

There are some other analogues of "parent" which it would also be nice for role handling to cope with. One roles and relationships model that I am looking at dealing with at the moment, for example, would like to try and handle the relationships of:

"Student"
"Student's Development Planner"
"Student's Manager"
"Student's Sponsor / Patron"
"Student's Teacher"

While I can see some commonalities in the way _some_ people have described the level of access that "Parents" might get with what "Manager" get in my relationships, the real access controls applied would vary wildly from site to site and country to country which would reduce the value of being _parent specific - not to mention i18n issues.

Another problem with being _parent specific is that it opens the way for a plethora of "_role" things without addressing the deeper issues involved in how the permissions can be controlled in the database. The interface needs to allow definition of quite fine-grained control, but without burying the user or administrator in a plethora of options.

For my own problem above I've more or less concluded that (a) some of the client's defined roles will never actually be used, as an accessible & transparent UI won't be achievable; (b) it's just too weird to try and do it inside Moodle right now; and (c) if we do it outside of Moodle, once we've actually got the darn thing doing the needful we might be able to see a more elegant solution that we _can_ propose for core implementation.

Regards,
Andrew McMillan

Average of ratings: -

Re: Relational Roles

by Ne Nashev - Wednesday, 1 March 2006, 6:22 PM

It is may be named as "Relational Roles" and his "Relational Permissions"...

(remark: It is, i tink, new word in security!

Before here i no where havn't read about this!)

It is when permissions of user specifed not only by Role, but by role and relation to something other, like other user. Example - when we attach user to role "Parent" we must set for this user role relation to user's childs.

Without "Relational Roles" it may be representd as more detailed permissions - like generation permission "View details of user1", "View details of user2", "View details of user3", etc for each user, and give it personally to each parents, and check it when displaying details of user... But here we anyway can't work without automatically generating list of needed permissions for view this details - and it's in result will be untwisted to "Relational Roles".

Average of ratings: -

Re: Parents and criminals

by Andrew McMillan - Wednesday, 1 March 2006, 5:12 PM

Hi Sam,

As I see it, the 2004 roles proposal looks pretty well done and flexible, as far as course-related role definitions go.

It has no coverage at all of student-related role definitions Parents, Tutors, Managers for example. Or even "Prison Supervisors", to extend your "Prisoners" concept further.

Has your work so far done any extension or thinking around this?

Regards,
Andrew McMillan

Average of ratings: -

Re: Roles and Permissions architecture

by Humair Syed - Tuesday, 28 February 2006, 7:37 PM

Hi,

I am implementing the architecture you drafted in 2004,
I ran into problems after implementing the documented changes/additions.
I have to work in each module to make it work.

Did I miss something that bring me these problems.

~humair

Average of ratings: -

Re: Roles and Permissions architecture

by Matt Oquist - Tuesday, 28 February 2006, 11:22 PM

Ahh - that architecture does look quite good. (I hadn't seen the spec until just now.)

Yes, this will require changes throughout Moodle, as the specified APIs will all change. Is this what you're asking about, Humair?

One thing I do question is adding a "roles" architecture to Moodle, as opposed to just using groups to fulfill the same purpose. Why can't we make each of the "roles" into a named group, and then give each group the appropriate access to whatever they need? Then we'd have a "teachers" group with all the appropriate members (there can be a site-wide group and per-course groups), and that group can be given all the appropriate access to create courses, enroll students, do grading, etc.

In addition, this could then make use of the access_control module that I've already implemented. It already supports plugins that define their own "access types", which would be "capabilities" for our purposes here. So we would add a "capabilities" plugin under access_control/plugins/, beef up group management to make it easier to have site-wide groups, and then change all the modules to use APIs that manage groups ("teachers" for example) and use the access_control module under the covers.

Hmm. Right now the access_control module gives you APIs to present and process forms that changes access_controls and ownership, which means that it already supports changing who (which "roles") has a specific type of access ("capability"). But what we'd really want here is a page that allows you, for a given user/group/course ("role"), to choose from a list of specific access types ("capabilities"). That's interesting, and I'll have to think about how it may work to make a generic API that can present that type of form in a way that is easy for developers to code and for users to use.

This is just brainstorming on my part -- I'm not convinced that the access_control module is the best way to take care of roles and capabilities, but since it's a completely generic module that handles any type of access for any type of object, and it comes with a (IMO) robust set of APIs and user interfaces, it certainly seems like a viable option to me. I'm hoping to make the access_control module as appealing as possible for inclusion in the Moodle core, and if it ever reaches that point I fear that it will be redundant to have implemented an entirely independent roles & capabilities architecture, which does a lot of similar things but is more limited in scope.

Maybe what I need to do is write up some more attractive API documentation for the access_control module, so it's more obvious how powerful (I think) it really is. It's got an ASCII text file ATM, but maybe that's not doing the trick...

Average of ratings: -

Re: Roles and Permissions architecture

by Matt Oquist - Wednesday, 1 March 2006, 11:44 AM

I thought of a distinct lack in the access_control module that reduces its flexilibity below that of the proposed specification for roles - the access_control module is extensible to include arbitrary access types ("capabilities") by plugin, but not at runtime. I should've designed it differently. As it is, it can still be changed relatively straightforwardly, but I don't have time to do it now.

Average of ratings: -

Revised proposal

by sam marshall - Tuesday, 7 March 2006, 12:15 AM

It's probably best if nobody tries to implement this. We/Martin D/somebody are likely to implement a revised proposal, which has significant changes. (Yes, any such work does involve changes in many areas.)

I have attached a revised proposal. (This was written by Thanh Le and mys'elf after a meeting here to discuss requirements, based on that previous proposal.)

Please bear in mind that this is only a draft and Martin D identified a few problems with it, specifically re our intention to get rid of the 'built-in' roles and replace them with capabilities, which makes supporting legacy enrolment plugins difficult as they don't know which role to add for what used to be a 'teacher' say... however I think that can still be addressed using a minor misuse of capabilities if we give some roles the 'defaultteacher' and 'defaultstudent' capabilities say.

I don't know if anything has been agreed re implementing this (i.e. whether we are paying someone to do it, when they will).

--sam

Roles_and_capabilities.doc

Average of ratings: -

Re: Revised proposal

by Martin Dougiamas - Tuesday, 7 March 2006, 9:11 PM

Yes, this will be the first task for moodle.com after 1.6.

Average of ratings: -

Re: Revised proposal

by Matt Oquist - Thursday, 30 March 2006, 7:21 PM

Interesting; I'm looking over your revised proposal and the capabilities part is much more mature (IIRC) than the previous one. Again, I am compelled to point out that I've already implemented an access_control plugin that (as far as I can tell at this point) does everything your revised proposal for the capabilities architecture would do.

I've written up a document about the data storage and the APIs. This will be in CVS later, but for now I've just attached it here.

I'll do a bit more writing and thinking about it and upload my own "revised proposal" later (today, hopefully), but it seems to me ATM that simply implementing generic groups in Moodle (these will store the "roles"), using my existing access_control plugin, and implementing a handful of front-end APIs will take care of the entire set of requirements for the roles & capabilities architecture as it's being discussed here.

developers-documentation.pdf

Average of ratings: -

Re: Revised proposal

by Matt Oquist - Thursday, 30 March 2006, 7:23 PM

I've attached the flowchart that is referenced on the first page of the developers-documentation.

Ha! If I attach it, we get a huge graphic displaying inline. Here's a URL instead.

Oy, and I have to upload another attachment anyway, because I don't see a way to get the inline image out otherwise. So the file is also attached, but you'll have to change the extension to view it.

access_flowchart.png.fake

Average of ratings: -

Re: Revised proposal

by Martin Dougiamas - Thursday, 30 March 2006, 8:00 PM

Hmm, can you talk about this further?

Is every step in your flowchart a database access? How would it support the question "show me all the users who have discussion deletion privileges in this particular forum?" or "show me all the activities that I can see in this course?"

Average of ratings: -

Re: Revised proposal

by Matt Oquist - Friday, 31 March 2006, 1:00 AM

Is every step in your flowchart a database access?

At this point, yes. In fact, some of those steps involve calls to other methods and perhaps multiple database queries -- yikes! In the current implementation of access_control, I was aiming for API clarity and simplicity, and it was also a proof-of-concept for myself, in a way. But there's no reason it couldn't be optimized significantly. Here are a couple optimizations that have been simmering in the back of my mind:

Add a CSV-IDs property to access_control for checking/retrieving/processing access for multiple entities simultaneously. That is, instead of having a PHP loop that sets fkid and calls the same access_control method repeatedly, making one DB request per call, just set fkids='1,2,3,4,5,6,7,8,9' and call the method once. The method should realize it got fkids instead of fkid, and use 'fkid IN (...)' instead of 'fkid = ...' when it accesses the DB. This is relatively low-hanging fruit...I estimate 3-5 hours of work to do it.
The same sort of thing that Sam and Thanh propose on pages 8-9 of their revised proposal, where the code constructs one giant mother SQL query and grabs everything at once, and then intelligently processes the results afterwards. BUT I'm way behind the curve on this one. I haven't really thought about how to implement this optimization. Even without completely optimizing down to a single DB access, several of the methods should be optimized in themselves to do fewer queries than they do now. (For example, access_specified_bygroup() is an internal method that comes to mind here.)

How would it support the question "show me all the users who have discussion deletion privileges in this particular forum?"

To ask this question in code, you could write something like the following:

$ac_defn = array(

    'description' => 'forum',

    'access' => 'discussion deletion',

    'yesno' => ACCESS_GRANT,

);

if (!$users = access_get_users($ac_defn)) {

    error("Oops");

A query such as this fetches the results:

SELECT designee, 1 FROM mdl_access_control
WHERE fkid = '4'
  AND description = 'forum'
  AND yesno = '1'
  AND access = '247'
  AND designee_type  = '1'
  AND designee != '0'

The access is set to whatever numeric value that the forum module has designated for 'discussion deletion'. The designee_type of 1 is actually defined() as ACCESS_BYUSERID, BTW; this query would find all the IDs of users who've been granted the specified access to the specified forum (with ID 4).

Suppose you wanted to control access to specific posts -- then you might want a description like 'forum_post' (or 'forum post' -- it doesn't matter) and you can still use the APIs the same way, with the same access types, etc. For the most part I'm using defined() constants throughout my code, so my descriptions and designee_types are grouped nicely and less typo-prone.

If we head toward a groups/access_controls "roles/capabilities" architecture, then it's likely you'd have a role-group named something like forum_moderators, and you'd want to call get_groups() instead of get_users(). The resulting query would be the same except the designee_type would be ACCESS_BYGROUPID instead, and then you'd have to get a list of the users in the group(s) in your result.

I need to think about it more, but off the top of my head I'd say to just set the fkid=0 to specify access for forum super-moderators, who moderate all the forums. It might be a good idea to enhance the access_control plugin slightly to help handle this; it would probably be similar to the way designee is set to 0 when everybody is set. We wouldn't need another field in this case, we'd just need the access_control code to recognize that a fkid==0 means that the specified access is granted to all 'description' entities. This might be anywhere from 10 minutes to 2 hours of work. *shrug* OTOH, I've been awake for about 22 hours now, so after I've slept I may realize the "right" way to do it that doesn't require any additional work.

"show me all the activities that I can see in this course?"

Ahh - this one is more complicated and interesting.

It would be very easy without the "in this course" part, so I'll go through that first. You'd write the following:

$ac_defn = array(

    'description' => 'activity', # or maybe 'course_activity'...whatever

    'access' => 'read',

    'yesno' => ACCESS_GRANT,

);

if (!$activityids = access_find_user_shares($ac_defn, $USER->id)) {

    error("No soup for you!");

A query like the following would do the work:

SELECT DISTINCT fkid, 1 FROM mdl_access_control
WHERE description='activity'
  AND designee=$USER->id,
  AND designee_type=ACCESS_BYUSERID,
  AND yesno=ACCESS_GRANT,
  AND (access='2' OR
       access='1')

This gets a list of all the IDs of activities that $USER's been given 'read' or 'write' access to. (One feature of access_control that I haven't mentioned yet is the ability for callers to consider one type of access as implying another type; that's why we see two access values here.)

If you want to ask your more interesting question in the most efficient and convenient way, the access_control plugin would need to be enhanced slightly -- and that's a good idea. It would be quite simple (est. 1-2 hours with testing) to enhance the find_user_shares() method to take in a specific list of IDs. Then the same query as above would run, except that it would have " AND fkid in (1,2,3,4) " added to it. Then the caller would fetch all the IDs of the activities in this course and call access_control->find_user_shares() to get the answer. The caller's code would look something more like this:

$allactivityids = $course->get_all_activityids();

if (!$activityids = access_find_user_shares($ac_defn, $USER->id, '', '', '', $allactivityids)) {

    error("No soup for you!");

Well, this post is probably long enough for now, and I must needs sleep.

Average of ratings: -

Re: Revised proposal

by Matt Oquist - Friday, 31 March 2006, 2:51 PM

Slightly updated document attached with info about primary keys.

developers-documentation.pdf

Average of ratings: -

Re: Revised proposal

by Matt Oquist - Thursday, 30 March 2006, 11:11 PM

Here's another way to think of what I'm suggesting, leaving aside the fact that I've written a bunch of code.

Why should we implement roles and capabilities when we can generically implement groups and access controls, and then use those to handle roles and capabilities? That way we end up with great group and access control features that can be used extensively throughout Moodle, and we won't be duplicating any data, code, or UIs, and we won't be hacking generic functionality into a narrowly-specified system as an afterthought.

And quite honestly, that's why I wrote the access_control plugin. I could've written some little hack that would handle publication of portfolio items, but what's the point of writing something that's so limited by design, and that will need to be duplicated every time somebody wants to do the same thing in another plugin/module?

At the very least I hoped to provide an inspiring prototype, and it'll be even better if we can massage it into working for Moodle without reimplementing it. It was very encouraging to me to see that the capabilities piece of your revised proposal is so very similar to what I ended up implementing.

I must say, however, that I'm not following the "contexts" part of your proposal. Hmm. As I look at it again now, it seems like you're using that to do what I've shoved (perhaps too simplistically) into the "description" field. Here's a fundamental assumption that underlies my access_control implementation, and which may differ from your approach: For the sake of being generic, the access_control code should be entirely agnostic about the data it stores and processes.
Thus it is up to the API callers to identify and set owners, create and manage access types and access instances, and ensure that access controls are deleted when their corresponding entities go away. The access_control plugin only provides generic APIs to take a lot of the programming work out of doing rich and extensive access controls.

More later.

Average of ratings: -

Re: Revised proposal

by Martin Dougiamas - Thursday, 30 March 2006, 11:58 PM

I can see I'm going to have to have a good look at your access_control code (I haven't yet!) and have a think about it.

In particular I think we have to consider performance as a key requirement as these things will get used for every access, which means being able to cache this information in the session and not access the database.

Keep talking.

This stuff is too important for us to get it wrong.

Average of ratings: -

Re: Revised proposal

by Matt Oquist - Friday, 31 March 2006, 1:08 AM

You're absolutely right, and I think this is the greatest weakness of my current implementation. I know we could take what I've got now as a starting point and make it leaner and meaner; I just hope it can be lean and mean enough.

And, worst case(?), we look at what I've implemented as a prototype or model, and learn from it (and from Sam and Thanh's proposal) as we implement something truly great.

OK, time for sleeping now.

Average of ratings: -

Re: Revised proposal

by Matt Oquist - Friday, 31 March 2006, 1:35 AM

Still not sleeping.

I was just thinking -- there's no reason we couldn't implement some specific APIs to do specific types of access control handling. These could be made much, much more efficient than the completely generic can_designee_access() method.

Especially WRT to roles & capabilities specifically, we could do something like this (TOTALLY shooting from the hip, here...):
$ac_defn = array(
    'description' => 'forum',
    'fkid' => 4,
    'access' => 'delete',
    'designee' => $USER->id,
    'designee_type' => ACCESS_BYUSERID,
);
if (!access_by_role($ac_defn)) {
    error("No, no no!!!")
}

That routine would specifically and directly execute a single query that checks for the user having access via membership in a group that has been given access. In fact, now that I think about it, the existing (up-to-now internal-only) access_specified_bygroup() method would do exactly this once it's optimized as it should be anyway.

So maybe we can have our cake and eat it too just by choosing not to use all the most generic features of the plugin all the time. That way we can still offer the generic features, but also provide highly optimized APIs for specific purposes/callers.

NOW I WILL SLEEP, or at least lie in bed thinking about Moodle, which is more likely...

Average of ratings: -

Re: Revised proposal

by Matt Oquist - Friday, 31 March 2006, 6:30 PM

After some more thought, I'm pretty sure we can get the generic can_designee_access() down to a single query, too, except for that last item in the flowchart; checking for parent entities and their permissions really should continue to be handled recursively, because trying to write a single query to handle that would be insane if it's even possible. But if each recursive call only does one query itself, we're still way ahead of where things are now.

The pursuit of this optimization is oscillating between #1 and #2 on my todo list.

Average of ratings: -

Re: Revised proposal

by Matt Oquist - Friday, 19 May 2006, 3:50 AM

And along the same lines as my belief that "roles" and "groups" should be the same thing, I still think that it would be best to have a more generic design overall.

I'm thinking of repository resource ownership and permissions as a problem I don't believe this proposal addresses very well. It doesn't make sense to me that the on-the-disk, local Moodle repository would have its own ownership and permissions data storage and management, separate from the proposed system. Duplicating such similar code strikes me as silly, but I'm having trouble seeing how the proposed R&C system could cleanly handle file ownership and permissions.

If the following two concerns can be allayed, I will feel much better about this proposal:

hierarchical R&C granting
- Can the proposed system deal with situations where a user should have a capability in virtue of having another capability? This could probably be done by adding another (self-referential) column to your capability_contexts table: "capability_contextid". But I see nothing in the current proposal addressing this.
- Now that I've written the above, I'm trying to think of a compelling example to illustrate why this matters, but in every case I've thought of a slightly different design of the API callers makes this unnecessary. I'll have to keep thinking about this; it's been too long since I was working with this aspect of my access_control plugin. Perhaps even though I found this hierarchical approach to be worthwhile, it's just one way to handle the situations where I'm using it.
fine-grained ownership & permissions management (such as a file repository will require)
- See the above paragraphs.
- As I try to envision how this system could handle fine-grained file ownership & permissions, I find myself worrying about [seemingly unnecessary] proliferation of table rows. Would we have a "write" role with a "write" capability assigned with a capability_context that specifies a fileid? That seems to be unduly complex.

Average of ratings: -

Re: Roles and Permissions architecture

by N Hansen - Wednesday, 3 May 2006, 11:20 PM

I know that roles are some way off with Moodle but in a discussion I had with a student the other day a "role" came to my mind. The role would be one where a student had completed all of the requirements of a course (ie assignments, quizzes etc.) but wished to have continued access to the course material for review or consultation. The course in question I am thinking about this for is a language course, but any other course could be like this. The key factor is that I would like to give access to the completed student to the notes he read, his work and the teacher's comments on it, but he would not be allowed to do anything that would take up the teacher's time. In other words, a sort-of read-only access to the course. How forums, which might contain pertinent information, would be handled, is a bit sketchy. Perhaps the student would be shown only what was in the forums at the time he completed the course. He would not be allowed to see any new posts or add any himself. Same thing for database and glossary entries. In other words, a snapshot of the course at the time his regular enrollment ended. I am thinking I would like to offer such access at a low six-month or annual fee.

Average of ratings: -

Re: Roles and Permissions architecture

by William Mudge - Thursday, 4 May 2006, 8:33 AM

Backup the course and restore to a new course, make some wording changes to indicate that this is not reviewed by a teacher any more, and is only meant for reference. Move the student enrollment across.

As more students got moved across, you could wipe and re-create the course with the new content. Students would need to be aware that anything they'd been doing in this version of the course may dissapear, but they could nevertheless still interact with each other (the group of "ex-students"), without incuring "teacher time", and this could be seen as a value add to those students.

Resource intensive, and issues with progressively adding students (changing content, admin time etc.) but might work in the mean time while we wait for more varied roles.

Just a suggestion.

Average of ratings: -

Re: Roles and Permissions architecture

by N Hansen - Tuesday, 16 May 2006, 9:06 AM

William-The problem is my course is offered on a rolling enrollment basis. I might want a student to only have access to what existed when they left the course. In other words, I wouldn't want them to be able to see new forum posts that were made after they left. Since it is on a rolling enrollment basis, for different students that would mean different posts.

Average of ratings: -

Re: Roles and Permissions architecture

by Martin Dougiamas - Tuesday, 16 May 2006, 5:32 PM

WHat about if they could still see the course but not contribute?

ie a read-only role.

Average of ratings: -

Re: Roles and Permissions architecture

by Martin Dougiamas - Monday, 15 May 2006, 3:11 PM

Regarding this, I'd really like to hear from people (primarily teachers/policy people, not so much developers) about what they would like a role to do in a user context That is, when you are given a role relating to some other user.

For example, Parents: what should they be able to do in relation to the student they have that role in?

Same for a Manager Role.

Your input would be very useful right now as we are working on polishing the specification for Roles in 1.7.

This wiki page is the place to brainstorm: http://docs.moodle.org/en/Roles#Parent

Average of ratings: -

Re: Roles and Permissions architecture

by Just H - Monday, 15 May 2006, 3:21 PM

Hi Martin

Ideally, I'd like to see permissions treated the same way Drupal does i.e. it is up to the site owner what roles, how many roles, what the roles are known as and what permissions each role is given.

Not sure if that would be possible with Moodle as the code stands but from a quick look at Drupal the other day it would appear to be highly flexible and covers any situation a person can think of. I believe this model would be ideal for all Moodle users whether K12, corporate, government or whoever else is using it.

I think not only would it be more flexible and give more power to users (as in site owners, not students) but easier too i.e. with the ability to create whatever roles we want, no need to hack code or mess with language files.

Regards
H

Average of ratings: -

Re: Roles and Permissions architecture

by Martin Dougiamas - Monday, 15 May 2006, 3:35 PM

Drupal is actually a very simple model. It seems to only have site-wide roles and each person can have one of them. We'll have roles in various contexts and each user can have a number of them. To do what Drupal does will be easy in Moodle.

Regardless, this is not the question I was asking (Drupal doesn't support permissions/capabilities related to users).

Average of ratings: -

Re: Roles and Permissions architecture

by Martín Langhoff - Monday, 15 May 2006, 4:24 PM

I know you aren't asking developers but I can't resist chiming in with some recent insight

We were recently struggling to figure out how do to a 'manager view' without implementing full blown user roles, messing up all the codebase, and without infringing upon other user's privacy in the social activity.

And what we are doing for this case is enabling the "user activity reports" page (outline report/ complete report) as an overview of the user's activity for managers, parents, etc. And we avoid having to make complex code changes.

It is cheating, but when cheating works... does it make it right?

Average of ratings: -

Re: Roles and Permissions architecture

by N Hansen - Tuesday, 16 May 2006, 7:44 PM

Martin-Will the current roles still exist-admin, teacher, student, editing teacher etc.? It seems to me that there should be some standard default roles to make it simple for those who don't want to/don't know how to configure roles.

Average of ratings: -

Re: Roles and Permissions architecture

by Chardelle Busch - Tuesday, 16 May 2006, 11:15 PM

Hi Martin,

For both the Manager/Parent (have the ability to read-only) and the Mentor/Tutor (include ability to grade/comment) roles, I need to have the ability to assign which students they can have permissions for. This will be only a subset of the enrolled students. How will this happen, with groups? Or maybe a "permissions" tab in their profile where admins can add the students they have permissions for?

Average of ratings: -

Re: Roles and Permissions architecture

by sam marshall - Wednesday, 17 May 2006, 8:23 PM

You don't need to ask Martin for this - pretty sure anyone could answer it. Whichever roles & permissions architecture is implemented, the automatic database upgrade to the new version will transfer all your old roles.

So yes there will be a 'student', 'teacher', 'editing teacher' etc role. for any upgraded system (depending on the user they might want to delete these roles or change them, but they don't have to).

I'm sure that roles like these will be configured by default for a new installation too. And setting people up in the roles (e.g. adding students or teachers to a course) might look slightly different but is bound to be fundamentally the same.

In other words

Don't Panic

--sam

PS I haven't had time yet to look at the other proposals etc. - basically will do so if/when Jason tells me to

PPS We have already come up with a use case for a new 'context' for roles that we hadn't thought of in our original proposal

It would fit easily into that system though.

Average of ratings: -

Re: Roles and Permissions architecture

by Martin Dougiamas - Thursday, 18 May 2006, 10:37 AM

Yes, like all Moodle upgrades the default configuration is to maintain the existing settings.

I suspect a lot of people will just continue on and never delve into the Roles settings at all.

Average of ratings: -

Re: Roles and Permissions architecture

by Colin McQueen - Thursday, 25 May 2006, 10:01 PM

Here are some suggestions:-

A parent of one or more children in any instance or cluster of Moodles (Think about LEA wide or local primary>secondary cluster wide moodles) would probably like to view a summary for their children much like a weekly/monthly/termly/annual report.
A parent may need to confirm reading the weekly/monthly/termly/annual summary of their child's learning attendance etc. and perhaps add a comment.
A parent may want to be a member of the PTA moodle course/area and so be a fully contributing user. Perhaps though that ought to be a separate Moodle for the PTA without the child linking being necessary.
In early years and KS1 and for parents of children with literacy issues the parent may need to be able to support the child in contributing to forums, quizzes etc as an amanuensis (dunno how to spell this and I can't be bothered to look it up ... Oh spell check .... wow it looks like it's in the dictionary! Is that right?). This could be using the child's id but there could be an amanuensis id to record who actually did this?
In some cases there may be a need for parent<>teacher communication where they refer to the child's work/contributions without the child being present or party to discussion. This happens face to face. Would that interaction transfer to an on-line one?

I'm sure there are more. Not sure if any of this helps but you did ask. I'm a parent of school children, a teacher, an LEA adviser/consultant and amateur programmer developer wide eyes

Average of ratings: -

Roles in Moodle 1.7 - How to implement parent role?

by Anthony Borrow - Saturday, 16 September 2006, 8:27 AM

As I understand the concept of roles as it is being implemented in 1.7 it allows for a given user to have access to certain activities, resources, etc. It is less clear to me how this interface will be used to create a parent role. Is there a way in 1.7 to associate a user as having some type of relationship or role to another user. In other words, can I say that user ParentJSmith is the parent of user JSmith and therefore can see his grades, but not view forums or submit assignments on his behalf? As I begin playing with 1.7 I would like better understand how the roles are designed to work and possible limitations of the current model. Any insights would be appreciated. Peace.

Average of ratings: -

Re: Roles in Moodle 1.7 - How to implement parent role?

by Martin Dougiamas - Saturday, 16 September 2006, 8:46 PM

Basically you go to the user's profile and use the new "Roles" tab there.

Normally you would create a Parent role at Site level, then go to that user and assign a particular user to be a Parent of that user.

You can override four capabilities in the user context at the moment (it's easy to add more as we think of them).

http://docs.moodle.org/en/Roles#User-level_Capabilities

1. moodle/user:readuserposts -read individual user posts on profile page
2. moodle/user:readuserblogs -read individual user blogs on profile page
3. moodle/user:viewuseractivitiesreport-read individual activity report on profile page
4. moodle/user:editprofile - edit profile (normally used in CONTEXT_USERID and CONTEXT_SYSTEM)

A fifth one is not in the override list at the moment (that's probably a bug), it's moodle/user:viewusergrades.

Interface-wise what all this means to their parent is that they can see the same sort of tabs on their kid's page as the kid usually can see themselves. Note there is a new grades tab in the user profile that just shows the grades for that one user.

Average of ratings: -

Re: Roles in Moodle 1.7 - How to implement parent role?

by Anthony Borrow - Sunday, 17 September 2006, 1:27 AM

Martin - Thank you for the explanation of the roles and how to implement something like a parent role. I am very excited about the new possibilities that roles will allow - a powerful new tool (toy)!

Average of ratings: -

Re: Roles in Moodle 1.7 - How to implement parent role?

by Daniel Denev - Sunday, 17 September 2006, 1:36 AM

Hello Anthony, if you are interesting in roles architekture, implementation and using roles, see my publikations, papers, screens etc. in bulgarian social (Социален Форум) forum at URL http://moodle.org/course/view.php?id=43 or
!!! http://moodle.org/mod/forum/discuss.php?d=53989

Daniel

Average of ratings: -

Re: Roles in Moodle 1.7 - How to implement parent role?

by Anthony Borrow - Sunday, 17 September 2006, 4:28 AM

Thank you for the invitation - unfortunately I do not speak Bulgarian.

Average of ratings: -

Re: Roles in Moodle 1.7 - How to implement parent role?

by Daniel Denev - Monday, 18 September 2006, 3:10 PM

Hello Antony. I know that more people do not speak Bulgarian. смях I was translated all postings before I published. My postings always are on Bulgarian and English. Did you saw that? I plann the postings about BEST (Bulgarian Educational Site) to be on many languages. At this time they are only on English and Bulgarian. I always post very interesting research papers in this forum http://moodle.org/course/view.php?id=43 and here http://moodle.org/mod/forum/view.php?id=3511 nany screens and many sourcecode. Very full of matter and new developped ideas.

With respect: Daniel Denev

Average of ratings: -

Re: Roles in Moodle 1.7 - How to implement parent role?

by Greg Lyon - Thursday, 28 September 2006, 1:30 AM

Hi Daniel, Like Antony I do not speak Bulgarian

I followed your links but can't seem to find the english translations anywhere. I did check my profile on your site and my language choice is en (I tried en_us too), but everything is still greek (make that bulgarian) to me! Any help to see the english translation would be greatly appreciated. I'm trying to understand roles too right now.

Thanks,
Greg Lyon.

Average of ratings: -

Re: Roles and Permissions architecture

by Juliette Culver - Thursday, 18 May 2006, 12:37 AM

Just had a quick look at the wiki page on this - and one context that seems to be missing is that of a group within a course.

A fairly common requirement for instance is for somebody to have teacher type rights for certain groups but not others, and at the same time have some other sort of permissions for the course as a whole. I haven't really thought about it carefully, and I might have missed somewhere where this has been addressed, but I thought I ought to flag it as a possible issue!

Average of ratings: -

Re: Roles and Permissions architecture

by sam marshall - Thursday, 18 May 2006, 1:45 AM

I think this only applies when a new grouping system is implemented (yes, I know that's what you're doing). In the present system if I understand it correctly you can only be in one group within a course, so setting you to have the 'tutor' role for the whole course automatically includes only that one group.

Basically I think you're right that we would need to add 'group' as a possible context once a new group system is implemented. This context would then apply only when involved in activities (or other things) that are related to a grouping including the involved group.

Logically it would be easy to add that context to our proposal. It does offer kind of interesting possibilities in conjunction with groups. To start with you no longer need a separate 'list of users in group x' type table because you can use role_assignments (I am referring to the tables in our proposal, haven't looked at current wiki) to assign people as 'member' in the group context. (Just as the same table does away with the need for teacher and student tables for course membership.)

The group context would be important in pages dealing with group admin tasks, and in activities that had been assigned a grouping (=groupmode on). Other pages don't relate to a specific group.

Using two different roles, say Tutor for tutors associated with a course context and GroupTutor for tutors associated with a group context, you could ensure without any nasty hard-coding that all tutors (whichever group) have capabilities in the course in general, such as perhaps being able to view activities of all different groups, but that they have specific abilities with regard to their own group (e.g. access to contact details).

So I agree using groups as contexts will be important once the group system is expanded.

--sam

Average of ratings: -

Re: Roles and Permissions architecture

by Martin Dougiamas - Thursday, 18 May 2006, 10:45 AM

We've been doing a lot of thinking and whiteboarding here on the OU proposal to try and simplify the GUI without losing flexibility. We have already assumed groups as a context, and that activities will eventually be able to be assigned to particular groups (as per 2.0 roadmap). We're considering ways to have default priorities so that, for instance, a role in a group context would always override a role in a course context, etc.

It's true there is a lot of crossover about groups and roles, in that being in a role is a lot like being a member of a group, but there are also differences that may make it worthwhile keeping the groups tables (just like we are keeping the course tables). For example, groups may have settings and collaborative tools of their own (in future).

Yu or I will post more thoughts on this when we have it written up. It all becomes very involved because it touches on so many facets of how Moodle works.

Average of ratings: -

Re: Roles and Permissions architecture

by Robert Brenstein - Thursday, 18 May 2006, 5:34 PM

A propos groups, what ever happened to having support for teamwork in Moodle? This should somehow be included in the roles and permissions architecture.

A while ago, someone made a nice proposal for having both groups and teams in Moodle, but I haven't heard about any progress. We are sorely missing this and I have seen many posts on forums trying to use groups as teams with mostly miserable results.

By teams I mean a group of students working as a single entity, turning in, for example, a single assignment with grades etc automatically passed to all team members.

Average of ratings: -

Teams

by sam marshall - Thursday, 18 May 2006, 8:44 PM

Roles and permissions were picked as a higher priority than groups, which is why they're being implemented first. I can't speak for the Moodle project's reasoning for that choice, but here at the OU we need a permissions /capabilities architecture so that we can restrict what people can do more accurately even with only the existing tools. Of course we do want groups support too

It sounds like Martin/moodle.com is already considering how groups would work with the R&P stuff.

Looking specifically at teams, I don't think there's any distinction between your 'teams' and groups on a fundamental system organisation level. (Maybe the teams are not the same people as in tutor groups, in which case it does need support for multiple groups similar to what Juliette's been looking at, but apart from that no.)

Are you thinking about marking specific activities as 'team' ones? This would then mean that anyone within a group [or an assigned group leader] could attempt the activity (submit the assignment, etc.) and any marks would be transferred to everyone on that group? If so, I don't think that has any implication for R&P. But maybe I'm missing something...

--sam

Average of ratings: -

Re: Teams

by Chardelle Busch - Thursday, 18 May 2006, 10:20 PM

If you intend to keep permissions at the group level. It would be really nice to have a Permissions tab in the profile that lists the groups (which, for a parent, might be equal to one student) by type (read-only, grading, etc.) for which the person has permissions for. And, if this is done by group, it seems likely that site-wide and multiple groups will have to be implemented first.

Average of ratings: -

Re: Teams

by Robert Brenstein - Thursday, 18 May 2006, 11:25 PM

Yes, I realize that individual roles have to be dealt with first and that the nitty gritty details of dealing with teams will be done (mostly) at activity level. My point was that the architecture of R&P should account for groups and teams right away even if the details are worked out later. There must be a common concept of handling this which will transcend to activity writers, so all activities handle them the same way. Bare in mind that to function properly, teams will be behaving in some ways like individuals and in other ways like groups, so each factors in into permission aspects and may affect the roles.

cf. http://moodle.org/mod/forum/discuss.php?d=29949#144727

I can't seem to find the post with the earlier proposal for implementing groups and teams.

Average of ratings: -

Re: Teams

by Don Hinkelman - Sunday, 28 May 2006, 9:40 AM

Hi Sam and everyone,

I agree that the difference between roles and groups is profound. For example, in the teams/groups in one of my courses, the role of "team leader" rotates around and each person takes a turn. The team leader has different permissions and must design the course for a two week period and conduct assessments of the other members. Then, the role ends, and is passed on to another team member.

Average of ratings: -

Re: Roles and Permissions architecture

by Juliette Culver - Thursday, 18 May 2006, 10:16 PM

My feeling is that distinction should be one at the activity module level. For each activity module that's appropriate, you could choose when it's in 'groups mode' the way that it behaves e.g. whether the group is a team or not in the sense you're using it. So I'd petition the people who work on the activity modules

What I don't know offhand is how grades work across moodle - if you want the distinct ability to give grades to groups rather than giving the same grade to all individuals in a group, then I'm guessing that'd need some changes, but it's not something I'm thinking of touching in the work that I'm doing.

Average of ratings: -

Re: Roles and Permissions architecture

by sam marshall - Thursday, 18 May 2006, 5:42 PM

Our original proposal, or any similarly flexible implementation, could make for a complex GUI but I think there are reasonable ways to expose the functionality. To begin with you're probably right that most people will never touch the settings, so most can safely be placed as 'advanced' options - in other words, I'm just saying that I don't think users without a need for these features have anything to worry about.

--sam

PS Martin, I'm now assigned to monitor this from the OU's perspective (at technical level obviously), so if you want any GUI suggestions let me know. If you're already doing the work though, perhaps best for me just to wait until you've written it up. (There are plenty of other things I'm supposed to be doing too.

)

Average of ratings: -

Re: Roles and Permissions architecture

by Matt Oquist - Friday, 19 May 2006, 2:33 AM

It's true there is a lot of crossover about groups and roles, in that being in a role is a lot like being a member of a group, but there are also differences that may make it worthwhile keeping the groups tables (just like we are keeping the course tables). For example, groups may have settings and collaborative tools of their own (in future).

Why wouldn't it be appropriate to handle the settings and collaborative tools with roles? i.e., I don't see why this necessitates a distinction between "roles" and "groups".

In fact, pending more explanation that changes my mind, I think "roles" and "groups" should be the same thing, and they should be called "groups".

Average of ratings: -

Re: Roles and Permissions architecture

by Juliette Culver - Friday, 26 May 2006, 4:32 PM

There's nothing to do with groups that you couldn't in theory do with roles if you write a good enough library around roles to do all the groups stuff, but you could say exactly the same with courses.

It's a simpler solution in some ways, but I think that conceptually for most people thinking of groups in terms of roles isn't the natural way to think about them. I suspect you'd end up with code that would be quite difficult for anybody who isn't naturally an extremely abstract thinker (which to be honest is the majority of people, even programmers) to modify. Hacking the database would also become much harder.

But I'm also prepared to be convinced that it's easier than I think if someone shows me exactly how they'd do it

Average of ratings: -

Re: Roles and Permissions architecture

by Matt Oquist - Friday, 26 May 2006, 6:50 PM

I was advocating the opposite position, actually. I think we should think about roles in terms of groups. I have more to say about this, but I'm going to wait until I understand the OU proposal better.

Average of ratings: -

Re: Roles and Permissions architecture

by Juliette Culver - Friday, 26 May 2006, 9:10 PM

Sorry, should have read things more quickly!

I'm not involved in the OU proposal btw, but am generally interested because I've spent a fair bit of time thinking about groups in moodle!

Average of ratings: -

Re: Roles and Permissions architecture

by Matt Oquist - Friday, 19 May 2006, 2:50 AM

I'm taking more of a look at it now, and I like the OU proposal better than I did after my first glance a couple months ago.

I still don't quite buy the "capability_contexts" table design, though. I no longer think the simplistic way I did things in access_control is better, because the (description, ID) tuples are specified in the access_control and access_owner tables directly, and they should be in a separate table analogous to "capability_contexts".

But I think a combination of our approaches could be better. I'm picturing a capability_contexts table like this:

capability_contexts:

id (PK)
context_name
context_id

context_name: your current column names would go here: "system", "metacourse", "course", "moduleinstance", "user", etc.
context_id: the corresponding ID (if there is one)

This would accomplish the same thing and be more expandable as far as I can see. Instead of effectively hard-coding the available contexts in your table definition, new contexts could be introduced just by code.

Average of ratings: -

Re: Roles and Permissions architecture

by Matt Oquist - Friday, 26 May 2006, 6:57 PM

I've mostly changed my mind about this; I like the OU's capability_contexts design better now.

Average of ratings: -

Re: Roles and Permissions architecture

by Matt Oquist - Friday, 26 May 2006, 4:07 AM

After thinking some more about my access_control work and the OU's proposal being discussed here, I've written the attached requirements document for access controls (roles & capabilities, permissions) in Moodle.

Thanh just sent me some of the OU's documents as well, so I'll update this document after I go through those; hopefully we can cover all the bases that way.

The idea is to continue this discussion so we end up with the best possible design, so all comments from all quarters are welcome!

requirements-access_control.pdf

Average of ratings: -

Re: Roles and Permissions architecture

by Wesley Wakeman - Friday, 26 May 2006, 7:12 PM

When the parent sets up their account first time you would have to have a wait on approval as well just to make sure it was the real parent so say you'd send a letter or email to their registered address or email address and if they replied etcetera you would then activate the account? This should stop unauthorised people abusing the system?

Wes

Average of ratings: -

Re: Roles and Permissions architecture & IMS-LD

by Don Hinkelman - Sunday, 28 May 2006, 9:14 AM

Hi Matt, Jason, Yu, and Martin,

I am curious to see how universal course/unit/activity interoperability would work with a flexible roles and permissions architecture. In other words, if I moved a course from one LMS to another, would the roles work the same?

We studied the IMS-Learning Design specification here on moodle.org and found they have a sophisticated concept of roles that is built into the international standard. Since Moodle is moving toward full compatibility with IMS-LD through versions 1.7~2.1, how is this standard reflected in the requirements documents by OU, moodle.org, and the SPDC project?

Average of ratings: -

Re: Roles and Permissions architecture & IMS-LD

by Matt Oquist - Tuesday, 30 May 2006, 4:35 AM

Thanks for the pointer, Don. I've only cursorily glanced through the IMS ePortfolios spec; I'm going to look through more of them now because of your comment, but can you help by pointing to any particular IMS specs, pages within them, etc. that deal with roles?

Average of ratings: -

Permissions set at data level

by Paolo Oprandi - Tuesday, 30 May 2006, 11:05 PM

To add a new point to this discussion on roles and permissions I would like to add a view held by many at my institution: VLEs are closed boxes that are rather at odds with the ethos of opensource, MIT OpenCourseware and the web in general.

Attempts in Moodle have been made to reduce this, but even so, entering a Moodle course still provokes a feeling that the course materials are for the students on the course and not for world consumption.

I suggest that if guest access is allowed that no prompt is offered to sign in or sign up as guest (and if I do sign in no warning is given that I am about to enrol on a course and am I sure). I realise you can set your site to be open to Google seaches.

Course administrators would be encouraged to create courses with guest access if there was a higher level of data integrity - i.e. materials/activities could be set to be open to anyone, open only to enrolled users, open only to a group or open only to a user role. Only at the point of selecting a restricted material/activity would the user be asked to log in.

This would also reduce, but not eliminate, the need for the close integration of Moodle with a document management system where course-related documents need to be re-purposed in and out of the VLE.

Average of ratings: -

Re: Permissions set at data level

by Jared Stein - Tuesday, 11 July 2006, 1:49 AM

I agree nearly 100% (though I don't think that one would be asked to login in if a restricted feature was accessed--instead I'd like to see restricted features hidden completely)

We need the ability to make the Guest role one that does not require user/pass.

Carlos Alarco and some of our developers are beginning to plan a modification (probably of the Locked feature) that allows designers/instructors to tag any resource or activity as either "Open" or "Private" (working names only):

A resource/activity tagged as "Open" would be visible & open to all Guest roles (and must also have the "Copyright cleared" designation assigned)
A resource/activity tagged as "Private" would be visible & open only to registered students (provided any other necessary selective release criteria has been met)

What do you all think?

And do we need to include "Visible"? That is, an option could be "Private" to the Guest role, but also "Visible", so as Paolo puts it a Guest could see but not access it?

Average of ratings: -

Re: Permissions set at data level

by Paolo Oprandi - Tuesday, 11 July 2006, 3:22 AM

The only danger in resources/activities being hidden is that students may go to a course and not realise that they need to log in to get the additional material. In any case, it sounds great!

Average of ratings: -

Re: Permissions set at data level

by Jared Stein - Tuesday, 11 July 2006, 3:49 AM

That's an excellent point. Perhaps this could be solved by having two access portals: one for students, the other for the community.

Anyway, I do see an issue with removing the user/pass system altogether even for Guests: I can imagine some opencourseware projects wanting to allow open learning communities to develop, and you can't very well do that if everyone is anonymous.

Average of ratings: -

Re: Permissions set at data level

by nabil Lachheb - Friday, 4 March 2011, 5:03 PM

Hi all!

Hello paolo oprandi, 5 years after, I agree 1000% with you .

Your contribution/idea/point of view is exactly what i'm planning to do: All courses should be opened to guest (+google) and then Permit/Prohibit "stuffs" for each Role at each level.

Im not a Moodle core developper, neither teacher but i've been playing around Moodle for a long time and TODAY my vision of a School Portal running under Open Source Application is to be completely Open (lol).

(i would like to contribute with my visions, but my english is too poor as the French Community resources )

Will share the results (portal design + navigation design) very soon.

Average of ratings: -

Capabilities

by Artem Andreev - Tuesday, 11 July 2006, 5:34 PM

May be extend capabilities list?..
Site-level Capabilities
moodle:viewreports

Course-level Capabilities
course:viewreports

Average of ratings: -

Re: Roles and Permissions architecture

by N Hansen - Sunday, 30 July 2006, 7:55 PM

In reading over what has been said about this here and in the documentation, several things still remain unclear to me:

Who has the ability to create roles and set permissions for them? Who has the ability to assign users to roles?

In the documentation, there are core level and module level permissions? But what about permissions for specific instances of modules? That doesn't seem to be spelled out anywhere, but it is implied in the following example:

For example, Jeff has a naughty student role that prohibits him from postings in any forums (for the whole site), but he's also assigned a facilitator role in "Science forum" in the course Science and Math 101.

I'm assuming this means we will be able to fine grain permissions on a module-instance level? I'm assuming the specs will be the same as the overall permissions for those modules? Am I correct?

Following from that, if the capability of doing anything related to a particular instance of a module for a particular role is set to prohibit or prevent, wiill someone in that role still be able to see the instance of that module on the course page? Or will it be invisible to them?

And again, related to the previous question, in terms of making things easier to use, could there be a way of simply setting all permissions for a particular module (or module-instance) to one of the various capabilities at once? For example, forum has 15 different permissions that can be set for it-it would be helpful if we could set all 15 to the same thing at once if necessary, rather than have to set 15 individually.

Also, what about the enrollment process? Will it be possible to enroll in courses directly into particular roles? If so, how will that be handled vis-a-vis something like the Paypal module?

Thanks in advance for any answers you provide, but if things actually will work as they seem to be described, this new feature will solve a big problem I have had that I thought wouldn't be fixed until 2.0 at the earliest, so I'm very excited about this.

Average of ratings: -

Re: Roles and Permissions architecture

by Martin Dougiamas - Monday, 14 August 2006, 9:48 AM

>Who has the ability to create roles and set permissions for them? Who has the ability to assign users to roles?

People who you give roles that include that capability to (like any other permission).

>In the documentation, there are core level and module level permissions? But what about permissions for specific instances of modules? That doesn't seem to be spelled out anywhere, but it is implied in the following example:

For example, Jeff has a naughty student role that prohibits him from postings in any forums (for the whole site), but he's also assigned a facilitator role in "Science forum" in the course Science and Math 101.

Yes, this is exactly right. Read the documentation more closely about contexts. Roles are granted to a user in a context.

> I'm assuming this means we will be able to fine grain permissions on a module-instance level? I'm assuming the specs will be the same as the overall permissions for those modules? Am I correct?

Yes.

>Following from that, if the capability of doing anything related to a particular instance of a module for a particular role is set to prohibit or prevent, wiill someone in that role still be able to see the instance of that module on the course page? Or will it be invisible to them?

Currently they will still see it, because testing ALL permissions for every activity on a course page would be too expensive. This will be solved later as part of conditional activities and new groups.

> And again, related to the previous question, in terms of making things easier to use, could there be a way of simply setting all permissions for a particular module (or module-instance) to one of the various capabilities at once? For example, forum has 15 different permissions that can be set for it-it would be helpful if we could set all 15 to the same thing at once if necessary, rather than have to set 15 individually.

We might add this to the GUI later but you won't need it as much as you think you will because you aren't assigning these capabilities to individual people, but to Roles.

>Also, what about the enrollment process? Will it be possible to enroll in courses directly into particular roles? If so, how will that be handled vis-a-vis something like the Paypal module?

This is one of the things yet to do, but yes. It needs to be done because "students" and "teachers" are fluid concepts now and the user_students and user_teachers tables are going away.

There are two ways of referring to the Roles for something like this. The first way is by direct reference, though this can be fragile because you might remove/change roles. The second way is indirect, by referencing the "legacy capabilities", which act like tags to say that "this role is really the 'student' role, even though I'm calling it something else and have changed what these people can do". So you can still make people "students" in the old language and the plugin will be able to find which role(s) to assign to those users.

Average of ratings: -

Re: Roles and Permissions architecture

by N Hansen - Monday, 14 August 2006, 8:10 PM

I posted this over in the docs but I'll post this question here too, as this is really one of the key things I am trying to understand about roles. I'm not so interested in what role is the "student" role even if it is different, what I am wondering about is the possibility of assigning different roles from the outset to what might be called a "legacy" student in a course. For example, now we have a single button that allows a student to enroll in a course as a student. In this case, they are enrolling directly into a student role. But what if you have a course where you have different types of student roles each with different capabilities assigned to them? In what role will those students be enrolled? Will they be able to choose a role when they enroll? Or will there be a default "student" role for that course? At the moment, you talk about certain higher level people having the ability to assign roles. What I am thinking about is in a way is giving a student a way to assign a role themselves, but only to themselves? Is this possible?

In looking over the feature requests for an improved payment plugin, a lot of what people are looking for involves selling different types of course packages and I think roles would really help with satisfying a lot of those needs if they could be tied in with roles. For example, imagine a course with a trial membership role (with read-only priveleges) and a full partiicpant role (with the ability to do anything a student normally can do). The trial membership costs $5 and the full participant option costs $50. I realize the ability to set different prices doesn't exist yet (nor different enrollment periods) but that is something I think can be incorporated into a new payment plugin, so for the moment let's just imagine they do. What I need to know is there going to be any built-in ability to self-select a role for themselves or must it always be assigned to them by someone else?

Average of ratings: -

Re: Roles and Permissions architecture

by Martin Dougiamas - Monday, 14 August 2006, 9:34 PM

The enrolment plugins will have to decide what roles people are assigned, it's not a function of Moodle core. They may choose to allow students to choose, they might not. I look forward to seeing what happens with new plugins there.

Average of ratings: -

Re: Roles and Permissions architecture

by Angel Rojas - Friday, 4 August 2006, 4:17 AM

first of all sorry for my english I´m from Guatemala so.

Well I was thinking in add a new user, pasword and mode=(student or parent) to the students table, depending of which mode the user gets loged the permissions changes.

example.

user: pepe vars

student uses:
user=pepe , pwd=12345;
mode=0;

parent uses:
user=papa, pwd=67890;
mode=1;
with the variable "mode" we could define the permission of the user in diferent ways(modules,curses, or chats).

exmple of code:

if($USER->mode=0){
allow_student();
other functions();
}
else{
echo=get_string("not allowed","document");
other functions();
}

well i hope this idea could help for something.

Average of ratings: -

Re: Roles and Permissions architecture

by Chardelle Busch - Tuesday, 15 August 2006, 2:07 AM

I also have a question about students choosing their role and I'm wondering if this would be the best way to fulfill a need I have:

I have clients who want the capability of allowing students to post in forums under an anonymous "avatar", but with the teacher able to see who is posting (for example when discussing sensitive issues). So, would it be possible with roles to have an "anonymous forum" role where if students choose this role for a forum, then ohter students will see their personal profile info replaced with a non-linked alias student name?

Or, what is there a better way to accomplish this?

Average of ratings: -

Creation of capabilities

by Thomas Giguiere - Saturday, 19 August 2006, 1:26 AM

Hello all. I am very excited about the development of the roles and capabilities architecture as this set of features will be directly applicable to my project at the school district where I work. I am still becoming familiar with the operation of the architecture, so please forgive my questions if they sound uninformed.

Basically, we are needing to create a parent role and enforce access rights to various parts of our moodle-based portal based on that designation. For instance, I have a block that will display different content to students, parents and teachers. Would it be a matter of creating a capability such as "view parent content", allowing that capability for the parent role, and assigning users to the appropriate role? Is there going to be a function for creating capabilities to be assigned to roles?

Thanks for your help.

Average of ratings: -

Re: Creation of capabilities

by Martin Dougiamas - Saturday, 19 August 2006, 12:01 PM

Close.

The capability name should describe the thing (your content in this case) without mentioning roles. eg "viewgradesoverview" or something.

Any module/block etc can create capabilities using an access.php file (you'll start seeing these sprinkled all over moodle in the "db" folders).

Then all you need to do is edit roles and change the permissions for that capability. The parent may have 'allow', while students have it as 'prevent'.

Average of ratings: -

Re: Roles and Permissions architecture

by Vinita Upadhyay - Friday, 9 July 2010, 3:54 PM

Hi Jason,

I need to add someone in a course just to look at the course contents like an observer. I don't want him/her to see students work/post or grades or take part in discussions.

Please advice me on this matter.

Kind Regards

Vinita

Average of ratings: -