Show Advanced KnowledgeHide Advanced Knowledge

Visibility of Sessions in Calendar

This feature request is a part of the Calendar Revision.

• Issue: Momentan werden alle Mitglieder der übergeordneten Container angezeigt, das wird wegen des "abhakens" der Teilnehmerliste für die Sitzungen mit der Einstellung "keine Anmeldung erforderlich" auch benötigt. 
• Tabellenfilter: angemeldete Benutzer,  alle Kursteilnehmer (default in Kursen), alle Gruppenteilnehmer (default in Gruppen) 
• Tabellenfilter teilgenommene Benutzer, 
• Jede Sessiona hat eine lokale Rolle "angemeldete Teilnehmer".
• Didaktische Templates für die Session, die Anzeige des Termins im Kalender hängt dann an den Rechten der Session: "Geschlossene Sitzung", die unterbricht die nicht-geschützten vererbten lokalen Rollen des übergeordneten Containers 
• Die Tabelle Mit den Sitzungsteilnehmern auf die Darstellung des Mitglieder-Reiters nachziehen. 

1 Initial Problem

Currently appointments automatically generated from sessions always are presented in course's or group's calendar. This is the case without regard to whether a user registers for the session or not. 

In a course with many sessions in which users are enrolled by an administrator or campus management system, the calendar that displays all session appointments cannot serve as a time table showing only appointments of sessions a user is registered for.

We want to use the course calendar as a time table and have many sessions in the course. 

2 Conceptual Summary

Sessions should get

• a new "Registration Procedure" setting "No Self-enrolment" in the "Settings"-tab.

If the Registration Procedure is set to "No Self-enrolment", the appoinments of this session should be not shown in the course calendar.  The appointment of the session should be shown only to those participants that are registered for that session. 

3 User Interface Modifications

3.1 List of Affected Views

• Settings tab

3.2 User Interface Details

Settings tab

Tab "Settings" in section "Registraton Procedure" as last option.

3.3 New User Interface Concepts

No new 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: Amstutz, Timon [amstutz]
• 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.

• ...

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