Session Registration Notifications

1 Initial Problem

Some scenarios require that sessions need a bit or maybe even quite some preparation, maybe confirmation or other manual steps for the session to be well prepared and a success.
At the moment, information on the participation of a session is not propagated but just stored. In order to deal with participants of a session, it is required to "patrol" the relevant sessions, checking user-lists. With a rather leightweight, optional feature, the situation can be enhanced for all kinds of supporting personnel dealing with session participants.

Excursus - Existing Solutions

There are already two ways of defining users that are notified about an event:

The already existing alternatives to realise such a workflow show the need to unify this UI element - as also stated by the Jour Fixe at January 21, 2019. We need one solution that fits for the new notification about a new session registration as well as for the already existing ones above (and all other upcoming usages as well).

2 Conceptual Summary

It is hereby proposed, to offer a new settings-group on individual session objects, allowing for named accounts to be notified of joining and leaving session participants by ILIAS- or E-Mail.
The messages sent will contain a _goto-Link to the corresponding sessions member management page.

3 User Interface Modifications

3.1 List of Affected Views

The Session-Settings Form, Section "Registration Settings" will be extended to hold the above described options.

3.2 User Interface Details

Actual Suggestion - Apr 2019

This third suggestion reduces the amount of code revision for the feature request and adapts the column pattern for notifiying users about new or leaving participants from the course and group object.

• We assume that notification in sessions is not always needed and therefore suggest to make it a session feature that can be enabled in the session's settings. Label option is "Notification". Setting should be part of the "Registration Settings" block because it notifies about new participants.
• We also considered that notification settings per user already exist in the parent course or group and might be reused easily. Therefore, we added the possibility to inherit the notification setting from the parent object in a radio box. Default option will be "Inherit from Parent". If toggled, the users that have Notification enabled in the parent course or group get a toggled checkbox in the Notification column of this session, too. The checkbox element is disabled and cannot be changed in the session in this case.
  In case, the session creator doesn't want to inherit these settings but set them manually for each created session, the radio option "Set manually" can be used and no checkbox will be toggled automatically.
• If option "Notification" is disabled, no sub-checkbox is shown.
• Notification feature can be used with all registration procedures. If procedure "Apply for Participation" is chosen, the user(s) with enabled  "Notification" setting for this session will be notified. In case "Notification" is not enabled, the feature behaves like now (notification setting of parent object are used).

Second Suggestion - Mar 2019

The second suggestion was accepted by Jour Fixe, see below. But due to missing funding for the necessary streamlining of this feature, a third solution was required, see above.

Suggestions for a streamlined handling of the notifications input in courses, groups and sessions - as required by Jour Fixe (see below).

Notifications Setting in Course

Existing column "Notification" in Course » Members : Edit Participants will be removed. DB migration step has to add login-ID of those users with toggled notification checkbox into the new input on Settings screen.

Notifications Setting in Group

Existing column "Notification" in Group » Members : Edit Participants will be removed. DB migration step has to add login-ID of those users with toggled notification checkbox into the new input on Settings screen.

Notifications Setting in Session

In difference to the original suggestion, this mock-up is offering one input for user names both for new participations/applications and cancelations. It is assumed that always the same group of people have to be informed about changes in participation lists - like it is already done in other components.

Notifications setting in Authentication settings

No change required at the existing UI implementation.

Notification settings in user administration

There is no way to migrate the current implementation that requires an e-mail address as input to a login-ID-based input field. The entered e-mail-address might not match to a registered user - or it might match to multiple user accounts.

• Option 1 : We keep this screen as it is.
• Option 2 : We substitute this screen by the login-ID-based one and keep the input empty.
• Option 3 : We substitute this screen by the login-ID-based one and add the login-IDs that are already added to Administration » General Settings : Contact Information - if there are any entered.

Original Suggestion - Jan 2019

Based on registration settings being either "Declare Participation" or "Apply for Participation", a new set of options will be shown.

• Checkbox "Notify User on New Participation/Application"
• Sub-Enabled TextInput for a user with autocomplete
• Checkbox "Notify User of Participation Cancellation"
• Sub-Enabled TextInput for a user with autocomplete

