Show Advanced KnowledgeHide Advanced Knowledge

Consistent Visible and Read Permission Behaviour

1 Description

If we implement this feature we should create a guideline and add it to the dev guide.

1.1 Root Node Behaviour (FS, Jan 2011)

Except the Personal Desktop, all (static) entries of the ILIAS header bar can be hidden from the users theoretically.
Among these four entries are two featuring a "View" and a "Read" permission: "Repository" (with the permission object "ILIAS root node") and "Administration".
By now, the impact of these "View"/"Read" permissions is not consistent with the way they work in other object types (see Mantis Bug #6988) and does not fully offer a facility to hide the respective object.
There should be a consistent and carefully planned solution on this as there are well-conceivable use cases for specific combinations of these permissions:

1. Read but not view "ILIAS root node":
   Hiding the Repository (top level) while still giving access to objects inside the Repository by putting them onto the Personal Desktop of users. This may be used to prevent users from browsing the Repository and to restrict their access to the objects on the Desktop.
   By now, this is spoiled by the fact that you cannot really hide the "Repository" entry in the header bar, and clicking it with lacking permissions will result in navigation errors.
   However, there are also other problems: Besides the header bar, there are some other ways to view or even call the Repository top level:

   • Breadcrumbs:
     This is the biggest issue as there are some open questions and things to be considered:

     • This problem does not only cover "ILIAS root node" but also with any other section of the breadcrumbs (I assume that a solution for this entire problem should be consistent throughout the system).

     • Are sections of the breadcrumbs to be completely hidden in case there is no "View" permission for them (which was the most logical choice) or only become unclickable (which might be easier to achieve)?
       In the first case, the breadcrumbs should only begin with the highest visible level. If an intermediate level was invisible while the ones above and below it aren't, there are two meaningful solutions to avoid "gaps" in the breadcrumbs:

       1. Hide the invisible sections and only display "..." instead.
       2. Let breadcrumbs only begin with the highest visible level all the children of which are also visible, down to the position of the beholder.

   • Message on the empty Personal Desktop

   • Redirect to the Repository top level in case of calling an object without appropriate permissions

   • Repository overviews for selection purposes:
     There are some Repository overviews that at least show the Repository top level:

     • Targets of internal links
     • Desktop items for roles
     • Search area
     Note that the open questions from the "Breadcrums" problem also occur here.

   • "Repository, Trash and Permissions":
     I'm not sure whether this is also affected by permissions for "ILIAS root node".

2. Read but not view "Administration":
   Hiding the Administration (top level) while still giving access to specific positions of the administration area (e.g., by means of the new goto link for the user administration (see Go to User Administration) and possible comparable goto links in the future.

1.2 General Behaviour (JF, 10 Jun 2013)

The visible permission only controls:

• The presentation of the object in the repository, search and breadcrumb.

Access to the info page should be granted, if visible or read or join permission is given.
 
Breadcrumbs

• We prefer the alternative that limites the breadcrumbs to all visible parents recursively from the current position (stopping at the first invisible node).

Repository Tree Behaviour (left hand navigation, internal link target selector, copy/move target selector, ...)

• The "root" node of the repository tree is determined like the first visible node of the breadcrumbs.
• Nodes that are not visible are not presented, including their subtree.
• A drop-down is presented on top of the tree (ajax mode to prevent permission checks), that lists all selected items/memberships and a "Open" button. If selted and clicked the context of the tree is changed, the path to the node is opened and the node is highlighted. (internal link selector and copy/move selector). We think the left-hand repository tree does not need this drop-down, since navigation is possible through the personal desktop. Related feature request: Copy or Link Objects: Repository and My Memberships.
• We need a administration setting, that disables the left-hand repository tree completely.

Main Menu Entry

• The top repository node will not be listed, if visible is not given.

Redirect in case of missing permission

• The redirect should be done to a separate Error and No Permission Screen.

LP Collections

• Items of LP collections will always be presented to the user, even if visible permission is not given. Otherwise the behaviour would not be comprehensible for the user.

Open Issues

• If users remove personal desktop items that linked to visible subtrees that are not accessible through the repository navigation, the only way to get them back is the search feature or contacting an administrator.

Related Bugs:

• 11146: Umfragen können nur mit den Berechtigungen "Anzeigen" und "Lesezugriff" durchgeführt werden.
• 11169: LP shows objects regardless of permissions.

2 Status

• 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: suittenpointner (at) qualitus.de

4 Discussion

JF 10 Jun 2013: We would like to improve this behaviour with ILIAS 4.5 and are looking for funding.

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