DataCollection : Switch to ‘Contributors‘ instead of ‘Owner‘

1 Initial Problem

At the moment, an entry in a table of a data collection has exactly one owner.

If you want someone else to be able to edit this entry, you can a) give everyone in the data collection permission to edit other people's entries or b) change the owner of the entry.

• For a) this means that you can change all entries, not a specific one.
• For b) this requires the “Owner” field to be editable and means that you can no longer access the entry yourself if you handover it to another owner.

Good examples of these obstacles are the joint submission to the call for papers for the ILIAS conference and the plug-in data collection for ILIAS.

2 Conceptual Summary

Instead of a single 'owner', there should be several 'contributors'. 

• If someone changes an entry in a table, they are automatically added to the set of contributors for this entry.
• Contributors can add other contributors and delete other contributors.
• All contributors have equal rights
• There is always at least one contributor
• Questions about visibility, mandatory status and lock for entry editing are still handled in the respective view.

In the process of the feature modification, the often very extensive form usages for entering data records is to be revised.
As this form can contain all data field types, this is an important step towards UI refactoring to use KitchenSink Forms.

3 User Interface Modifications

3.1 List of Affected Views

Change 'Owner' to 'Contributors' in …

• … Edit Entry of a Table of a Data Collection
• … View Configuration
• … Field Settings in Table
• … Export of Data Collections
• … and some more labels in 

3.2 User Interface Details

Use KS Tag Input to set multiple contributors. If possible by AutoCompletion to users database.

Changes to all corresponding identifiers.

3.3 New User Interface Concepts

None

3.4 Accessibility Implications

Nothing specific.

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

{ Please list all personal data that will need to be stored or processed to implement this feature. For each data point, provide a short explanation of why it is necessary to use that data. You may consult the Privacy Clinic for questions regarding the legality, minimization, or appropiate use of personal data in compliance with applicable privacy regulations such as GDPR. }

6 Security

Nothing specific.

7 Contact

• Author of the Request: Samoila, Oliver [oliver.samoila]
• Authority to Sign off on Conceptual Changes: Seeland, Per Pascal [PerPascalSeeland], Samoila, Oliver [oliver.samoila]
• Authority to Sign off on Code Changes: Seeland, Per Pascal [PerPascalSeeland], Szmais, Ingmar [iszmais]
• 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

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}

Privacy

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

Approval

Approved at {date} by {user}.