Feature Wiki

Information about planned and released features

Tabs

Unbundling of Admin Permissions

Page Overview

[Hide]

1 Initial Problem

The permission settings in the administration can easily lead to misconfiguration if roles should only use parts of the administration.

Current Situation

  • A clickable entry in the administration menu (admin node) requires an RBAC node as a child of the system folder. The READ and WRITE permissions must be defined for the admin node.
  • For the general visibility of the administration menu, the system folder is tested for VISIBLE:
    \ILIAS\GlobalScreen\Helper\BasicAccessCheckClosures::hasAdministrationAccess
  • For an admin node to appear in the menu, a user must have both VISIBLE and READ on it:
    \ILIAS\Administration\AdministrationMainBarProvider::getStaticSubItems
  • The GUI of an admin node corresponds to the GUI of its RBAC object. It is called via ilAdministrationGUI as the base class. ilAdministrartionGUI checks whether the user has VISIBLE or READ for the system folder.
  • All other permissions relating to an admin node must be checked in its own GUI. To do this, ilRbacSystem must be used instead of ilAccess, otherwise the READ on the path would also be tested when checking for READ, which does not have to be the case for the system folder.

Relevant Jour Fix decisions

Administration nodes must offer a read permission and a read-only view should be implemented (e.g. forms should not display save buttons). Visible permissions should be abandonded from administration nodes.

https://docu.ilias.de/go/wiki/wpage_3452_1357, chap. 2.

The ilAdministrationGUI should allow the access for users with only read access (not visible) to open those links. Currently it does not allow this by checking for visible rights in the execute command.

[…]

JourFixe, ILIAS [jourfixe], August 28, 2017: We highly appreciate the suggestion to have an easy access to the Kitchen Sink documentation. We schedule this feature for 5.3. We only raise an error in the executeCommand function if neither visible nor read permission is given.

https://docu.ilias.de/go/wiki/wpage_4681_1357

We will implement the concept of Positions in Orgunits for the User Managment see Support of Positions in Courses, Groups and Exercises

Users with the RBAC Permissions "visible" and "read" and the Position Permission "Edit User Accounts" are allowed to:

  • Edit/Manage user account of "their" OrgUnits. Other User Accounts will be filtered
  • The Export of user accounts is filtered
  • The "Letter Filter" wil be filtered

The following features will be resticted or disabled:

  • It is not possible to change any role assignments
  • The "Advanced User Search" will be disabled.
  • Adding User Accounts or Importing User Accounts will be disabled
  • The "User List" for the "Multi-Actions" "All Objects" are restricted to the user account which are allowed to be mangaged by OrgUnit-Permissions.

[…]

Meyer, Stefan [smeyer] @Richard please have a look on the permission screen in "Administration -> User Managment". The following permissions are currently available (used for user managment):

  • Visible, Read: Shows the administration node
  • Read Access to User Accounts: only if this permission is granted ALL global users are shown. Should not be given to OrgUnit-Users
  • Edit Role Assignment: Allow the change global role assignments. Should not be given to OrgUnit-Users
  • Create User: Allows to create (import) user accounts. Should not be given to OrgUnit-Users

We highly appreciate this suggestion and schedule the feature for 6.0. We would like to clarify that this feature request does not include support of positions in the local administration.

https://docu.ilias.de/go/wiki/wpage_5905_1357

The JourFixe decision from 2015 was never fully implemented. The READ and VISIBLE permissions can be set for all admin nodes and are tested for an entry in the menu.

Problems

The system folder is also the admin node for “General settings”. Its permissions are used for different purposes:

  • VISIBLE displays the administration menu
  • VISIBLE or READ allows the GUIs of admin nodes to be called up
  • VISIBLE and READ displays “General settings” in the menu

This combination is confusing. To give users access to other admin nodes, VISIBLE must be set under “General settings”. READ is additionally required for the general settings.

In the admin node "ILIAS accounts", the READ permission of the admin node causes all accounts to be displayed. However, it must also be set for the node to appear in the menu. Then, however, no restricted view of the accounts of your own organizational unit can be given.

2 Conceptual Summary

