Update Course References When Study Programme Assignments Change

If you need any help in filling out this wiki page, please have a look at the page ’How To Suggest A New Feature’.
You can remove the editing notes (paragraphs in italics) after having created the request (same with this block).
Please don't forget to complete the metadata (‘Status of Feature’) in the right column after having created the page.

1 Summary

This feature enables the ILIAS ECS connector to add missing course references after an existing course is assigned to additional study programmes in HIS.
The updated course data is supplied through the HIS–ILIAS proxy and ECS, and ILIAS re-evaluates its attribute mapping while retaining existing placements and avoiding duplicates.
This keeps courses discoverable in newly assigned study programmes through the regular import workflow.

2 Problem Statement

In our setup, HIS is the campus management system, and course data is transferred to ILIAS through the HIS–ILIAS proxy and ECS. An existing course may be assigned to additional study programmes in HIS after it has already been imported into ILIAS.

In our ILIAS 10 installation, additional course references are created during the initial import according to the configured attribute mapping. However, processing further course data for an already imported course does not add the missing references for newly assigned study programmes. The course itself can be updated while its additional placements remain incomplete, even when the assignments are included in the received payload.

In the inspected installation, ilECSCourseCreationHandler::doAttributeMapping() identifies an existing course by its lectureID, synchronises it and returns before evaluating the mapping rules again.

Consequently, students and staff browsing a newly assigned study programme may not find the course there. Administrators need the additional references to be created automatically without recreating the course or manually maintaining its placements.

3 Concept

4 User Interface Modifications

4.1 List of Affected Views

Existing repository category content views, for example:

Repository → [Semester] → [Organisational Unit] → [Study Programme]
These views will display additional course references. No views are introduced, removed or structurally modified.

4.2 User Interface Details

Additional course references will appear as standard entries in the existing category content lists. Their appearance and interaction follow the existing course reference behaviour. No additional controls or configuration options are proposed.

4.3 New User Interface Concepts

No new user interface concepts are proposed.

4.4 Technical Aspects

The main affected component is the ECS Interface, particularly ilECSCourseCreationHandler::doAttributeMapping().

After synchronising an existing course, the connector should continue evaluating the attribute mapping rules and create missing references using the existing repository and permission mechanisms. Duplicate detection must consider both the real course and references pointing to it in each target category. Newly created references should trigger the existing course URL response.

No new database schema or ECS payload format is proposed. The implementation should preserve existing import identity handling. Performance implications and compatibility with parallel course and group scenarios require review by the responsible developers.

5 Non-Functional Implications

5.1 Security

No new endpoints or authentication mechanisms are proposed. Course references should be created through the existing ILIAS permission mechanisms.

Tests must verify that additional references respect the intended visibility and access permissions, including access to the target course. The responsible developers should review the implications of creating references in additional categories.

5.2 Privacy

The change uses existing course metadata, import identifiers, ownership and access permissions to determine and create course references. No additional personal data fields are proposed, and participant data does not need to be copied into each reference.

Any effects on the visibility of existing personal data and the component’s privacy documentation should be reviewed by the responsible developers.

5.3 Accessibility Implications

No new user interface components or interaction patterns are proposed. Additional references use the existing repository components and should retain their accessibility behaviour.

6 Process Information

6.1 Involved Authorities

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

6.2 Contact

Person to be contacted in case of questions about the feature or for funding offers:  Yannick Jentsch, FH Aachen.

6.3 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'.

7 Discussion

8 Implementation

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

8.1 Description and Screenshots

{ Description of the final implementation and the changed behaviour in the related components. Please add screenshots to visualise the changes if possible. }

8.2 Test Cases

Test cases completed at {date} by {user}

8.3 Privacy

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

8.4 Approval

Approved at {date} by {user}.