Feature Wiki
Tabs
Enable Positions (only) in certain categories
Page Overview
[Hide]- 1 Initial Problem
- 2 Conceptual Summary
- 3 User Interface Modifications
- 4 Additional Information
- 4.1 Involved Authorities
- 4.2 Technical Aspects
- 4.3 Privacy
- 4.4 Security
- 4.5 Contact
- 4.6 Funding
- 5 Discussion
- 6 Implementation
- 6.1 Description and Screenshots
- 6.2 Test Cases
- 6.3 Privacy
- 6.4 Approval
1 Initial Problem
We have noticed that superiors get a complete list of all the courses their employees are participating. This is a problem from a data protection point of view and should be controllable or manageable in some way.
Example: If an employee is in a course/module such as ‘Quit on time’, this is not relevant for superiors as this is not a training. Superiors should only be able to view the courses / groups /... approved for them.
So far, we have not found a way to control this view in any way. We would like to request if it would be possible to create an option where the top-level object ID can be specified (in our case the ID for all our training courses). Only these should then be listed recursively. Alternatively, a course /group /... setting would also be useful.
2 Conceptual Summary
We suggest extending the settings by adding a scope (e.g. category) for the use of positions in object types (e.g. courses, groups, exercises) in which the permissions of the positions are valid. In other words: It should be possible to define an object (Ref-ID) and all configured object types inside this object will get the permissions of the positions.
3 User Interface Modifications
3.1 List of Affected Views
- Administration > Organisational Units > Settings
3.2 User Interface Details


3.3 New User Interface Concepts
No new UI Concepts are needed.
3.4 Accessibility Implications
{ If the proposal contains potential accessibility issues that are neither covered by existing UI components nor clarified by guidelines, please list them here. For every potential issue please either propose a solution or write down a short risk assessment about potential fallout if there would be no solution for the issue. }
4 Additional Information
4.1 Involved Authorities
- Authority to Sign off on Conceptual Changes: Klees, Richard [rklees]
- Authority to Sign off Code Changes: Klees, Richard [rklees], Schmid, Fabian [fschmid]
If this request is related to multiple components, please list both authorities for all related components.
4.2 Technical Aspects
{ Necessary technical information have to be provided here, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues. }
4.3 Privacy
{ Personal data that will need to be stored or processed to implement this feature have to be listed here. For each date give a short explanation why it is necessary to use that date. }
4.4 Security
{ Does the feature include any special security relevant changes, e.g. the introducion of new endpoints or other new possible attack vectors. If yes, please explain these implications and include a commitment to deliver a written security concept as part of the feature development. This concept will need an additional approvement by the JourFixe. }
4.5 Contact
Person to be contacted in case of questions about the feature or for funding offers: Lorenz, Katharina [klorenz]
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
Klees, Richard [rklees], 2025-04-07:
Hello Katharina,
if I understand this correctly, I do not think that this is a good way to solve the issue at hand. Let me try to rephrase (and check...)
* There is a list of courses for each employee that her superior can view. That list can be reached via Main Bar > Organisation > Course Memberships. (right?)
* That list shows all courses where the employee is a member. That list just shows all courses where the employee is a member. No further questions asked... (right?)
* This is a problem, at least regarding privacy. Which I understand =)
If this is correct, I wonder why we would need that new setting and also, why it would be located in the org-units. We have separated Org-Units from the Staff features some time ago, and from my point of view, this would be something for the Staff feature. Also, I think there already is a way to express the thing you want: If position permissions are used, there is a permission called "View Course Memberships" and a permission called "View learning progress of other users" which should be enough to express the thing you want. Is it correct, that the view "Course Memberships" simply does not respect these positions?
Kind regards!
Lorenz, Katharina [klorenz], 2025-04-10:
Hello Richard
Thanks for your comment, your points are all correct.
And yes, it is also correct, that there is the possibility to configure this via the “View Course Memberships” permission.
What we do not like about this implementation is that this has to be set individually for each course (in future and also for existing ones). This can take an enormous effort of time. We would therefore regard it as an improvement if this could be regulated for entire categories.
Kind regards back!
Klees, Richard [rklees], 2025-05-21:
Hi Katharina,
I have discussed this issue with Florian. We indeed have similar problems, where people want to set or unset position based permissions for a batch of courses. During the discussion we then found, that local roles and local policies seem to solve a very similar problem. We considered this option over the idea that you propose here and found, that it seems to be a little better because it preserves some locality, as the setting can be made in the location I want it to be applied (or at least, near that location...). We think that a similar approach would be possible for position based permissions as well.
There's one huge argument against that approach, though: The position based permission system already is complex and hard to understand. The same goes for the local roles and policies. Besides the technical issues that arise in implementation of the approaches, we think that it is imperative for access control, that people understand what they have actually configured and how changes will influence access of users. We feel that a solution that mixes two approaches that are already complicated in their own right, would fail this requirement.
We therefore want to propose to tackle what seems to be the initial requirement: "set permissions for a batch of courses". What'd you think about a solution that would allow for the batch processing of permission changes? We could e.g. think of a GUI that allows to say something like "for all objects of {TYPE} located {HERE AND THERE}, set position permissions X for position A, remove position permission Y for position B, ...", maybe in the form of some wizard that allows to check the different steps.
This seems to be closest to what the people actually want to do and won't add another burden for understanding the consequences of this or that action.
Kind regards!
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: 21. May 2025, 11:37, Klees, Richard [rklees]