Enable Positions (only) in certain categories

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

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

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

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}

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}.