Set Registered Attribute for Registration Procedure No Registration Necessary

This feature request is a part of the Calendar Revision III.

1 Initial Problem

I. If no login is required for a session (setting "No Registration Necessary"), everyone with Read Access and View permissions will automatically have access to a session. The user himself is not explicitly listed as a session participant. The access rights for the session are only controlled via the role "Course Member" or "Group Member".

II. In return, the other two options "Declare Participation" and "Apply for Participation" require a registration (from the user or the admin of the session). If the user receives the attribute "Registered", the user is handled as a "session participant". In this case, specific permissions can be assigned to the "Session Participants" role.

The role "session participant" is therefore related to the column or attribute "Registered". If registration is not necessary, there are no session participants, so to speak. However, it is actually the situation that in the case where no registration is necessary, all users of a course or a group are "session participants" for all sessions - at least potentially.

2 Conceptual Summary

It would be consistent if each person (course member, course tutor, course admin, or group member, group administrator) were automatically listed as a session participant if setting option "No Registration Necessary" is set.

This would have the following advantages:

1. The column "Registered" would always be visible and not dependent on one of the selected settings.
2. The role "session participant" would always be available for each session and would not depend on any particular setting.
3. Session participants could be assigned specific permissions (independent of a course member role). If desired, a course member could simply be excluded from a session without changing the setting of the session at all.
4. It's clear, that even if "No Registration Necessary" is activated, every member is participant of this session.

2.1 Scenario 1

In combination with feature Personal Calendar - Show only session appointments where user is participant it is possible to define who can see which sessions of a course in their own calendar. Namely, only those that are relevant for the user, i.e. for which he/she is registered. In this case all persons of a course or a group have to be listed automatically as "Session Participant" and thus get the attribute "Registered".

Preconditions

Outcome

2.2 Scenario 2

If several lecturers are responsible for different sessions, but all course members attend, the attribute "registered" can be used to control that only certain lecturers have access to a session.

This means that even if no registration is necessary for the members, all of them (including tutors and admins) are already registered as session participants for the session. It can be defined manually or via interfaces that only certain of the tutors or lecturers are session participants or those who have nothing to do with the session (and do not need to see it in the course content or calendar) can be "deregistered". Lecturers will only see their own appointments if they have the appropriate rights settings.

Preconditions

Outcome

3 User Interface Modifications

3.1 List of Affected Views

• Session > Participants

3.2 User Interface Details

Combination of settings "No Registration Necessary" and "Registered" column in Participants Tab

3.3 New User Interface Concepts

No new user interface elements

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 Contact

• Author of the Request: Seiler, Yvonne [yvseiler], Amstutz, Timon [amstutz] (Universität Bern)
• 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.}

6 Funding

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

• Universität Bern

7 Discussion

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

Approval

Approved at {date} by {user}.