Extend Log for Membership Changes

This Feature-Request is still in Progress.

1 Initial Problem

Currently, changes to course memberships (adding users, removing users, changing roles) are only visible in the Members tab.This results in three major issues:

Lack of Traceability: There is no reliable, revision‑safe way to track when membership changes were made and by whom.

Monitoring & Transparency: Administrators cannot efficiently monitor membership modifications, as the Members tab does not provide chronological or contextual information.

Data Protection: Displaying roles and membership changes in the Members tab exposes information to users who do not necessarily require access to it.

The course log is therefore the appropriate location, as access is restricted to authorized roles.

2 Conceptual Summary

The object log (for Courses, Groups, and all other ILIAS objects with member assignments) shall be extended to record all membership‑related changes, specifically:

To support this, two new log activity types will be introduced:

2.1 Detailed Behaviour

2.2 Filter Integration

The new log activities will:

2.3 Logging Output

2.3.1 Scope of Logging Extension

The logging extension applies to all ILIAS object types that manage members, including but not limited to:

2.3.2 Purpose of the Extension

The extended logging provides:

3 User Interface Modifications

3.1 List of Affected Views

The Log from every Course should be extended by two more Options:

• Edit Members of Object (Assign, De-Assign)
• Edit Member Roles (Change of Role, First Role Role Assignment)

If a course administrator is added to a course, this user will appear in both categories.

3.2 User Interface Details

Examples of new log entries:

Behaviour in the Log Table:

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 Additional Information

4.1 Involved Authorities

If this request is related to multiple components, please list both authorities for all related components.

4.2 Technical Aspects

Backward Compatibility

4.3 Privacy

{ Personal data that will need to be stored or processed to implement this feature have to be listed here. For each date give a short explanation why it is necessary to use that date. }

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

4.5 Contact

Person to be contacted in case of questions about the feature or for funding offers:  {Please add related profile link of this person}

4.6 Funding

Funding status and funding parties are listed in the block 'Status of Feature' in the right column of this page.

If you are interested to give funding for this feature, please get into contact with the person mentioned above as 'Contact'.

5 Discussion

6 Implementation

Feature has been implemented by {Please add related profile link of this person}

6.1 Description and Screenshots

{ Description of the final implementation and screenshots if possible. }

6.2 Test Cases

Test cases completed at {date} by {user}

6.3 Privacy

Information in privacy.md of component: updated at {date} by {user} | no change required

6.4 Approval

Approved at {date} by {user}.