There is some speculative talk about changing how roles are combined for Moodle 2.0 (Development:Role overrides revisited). I am worried about this, because there is not point simplifying things if, in the process, they no longer work. After all, 7 hard-coded roles was a very simple system, and we had to change that because it was insufficient. I accept that, if anything, the current system tends towards the other extreme, of being too flexible at the expense of being too complex.
Anway, in the process of trying to understand why the current system is the way it is, I wanted to see what was originally proposed. Amazingly, sam was able to put his hands on it even though it is 2.5 years old. He said it was OK if I posted it publicly, so here it is. (Sorry for the inconvenience, but I had to Zip it to make it fit in 100kB.)
It is interesting to see the differences between what was originally asked for and what got implemented.
I was a bit disappointed that this is only a design document. I don't think there was ever a clear statement of requirements. So the closest thing we have are probably the examples from the end of the document. They provide some motivation for the design.
I also made a half-hearted attempt to start reverse-engineering the requirements on Development:Roles use cases. I guess I should add the original examples. Also, it occurred to me that some of Helen's Useful things a teacher can do with roles would also be worth looking though. Anyway, if anyone any thoughts about what we actually require from the roles system, please feel free to edit that use cases page.
I was also rather amuse to see that some of the great innovations I have introduced for Moodle 2.0 are actually very like things that were in the original specification, but then forgotten about.
A historical curiosity, the original design document for Roles
Tim Hunt írta időpontban
Válaszok szám: 1
Válasz erre: Tim Hunt
Re: A historical curiosity, the original design document for Roles
David Bogner írta időpontban
Hello Tim,
I am quite satisfied with the roles model. Improvement of the usability of the roles could be done, but that's more an issue of design and structure how to assign and manage roles. (assign roles with ajax would be less time consuming)
There is also a problem with the roles hierarchy between the guest role und the authenticated user role.
Generally the guest has more capabilities than the authenticated user, whereas the authenticated user is the user who I trust more than a guest and should have more rights than the guest (A guest just does not have to login and I can configure my moodle installation that only trusted users can login)
So why place the guest user in the capabilities hierarchy over the authenticated user?
That's the theory, but in real life this has following consequence (example)
I want that a database with Moodle ressources can be updated by everyone who is logged in, but not by guests who are not logged in.
If I override just the authenticated user role for the database, to be allowed to add an entry, the user can't do it, because he is considered as a guest. So I have to change the guest role too and allow a guest to add an entry. So a guest not logged in sees the "Add entry" tab but too, which is not wanted. (And the guest can't add an entry even if set to allow, that's good, but confusing). Only if the guest is authenticated user and guest he can add an entry.
This is inconsistant.
My proposition:
Abolish the Authenticated user role and replace it with authenticated guest role (an authenticated user is automatically guest + authenticated). That would make more sense than the actual roles definition.
What do you think about this inconsistancy and the solution? You can find the described problem under following link http://www.edumoodle.at/edulab/mod/data/view.php?id=6451
You will see that you are allowed to add an entry as guest, but can't add an entry. Only auth. users can do that. So the role model has to be revised for those two roles.
Yours
David
I am quite satisfied with the roles model. Improvement of the usability of the roles could be done, but that's more an issue of design and structure how to assign and manage roles. (assign roles with ajax would be less time consuming)
There is also a problem with the roles hierarchy between the guest role und the authenticated user role.
Generally the guest has more capabilities than the authenticated user, whereas the authenticated user is the user who I trust more than a guest and should have more rights than the guest (A guest just does not have to login and I can configure my moodle installation that only trusted users can login)
So why place the guest user in the capabilities hierarchy over the authenticated user?
That's the theory, but in real life this has following consequence (example)
I want that a database with Moodle ressources can be updated by everyone who is logged in, but not by guests who are not logged in.
If I override just the authenticated user role for the database, to be allowed to add an entry, the user can't do it, because he is considered as a guest. So I have to change the guest role too and allow a guest to add an entry. So a guest not logged in sees the "Add entry" tab but too, which is not wanted. (And the guest can't add an entry even if set to allow, that's good, but confusing). Only if the guest is authenticated user and guest he can add an entry.
This is inconsistant.
My proposition:
Abolish the Authenticated user role and replace it with authenticated guest role (an authenticated user is automatically guest + authenticated). That would make more sense than the actual roles definition.
| Rollen | Beschreibung | Änderungen |
|---|---|---|
| Administrator | Administrators can usually do anything on the site, in all courses. | 0 |
| Course creator | Course creators can create new courses and teach in them. | 0 |
| Teacher | Teachers can do anything within a course, including changing the activities and grading students. | 0 |
| Non-editing teacher | Non-editing teachers can teach in courses and grade students, but may not alter activities. | 0 |
| Student | Students generally have less privileges within a course. | 0 |
| Authenticated guest | All logged in users. They are generally considered as guests, but are allowed to enter text in some cases. |
0 |
| Guest | Guests have minimal privileges and usually can not enter text anywhere. | 0 |
What do you think about this inconsistancy and the solution? You can find the described problem under following link http://www.edumoodle.at/edulab/mod/data/view.php?id=6451
You will see that you are allowed to add an entry as guest, but can't add an entry. Only auth. users can do that. So the role model has to be revised for those two roles.
Yours
David