TAC: Role Based Access Control to Export Creation for Tests

1 Initial Problem

Currently, it is only possible to allow TAC to be used by everyone with write access to the test object or block the plugin entirely (system administrators keep access always). This configuration does not suit all organizational structures, where some subgroups of users should have access to the creation of TAC exports, while average users, i.e. teachers running the exams, who might already feel overwhelmed with ILIAS’s core functions, should have limited access.

2 Conceptual Summary

Instead of generally allowing all users with write access to the test object to create exports, admins need to be able to define the global/self-defined roles which should be granted access. Write access has still to be present for a user to access the export tab and thus the export functionality of the test object. The TAC plugin must only disable the export feature for users accessing the export tab IF they are not assigned to at lease one (1) of the global/self-defined roles selected in the plugin configuration. (To clarify: Local roles like groupmember or courseadmin are not to be used to define the users which should be granted access, only global roles or self-defined roles are meant to be used to define which should be granted access.)

This possibilty and the rights to access certain categories/courses will allow to narrow down the group of users in a suitable way.

3 User Interface Modifications

3.1 List of Affected Views

• Test: Export
• Admin: Plugins: TestArchiveCreator: Configuration

3.2 User Interface Details

3.3 New User Interface Concepts

• No new interface concepts.

3.4 Accessibility Implications

• No accessibility implications.

4 Technical Information

{ The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues. }

5 Privacy

{ Please list all personal data that will need to be stored or processed to implement this feature. For each date give a short explanation why it is necessary to use that date. }

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

7 Contact

• Author of the Request: Sesterhenn, Fabian [sesterhenn]
  
• Maintainer: {Please add your name before applying for an initial workshop or a Jour Fixe meeting.}
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

8 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• …

9 Discussion

10 Implementation

{ The maintainer has to give a description of the final implementation and add screenshots if possible. }

Test Cases

Test cases completed at {date} by {user}

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

Privacy

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

Approval

Approved at {date} by {user}.