LCMS roles and rights brainstorming

From Dokeos

1 General description
2 Version/Due date
3 Analysis
4 Implementation proposal
5 Unresolved issues

General description

Bmollet 10:45, 13 November 2007 (CET): We did some brainstorming here at HoGent about roles and rights in the LCMS. We started from the ideas described on User_roles_and_rights. At this moment nobody in the developer community has plans to implement roles and rights in the LCMS project. Everybody agrees however that we certainly need such a system to handle everything we want (sharing learning objects between users, allowing specific rights in a course,...). This is just a report of our brainstorming session which we want to share.

Version/Due date

Analysis

We think the implementation of a roles and rights library should be flexible enough to allow new applications running on top of the repository to pick in without much changes. Every new application or functionality should be able to use the common roles & rights library and to store its own locations, rights,... in the central storage structure of the roles and rights system. This was also stated as a goal on the page mentioned above. We think however, that we should have specific rights for specific locations. The general "add", "delete", "edit",... rights of which the exact meaning depends on the context don't look flexible enough. For example, a "reuse" right could be defined in the repository allowing a user to say "Users of roleX are allowed to use this learning object as a publication". This "reuse" right isn't usefull in other applications, so it shouldn't be available there.

Locations, Rights, Roles

We should have a single tree with all locations in the platform. The image below gives an example of how this tree could look like. When a new application is added to the system, a new node can be added in the tree with 'Application' as parent node.

In this image, the repository subtree has indivudual learning objects as leafs. So rights can be attached to those locations. In the Weblcms subtree, the image goes to the level of a tool in a course. This means that rights can be attached to that level.

Ideas

Rights should be attached to a location. "RightX is attachted to LocationY" means that RightX is available in the subtree with "LocationY" as root node.
We shouldn't add all locations by default to this tree. If default rights are defined on the level of Weblcms, there's no need to add all elements in the subtree if the roles-rights relations on those sub-locations are the same.
You ask questions to the system like 'Is UserA allowed to RightB on LocationC where root is LocationD'. Then the system looks at LocationC to see if the Roles given to UserA are allowed to RightB. If not, the parent locations of LocationC is examined until we are in LocationD where the algorithm stops.
What will be the size of the table?
- Some numbers of our Dokeos portal:
  - 6.800 courses
  - 503.204 learning objects
  - 21.079 users
- If we go all the way (leafs are learning objects and learning object publications)
  - 21.000 repositories + 500.000 learning objects + ?? categories ~=~ 550.000 nodes
  - 6.800 courses x 15 course tools + ?? categories ~=~ 110.000 nodes
- Many nodes, but with a good tree implementation it can be done we think.

Responses

We shouldn't decouple the repository and the roles and rights system too much, or it will become an empty box. If you leave it up to the Dokeos-application developer to always check whether a certain user has the right to use a certain learning object, this will create loads of problems. Therefore I think every function in the Repository that returns such an object should check for itself whether this user has the right permissions (using one single "haspermissions(user, object)" function. --ThijsBraem 16:49, 13 December 2007 (CET)
- I think this is probably a misunderstanding. Of course the repository will handle roles and rights for objects ... simply because the repository is the only application that can directly access them. But what people do with the publications of those objects and who can or can't do it would be handled by the applications. e.g. all applications in my own LCMS-implementation have an is_allowed function which expects a right, a user and a location. That however doesn't change which objects the user can publish as a list of publishable objects is provided by the repository, which checks the objects's roles and rights to see which objects the user could publish. (this is a simple example for publishing objects, but the basc principle applies everywhere) --HansDeBisschop 10:50, 15 December 2007 (CET)
  - Ok, it was, thank you for the clarification! --ThijsBraem 12:41, 17 December 2007 (CET)
The idea of having a function give the "root" of where the algorithm should stop looking for permissions seems in itself insecure, as it appears to give the possibility to give as root a level where you are sure something is permitted even if on the parent level it is forbidden. --ThijsBraem 16:49, 13 December 2007 (CET)
- I'd have to agree, which is why I'd add an "inherit" setting rather then provide a root, inheriting rights by default is a bad idea to begin with IMO, an "inherit" flag would solve that though. If set to no, there should be no way of circumventing it. --HansDeBisschop 10:52, 15 December 2007 (CET)
  - Ok, I agree on that. --ThijsBraem 12:41, 17 December 2007 (CET)
Comment on the choice of available rights: an "add" seems indeed unnecessary. But I am of the opinion, and willing to be convinced otherwise, that "read", "write" and "reuse" (in the definition as proposed) should always be enough, for every object. Things like "add" for by example a forum topic to a forum, is just a "write" right for that forum, "add" for a message is a "write" for that topic, etc. "write" for a forum message is then just the right to change the message. Re-use should in my opinion always be available, as it can always be of use, if not: then it should be set to true for "world" (or whatever "top" role we have). --ThijsBraem 23:02, 14 December 2007 (CET)
- Available rights and their names depend on the location you're in. In the repository an "add" right indeed seems somewhat superfluous (it's your repository, of course you can add objects to it). But take for example the announcements tool in a course in the weblcms: an "add" right would be essential: whether or not someone can add / publish an announcement or not, the same applies for view, edit and/or delete. --HansDeBisschop 11:00, 15 December 2007 (CET)
  - Also in that example the "add" is not necessary at all: take "announcements of this course" as an object, and adding an announcement is just writing. Delete might indeed be another necessary permission/right though. The idea is that adding "custom" permissions for certain objects will unnecessarily complicate the system and the use thereof. --ThijsBraem 12:41, 17 December 2007 (CET)
Could the choice of also displaying the "application" branch be explained? I was of the idea that every relevant object of the application was already in the repository as well, and that therefore giving rights in the application itself would lead to unnecessary complexities. --ThijsBraem 23:02, 14 December 2007 (CET)
- Even though a user may have a certain right on an object in the repository, that doesn't mean he is able to access any of the object's publications, let alone the courses in which it might be published. A user needn't have any rights on a specific object to view it's publications. An application-location as seen in the tree doesn't really have anything to do with the objects. e.g. Course configuration is a tool within a course withing the weblcms. Whether or not someone can access that configuration-tool would depend on the roles and rights attached to it. --HansDeBisschop 10:35, 15 December 2007 (CET)

Implementation proposal

Roles & Rights are already implemented in the LCMS-based CMS Skorpiuz by HansDeBisschop. It could be used as the basis for an LCMS roles & rights system. Check LCMS Roles and Rights Proposal 1