Automated adding of users to exercises

1 Initial Problem

Users in courses are not automatically informed about new exercises created within a course through their tasks because users are not automatically added to new exercises.

For Students this is negative because they must be manually added by lecturers or join/participate the exercise themselves to be informed about new assignments through their tasks.
Further, for lecturers this is negative because they must manually add students.

2 Conceptual Summary

There are two possible options to this issue.

Variante 1: Role specific

There is a related FR Add Users to Exercise using course roles

Here, the Author of the Request suggests to add a role-specific adding function for exercises, this corelates with the suggestions of this FR if the automated adding of users to exercises would be implemented with incorporating role specific allocations

Users with a specific role within a course should be added automatically to new exercises. This automated process should also work for users who join the course at a later date when the exercise has already started. This way, users who are not supposed to be added to new exercises will not be added and lectureres will not have to add users manually.

A checkbox should be implemented to document that the lecturer wants the users to be automatically added.

Mockup upcoming

Variante 2: Non role specific

Users within a course should be added automatically to new exercises. This automated process should also work for users who join the course at a later date when the exercise has already started. This way, lectureres will not have to add users manually.

A checkbox should be implemented to document that the lecturer wants the users to be automatically added when creating the exercise. 

Byline: If enabled, all users from the current course will be added to the exercise.

3 User Interface Modifications

3.1 List of Affected Views

• Creation of exercises

3.2 User Interface Details

See above.

3.3 New User Interface Concepts

None

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 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: Becker, Matthias [matthias.becker]
• Maintainer: Killing, Alexander [alex]
• 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.

• Hochschule Bielefeld

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