Login names will be validated when form is submitted. Corresponding failures will be reported.

3.3 New User Interface Concepts

No new user interface concepts will be introduced.

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: Becker, Maximilian [mbecker] Databay AG for initial suggestion, Kunkel, Matthias [mkunkel] for collection of existing solutions and suggestions 2 and 3.
• Maintainer: Meyer, Stefan [smeyer]
• Implementation of the feature is done by: Meyer, Stefan [smeyer] / Jansen, Michael [mjansen] (will provide a PR with the code implemented for the funding party / will subcontract Meyer, Stefan [smeyer] for the final implementation)

6 Funding

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

• …

7 Discussion

JourFixe, ILIAS [jourfixe], 21 JAN 2019 : We highly appreciate this suggestion but would like to streamline it with existing features for notification of tutors/admins when participants or members join or leave a course/group/.... Matthias will look for a former suggestion to streamline this and make a suggestion to the JF. In general, we support the idea to handle the definition of users to be notified as part of the settings or an object (and less of the job for managing the members).

Kiegel, Colin [kiegel] 2019-02-14: If the user profile is activated, we could also introduce a link to the user profile in the email. Maybe the tutor wants to have a look at the person instead of the session. This would save a few clicks.

Kunkel, Matthias [mkunkel], 09 MAR 2019 : I made a suggestion for a streamlined input for registration notifications as required by the Jour Fixe. In case these suggestion is accepted I recommend to re-label this page to "Streamlining registration notifications and support for sessions".

JourFixe, ILIAS [jourfixe], 11 MAR 2019 : We highly appreciate this suggestion and schedule it for 6.0. We prefer option 2 for the screen "Notification settings in user administration" (change to ID-based input and left empty). In addition to the suggestion above we would like to have a check when saving the form if the entered user name exists and if this user has access (manage members permission) to the related object. If not, an Info message about missing permissions is presented but saving the form is still possible.

Studer, Martin [mstuder], 11 MAR 2019: Could this be the Input Field for this:  https://github.com/studer-raimann/CustomInputGUIs/tree/master/src/MultiSelectSearchInputGUI

The feature wiki page for this Input GUI: https://docu.ilias.de/goto_docu_wiki_wpage_2638_1357.html

Jansen, Michael [mjansen],  21 MAR 2019: We came to the conclusion to offer an alternative approach, that would also meet the funding parties demands - functional as well as financially. We expect the new iteration to be much more likely acceptable being the addition of "Notification" column, where we'd show checkboxes for each participant-row, similar to "Group" and "Course" objects.

JourFixe, ILIAS [jourfixe], 25 MAR 2019 : We accept the suggestion to adapt the notification procedure to the known one from courses and groups. But we still need a good suggestion how to handle the problem of presenting this new column. We would like to avoid more clutter on this table. One option could be to handle this notification as an additional feature that needs to be enabled in the session settings to be presented in the column. Matthias and Michael will work out a suggestion for the next JF.

Kunkel, Matthias [mkunkel], 04 APR 2019: I made a third suggestion to realise this feature, see above! This suggestion hopefully solves the problem of presenting the new "Notification" column.

JourFixe, ILIAS [jourfixe], 08 APR 2019 : We highly appreciate suggestion 03 and accept it for 6.0.

Jansen, Michael [mjansen], 26 JUL 2019: PR: https://github.com/ILIAS-eLearning/ILIAS/pull/1920

8 Implementation

Test Cases

Test cases completed at 2019-08-19 by Jansen, Michael [mjansen]

• C31849 : Benachrichtigungsoptionen beim Erstellen einer Sitzung
• C31850 : Benachrichtigungsoptionen in den Einstellungen einer Sitzung
• C31851 : Speichern der Benachrichtigungsoptionen in den Einstellungen einer Sitzung
• C31852 : Benachrichtigungsmodus: Manuell
• C31853 : Vom übergeordneten Objekt erben
• C31854 : Benachrichtigungsmodus: Keine Benachrichtigung
• C31855 : Auswirkung der gewählten Optionen auf Benachrichtigungen

Approval

Approved at 12.06.2019 by Kubier, Michelle [kubier].