Permission to link object

1 Description

1.1 Original Request (2010/13)

Up to now, the permission to link an object is assigned to the permission for deleting an object (see also forum). The reason for this is that a linked object gets into a new permission setting where the owner but also a local administrator have all or almost all (owner) permissions. This includes to delete the entire content of the object (which is also possible with the EDIT permission) - but not to delete the "original" object.

There are two solutions to solve the problem:

1. Adding a new LINK permission

This solution would increase the evidence of the permission but decrease performance due to additional permission queries.

2. Linking controlled by EDIT permission

This option has less evidence but also less performance problems.

1.2 Updated Request (2014)

The following changes of the current linking concept shall be introduced to improve and to extend the options of linking existing repository objects and re-use them in ILIAS:

1. Introduction of a new permission "Link" which allows only to link the selected object. The operation of linking is no longer part of the "Delete" permission. Roles that had the "Delete" permission before this separation get both "Delete" and "Link" permissions through DB update. This change allows to give a role the permission to link an object but to prevent that users with this role may also delete this object.
2. "Link settings" are introduced in the Permissions tab (new submenue) . They allow to configure which permissions are given to any new created reference by linking the current object. This change offer the possibility to restrict the permissions of a new object to a defined set - independent from the permission policy that exists at the node where the linked object is inserted. The intersection method is used to define the permission settings of each role in the current context.
   1. Example 1: Course admin role would have all permissions for a SCORM module at this node but the linked SCORM object comes only with "Visible, Read and Delete". Due to the intersection method, the course admin would get only "Visible, Read and Delete".
   2. Example 2: In the same context the course member role has permissions "Visible and Read" for SCORM modules and linked SCORM object comes with "Visible, Read and Delete", so the course member get "Visible and Read" (but not Delete).
3. The permission restrictions have no impact on users with global role "Administrator". They have all permissions anyway and are able to change the defined permission settings or even stop the restriction of permissions.
4. Global templates for predefined permissions for each linkable object type can be edited in the role administration.

2 Status

• Scheduled for: not scheduled yet (has been scheduled for v. 4.3 but postponed due to missing funding)
• Funding: Required
• Development: Feature is to be developed by tbd

3 Additional Information

• If you want to know more about this feature, its implementation or funding, please contact: Matthias Kunkel

4 Discussion

Florian Suittenpointner, 14-12-2010:
I'd like to add one more aspect (besides evidence and performance), that is, practical relevance in the work of trainers and/or authors.
Linking objects becomes especially important when authoring is a separate area of work in an organzation, i.e., content is produced centrally (maybe even by specialists only) and then only linked to the positions where it's used for learning/teaching. When you want to organize this in practice, the problem is that the distribution of the content should at best be done in a "PULL" system, i.e., the trainers take the content when they need it (and link in into their courses). Up to now, however, for that purpose you need to give to them the delete permission which is a problem because this way they can delete the original content object.
This problem would IMHO not really become better with solution 2 (linking allowed for users with edit permission) because then those who link the content can "spoil" the original content object.

Matthias Kunkel, 14 Dec '10: Hello Florian, thank you for this posting. To hit the nail on the head, you prefer a dedicated LINK permission, am I right?

Florian SUittenpointner, 11-01-2011:
That's right. Do you agree in the importance of the scenario I described?

Matthias Kunkel, 04 FEB 2011:

• Introducing a new permission for linking objects seems to be the better solution. We should go this way.
• How we are handling the move action which is also assigned to the delete permission now?
  1. Do we keep it together with the delete action (because it removes this object from the current place)?
  2. Shall we introduce a proper permission for moving objects, too?
  3. Do we assign it to the new linking permission (because it allows to use this object at another place in the repository)?

JF 14 Mar 2011: We see a risk that a "link" permission could be granted by users without understanding the implications (putting the object into another rbac context with possible edit permissions). What we need is a new link operation that allows people to add references in their contexts but without the possibility to change the content or to gain edit permission. This needs further conceptual discussion. We postpone this to 4.3.

Caspar Noetzli / Werner Willi 18. Jan 2012:
At PH Zürich we have developed a collection of over 80 learning objects (Learning Modules ILIAS). These modules are accessible by all faculty and students. To make the access easier a growing number of lecturers would like to add a link to a specific learning object (Learning Module) from within their Course or Group. If we use the Link-option (Verknüpfung) from the Actions-menu the problem is, that now all the adminitrators from the Course or Group could edit and change the Learning Module. By doing so, they change all the other instances of the Learning Module as well. We need an option to prevent this. It should be possible to link Learning Modules (and other ILIAS-items) in a "read only mode". As JF mentioned above it's imperative to develop " a new link operation that allows people to add references in their contexts but without the possibility to change the content".

Matthias Kunkel, 27 May 2014: Request has been discussed with Stefan Meyer and Uwe Kohnle to improve the current linking concept. Major aim is to prevent that users get additional permission through linking of an object and are able to modify the linked object or even to delete the original one. We would like to have this modification with 4.6 if funding is available.

Matthias Kunkel, 02 Jun 2014: There has already been made a similar request "right to link without right to delete" and added to the Jour Fixe Agenda at March 31, 2014. Therefore, this feature could even make it into 4.5 if funding is available.

Matthias Kunkel, Stefan Meyer, Alexander Killing, 13 June 2014: Currently if an object is linked multiple times within the repository object, all links are handled in the same way. There is no disctinction between a "master" and "non-master" links. The concept above now would need to identify the master and to allow it to introduce the "white list" of possible permissions.
 
A clear technical concept how this should be solved (and existing data should be migrated) needs to be added to this page before this feature can be scheduled for a major release.

Zenzen, Enrico [ezenzen], 18 AUG 2022: This request no longer fulfills the requirements of the Feature Wiki. In consultation with the maintainer I change the status of the feature request to "Redundant / outdated". If the request is still relevant, please update template and mockups.

5 Follow-up