Option 1

  • The system folder gets a new “Show Admin Menu” permission. It is copied from the VISIBLE permission during the ILIAS update. This permission is used to display the administration menu. The VISIBLE permission then only refers to the system node itself. The title of the system nodes page is is changed from "Administration" to “General settings” (same as its menu entry).
  • To enter the GUI of an admin node in the admin menu, the VISIBLE permission of the admin node is sufficient.
  • When the GUI of an admin node is called up, the permissions of the system folder are no longer checked. The GUI must check the permissions of its own node. Generally, it will require READ permission for all commands. In the case of user accounts, the accounts displayed are filtered more finely according to READ for all accounts and or by organizational unit for selected accounts.

If the GUIs of admin nodes have previously relied on the checked VISIBLE of the system node for display, they must now check the permissions of their own node. They should do this anyway to distinct between READ and WRITE.

1: New Page Title (instead of "Administration); 2: New Permission Setting

Option 2

The SystemFolder component and its RBAC node 'adm' combine several functions:

  • Parent container for all RBAC nodes of administration entries, but without being used for the permission check via ilAccess
  • General settings (basic settings, installation header, contact information)
  • Server settings (installation status, server info, Java server)
  • Tab for cron jobs (with jump to the GUI in the cron component)
  • Benchmarks

The general settings, server settings, cron jobs and benchmarks can be separated into their own components with separate authorities. They will get their own RBAC nodes as childs of the system folder.

The system folder then only has the function of being the parent of all admin nodes.

  • The VISIBLE permission of the system folder is checked to display the administration menu.
  • To enter the GUI of an admin node in the admin menu, the VISIBLE permission of the admin node is sufficient.
  • In the GUIs of the admin nodes, the permissions are checked via ilAccess. This means that the READ permission of the system folder is a prerequisite for the READ permission of the admin node.

The system folder has its own “Administration Area” entry in the Admin menu, in which only these permissons can be set.

1: New node and page for administration area (permissions only); 2: Separate nodes for the former general settings tabs

Alternatively the system folder can be put on the top level of the menu and it may offer an overview of the permissions given to admin nodes:

Based on the feedback in the JF, a feature workshop on Aug, 7, 2025 led to the following solution, in short:

  • Permissions of the system folder don't count anymore - all admin nodes have independent permissions.
  • The "Read" permission of a node is needed for its menu entry and for its GUI.
  • The former "Visible" permission will be removed from all admin nodes.

This will get the menu entry and access to admin nodes consistent. Special global roles are longer needed to give partial access to the administration - this can be done with local roles in the admin nodes.

2.1 Separate the System Folder Functions

The current tabs of the system folder GUI will get their own RBAC nodes in the system folder. They will have separate entries in the administration menu below "System Settings and Maintenance", all with their own permissions tab:

  • General Settings
  • Server
  • Cron Jobs
  • Benchmarks

The entry of the system folder in the administration menu (which is currently named "General Settings") will be deleted. This means also, that the permissions tab for the system folder is no longer available.

2.2 Revise Permissions

2.2.1 Permissons of the System Folder

Permission settings of the system folder will not be needed to display or access anything in the administration. A check for "read" on the system folder will always return true for all roles. The GUIs of administration nodes can use ilAccess to check their permissions.

2.2.2 Permissions of the Admin Nodes

  • "Read": is needed to show the node in the admin menu and to call its GUI.
  • "Edit Settings": is needed to change administration settings handled by this node.
  • "Change Permissions": is needed to show the "Permissions" tab of this node and to change permissions there.

The items of the administration menu (e.g. "System Settings and Maintenance") will be dynamically filled with all of their assigned administration nodes that have "Read" access. Each node that is shown in the menu  will at least offer a read view of its content or settings.

The main bar entry "Administration" will be shown if the menu has at least one administration node. To decide this performantly, a dedicated function will do a direct database query checking if the user has a role with "Read" access to at least one direct child of the system folder.

Some admin nodes have settings and content like sub items, e.g. users or languages.  With switching to the "Read" permission for access to an admin nodes GUI we would like to introduce the following pattern: 

"Read" permission is used to open the GUI of an admin node and to show its settings (may be write protected). It may also be used to show the content in the node. If it is necessary to separate these permissions, a new permission 'read <content that can be read>' MUST be introduced. The new permission MUST be completely independent from any preexisting permissions. All roles having the read permission at the moment of the introduction MUST be assigned to both permissions afterwards. 

In the case of the UserFolder, a new permission "Read all accounts" will be introduced. This permission will list all user accounts regardless of the organisational unit.

2.2.3 Kitchen Sink Documentation

The sub tab "Documentation" of "System styles" offers permanent links to the pages of the kitchen sink documentation. There are uses cases for the docu installation to give these links to other users for discussion on ui concepts. This is treated in a separate feature request More Visibility for Kitchen Sink

2.3 Database Update on Permissions

The "Read", "Edit Settings" and "Change Permissons" permissions of the system folder are copied to the "Read" and "Edit Settings" permissions of the new nodes for genereal settings, server, cron jobs and benchmarks. Then all permissions except "Read" will be dropped from the system folder.

All admin nodes currently have the permission "Visible", "Read" and "Change Permissions". The "Visible" permission is dropped from all direct childs of the system folder. 

The user folder wil get a new permission "Read all accounts". This is initialized for all roles with the value of hte "Read" permission. The value of the "Read" permission is overwritten with the value of the "Visible" permission. Then the "Visible" permission is dropped from the user folder.

3 User Interface Modifications

3.1 List of affected Views

  • Administration / System Settings and Maintenance (Slate): Separate Nodes for "General Settings", "Server", "Cron Jobs" and "Benchmarks" (three new icons needed)
  • Administration / System Settings and Maintenance / General Settings: New page with tabs "General Settings" and "Permissions"
  • Administration / System Settings and Maintenance / Servers: New page with tabs "Server" and "Permissions"
  • Administration / System Settings and Maintenance / Cron Jobs: New page with tabs  "Cron Jobs" and "Permissions"
  • Administration / System Settings and Maintenance / Benchmarks: New page with tabs  "Benchmarks" and "Permissions"

3.2 User Interface Details

3.3 New User Interface Concepts

No new UI concepts.

3.4 Accessibility Implications

The use of existing UI components does not introduce any new implications for accessibility.

4 Additional Information

4.1 Involved Authorities

For Administration:

For User Service:

If this request is related to multiple components, please list both authorities for all related components.

4.2 Technical Aspects

The GUIs of administration nodes have to check the READ permission of their admin node in order to display anything. If they are called with ilAdministrationGUI as baseClass, this will already be done there. If they are called with a different base class, they have to check this on their own.

4.3 Privacy

No new personal data is collected or processed as a result of the implementation of the feature. 

4.4 Security

All GUIs of administration nodes must be checked if they are either only accessible via ilAdministrationGUI or if they check the READ permission of ther admin node on their own.

4.5 Contact

Person to be contacted in case of questions about the feature or for funding offers:   Neumann, Fred [fneumann]

4.6 Funding

Funding status and funding parties are listed in the block 'Status of Feature' in the right column of this page.

If you are interested to give funding for this feature, please get into contact with the person mentioned above as 'Contact'.

5 Discussion

Kunkel, Matthias [mkunkel], 30 JUL 2025:  Thank you for this important initiative to make the ILIAS administration simpler and more consistent in its use. If we can manage this for ILIAS 12, I will be very happy.

One question: In 2.2 there is written: ‘To enter the GUI of an admin node in the admin menu, its VISIBLE permission is sufficient.’ What is meant with ‘its'? Is the VISIBLE permission of the system folder needed? Or does it need VISIBLE for each admin node? According to the JF decision from 2015 there should no longer be VISIBLE permissions for admin nodes.

Neumann, Fred [fneumann], 21 JUL 2025:

Thanks for the note. I made the proposal clearer. The VISIBLE permission of the system folder should in both options no longer be necessary to enter the GUI of an admin node.

The JF decision from 2015 contradicts with the JF decisions from 2017 and 2019. Both need the READ permision of the admin node.

  1. The READ permission of the style component is used to open the documentation without navigation through the admin menu.
  2. The READ permission of user component is used to distinct between full access to all users or restricted access to those of the orgunit. 

With acceptance of this FR, we should come to a consistent rule that works for all admin nodes in the same way. Admin nodes do not have an info page that can be shown without read access. Therefore we can check the same permission to add a node to the menu and to call its GUI. I took the VISIBLE permission to keep the READ permission free for component specific cases like those above.

We can use the READ permission of the admin node instead for both display in the menu and GUI access, following the decision from 2015. This would especially help in option 2 when ilAccess is used in the components. Then we can savely control access to any administration node with the READ permission of the system folder. But then we have to find solutions for the special cases:

  1. The style component should provide a path to documentation without READ access of its admin node.
  2. The user component needs a separate, new permission to allow access to all users.

JourFixe, ILIAS [jourfixe], 04 AUG 2025: We highly appreciate this suggestion and would like to solve the mentioned problems above. We all have a preference for the described option 2. But we had a longer discussion in the JF about the impact of the suggested changes and would like to continue this discussion in a dedicated feature workshop. This will give us more time for discussing and modelling this feature.

Open questions to discuss are:

  • how we handle the above mentioned workarounds?
  • do we still need the VISIBLE permission for single administration nodes (as well as for the parent administration node)?
  • who will check the permissions for a selected administration node?

We schedule a workshop for Thursday, 07 August, 16:00: Link to workshop

Kunkel, Matthias [mkunkel], 05 AUG 2025: With regard to yesterday's discussion at the Jour Fixe, I would like to outline why I am convinced that we do not need ‘visible’ permission within the administration of ILIAS:

Purpose of the RBAC permission ‘visible’ is to show repository objects in their parent container – whether in list view or tile view – and to give access to the ‘Info’ page (if it exists). That's it. Nothing more. The permission makes an object visible. A user can see that it exists. But ‘visible’ does not allow a user to ‘get into the object’ and read its content. That's the business of the ‘read’ permission. 

‘Read’ permission allows a user to see the content of an object, e.g. the pages and chapters of a learning module, to take a test or to download a file. The ‘read’ permission does also allow a user to read the content of a learning module even if this user does not have the ‘visible’ permission for this object. This is because ‘visible’ is no pre-requisite to read or see the content of an object. The user only needs to get a permanent link to the object to get access to it if ‘read’ is granted.

Most repository object types offer both ‘visible’ and ‘read’ permission. Only a few object types behave differently. All link object types (e.g. course link or group link) only have ‘visible’ but no ‘read’ permission. ‘Visible’ is needed to show the link object in the parent container. But clicking on the link and getting access to the linked object (course, group, category or study programme) is controlled by the ‘read’ or ‘join’ permission of the linked object (e.g. the course in case of a course link). 

The poll object behaves the other way round. This object type has ‘read’ but no ‘visible’ permission (at least until ILIAS 11) because there is no need for ‘visible’. The content of the poll (question and voting option) is already presented in its (parent) container. A user sees the poll and its content when ‘read’ permission is given. There is no entry in the object list on which a user has to click to get to the poll and vote there.  

If we now look to the administration area of ILIAS we see a top administration node and a lot of sub-nodes. Each of these sub-nodes has an own permission handling. But unlike the normal repository the administration has no parent container pages for the single administration nodes. Navigating to an administration node is done via the administration menu in the slate.

Brief excursus: As already stated in this feature request: there is not even a real top administration node yet. The administration node for System Settings is the entry point for all users – which should be changed with option 2 in the above described concept.

Back to the track: ‘Read‘ permission for an administration node should allow to see the ‘content’ of this administration node, e.g. existing roles in the role administration, existing documents in the user agreements administration or search settings in the search administration. The presented information in these administration nodes should be readable with ‘read’ permission but not be editable. Changing, adding and deleting settings requires ‘Edit Settings’ (there is a dedicated test case to check this behaviour).

Now what could be the purpose of a ‘visible’ permission in the administration? According to the use of ‘visible’ for normal repository objects it would allow users to see that there is an administration node (but don't give access to it because this requires ‘read’). That's it.

But is there a need for this? Does this support any known use case? What would be the benefit of seeing administration nodes for which I have no access to? What's that supposed to achieve?

IMHO there is no need of a ‘visible’ permission for administration nodes. An administration node appears in the administration menu when I have ‘read’ permission for this node. And the related entry in the administration menu (bulky button) is always clickable. Having ‘read’ permission allows me to see all information in this administration node. With additional ‘Edit Settings’ permission I also can edit the information (and ‘Change Permissions’ allows me to change the permission settings for this node). That is everything we need. The ‘visible’ permission is superfluous within the administration.

JourFixe, ILIAS [jourfixe], 18 AUG 2025: Thanks for updating the feature request according to the results of the RBAC workshop. We highly appreciate this suggestion and accept the FR for trunk.

6 Implementation

Feature has been implemented by {Please add related profile link of this person}

6.1 Description and Screenshots

{ Description of the final implementation and screenshots if possible. }

6.2 Test Cases

Test cases completed at {date} by {user}

  • {Test case number linked to Testrail} : {test case title}

6.3 Privacy

Information in privacy.md of component: updated at {date} by {user} | no change required

6.4 Approval

Approved at {date} by {user}.

Last edited: 18. Aug 2025, 13:44, Kunkel, Matthias [mkunkel]