Membership History

1 Initial Problem

Oftentimes HR requires ILIAS to offer a more comprehensive set of 'Member Statuses' that ILIAS offers. This set typically includes 'Cancelled' and 'Requested'. 

They deal with disgruntled superiors and team members and trainer claiming to have been treated somewhat unfairly with regard to some course admission. These disputs are tiresome and could be resolved by information. It is terribly important to them to understand which Members unsubscribed themselves or were unsubscribed by a webservice or a Course Administrator and when. The same is true for the question when Membership was requested and who granted it when.

We consider this a valid need, however 'Cancelled' and 'Requested' are no statuses but events. This warrants a log or history. 

This informational need should be served with privacy in mind.

2 Conceptual Summary

The log should be globally activated in Administration > Repsoitory and Objects > Course. It is similar to the RBAC log. This means that a duration or 'shelf life' of the log entries can be put in. The log should log the execution context and be open for more object types to support logging.

The following Event Data is to be stored in History Service

• Object Type
• Object ID
• Object Title (in case object was deleted)
• Reference ID
• User ID of Agent / User who did it
• User ID of Member / Prospective Member User done to
• ILIAS component (e.g. Service/Membership)
• Event (see below)
• Datetime of Event

3 User Interface Modifications

3.1 List of Affected Views

• Administration > Repository and Objects > Course 

3.2 User Interface Details

oben: Nach Benutzern filtern

3.3 New User Interface Concepts

None

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 Information

The records should be automatically deleted after the set shelf live indicated in the Administration is passed. 

• We need to be able to export the logs since they comprise personal data. Export should be offered in the "Export/Import"-tab of the Personal Profile. Data fields comprising personal data of others need to be set to [anonymous].
• If a user is deleted the Firstname, Lastname and Login will be set to anonymous in all logs. 
• Logging only starts once the setting is set and stops, once the setting is deselected. Start and end of logging shall be displayed in al enrolment logs.

6 Security Implications

No foreseen security implications

7 Contact

• Author of the Request: Tödt, Alexandra [atoedt]
• Maintainer: Meyer, Stefan [smeyer]
• 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

Kiegel, Colin [kiegel] 2019-03-05: Nice - especially the consideration of privacy reasoning.

• You may want to also log de/activation of the log itself as a global event. Otherwise the log will be disputable. I.e. anyone could claim that the log might have been disabled for a short time, or something.

JourFixe, ILIAS [jourfixe], 25 MAR 2019 : We highly appreciate this suggestion and schedule the feature for 6.0 with the following modifications:

• Please include also the following actions to the enrolment log:
  • User joined
  • Added manually
  • Add from waitinglist manually
  • Autofill from waitinglist (by ILIAS)
• Additional filter for all supported actions (multi-select)
• Start and end of logging shall be displayed in all enrolment logs.

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}

Approval

Approved at {date} by {user}.