Feature Wiki

Information about planned and released features

Tabs

DataCollection : Revision of Uniqueness of Field Entries

Page Overview

[Hide]

1 Initial Problem

The question of the correct interpretation of uniqueness is a recurring problem. See Mantis: 16674, 36938 & 30758.
Former Authorities of Data Collection can tell you a thing or two about this conceptual mess.

There are field types that simply cannot meaningfully support a uniqueness. This may be due to the specific content itself. But it can also be due to the fact that the value cannot be checked against uniqueness when other information is entered.

Examples:

  • Checking uniqueness for files and media objects: It is not practicable to check the specific file stored against a second file. The file name is not a useful parameter. Neither is the file size. Neither is the content of a document, which only needs one more or less space.
  • Checking uniqueness for the rating : The use of the rating is not part of the entry creation. Third parties can generate the same value from two data records that have nothing to do with the creation of the entry.
  • Checking uniqueness for the formula result : In the process of entering in n fields that are used for the formula of the formula field, their result in the formula field is not foreseeable.
  • Checking uniqueness for a Boolean: this only makes sense for data collections with tables that may contain a maximum of two entries. We assume that this is unnecessary for most users and can be achieved in other ways in case of doubt. We have therefore dispensed with uniqueness for Booleans.
  • Checking uniqueness for a Reference : The reference field can change its value, which would result in the uniqueness being violated in a table that refers to the value of the reference field. This potentially leads to problems that are difficult to handle.

2 Conceptual Summary

From now on, uniqueness will be only offered as the last setting option for the field types that are to support uniqueness.
Please see the list below:

Text Entry

 » uniqueness

Text Selection

 » uniqueness

Integer (Numbers)

 » no  uniqueness

Boolean

 » no uniqueness

Date Entry

 » no uniqueness

Date Selection

 » uniqueness

(Date-Time Entry)

 » no uniqueness

(Date-Time Selection)

 » uniqueness

Media Object

 » no uniqueness

Fileupload

 » no uniqueness

Reference

 » no uniqueness

Copy

 » no uniqueness

Link to an ILIAS module

 » uniqueness

Rating

 » no uniqueness

Formula

 » no uniqueness

[Plugin-Field] 

 » Plug-ins must decide for themselves whether they support uniqueness.

Side note: The Uniqueness setting can already be edited even if values already exist for data records. We suggest leaving this as it is and simply throwing an error when saving if the existing values are not unique. 

3 User Interface Modifications

3.1 List of Affected Views

  • 'New Field' in a table of a data collection
  • 'Edit Field' in a table of a data collection
  • Fields List. (The column "unique" should be removed since uniqueness is just a property after this implementation and no generall field setting)

3.2 User Interface Details

  • Remove the general checkbox "unique" from the Field form (create & edit)
  • Remove the column "unique" from the field table
  • Add one checkbox each into the subform of the datatypes "Text Selection", "Date Selection", "Date-Time Selection" and "Link to an ILIAS module" (create & edit)

3.3 New User Interface Concepts

None.

3.4 Accessibility Implications

No specific impact.

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

There should be a migration of settings for existing fields. If fields have the attribute “unique” and no longer support this after the revision, this change is made without any feedback.

4.3 Privacy

No changes on privacy aspects.

4.4 Security

No security aspects affected.

4.5 Contact

Person to be contacted in case of questions about the feature or for funding offers:  Samoila, Oliver [oliver.samoila]

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

Kunkel, Matthias [mkunkel], 13 MAR 2025: I see the need to restrict uniqueness to a couple of field types where checking the input is feasible. But we should not give up the option to require uniqueness for text input. Changing this as suggested above would destroy several workflows for the data collection. Example: when using the DC for submitting proposals or similar suggestions, you need to have a way to prevent the submission of two proposals with the same title. I can live with the exclusion of uniqueness for multiline text. But I won't accept abandoning uniqueness for text entries.

JourFixe, ILIAS [jourfixe], 17 MAR 2025: We highly appreciate this suggestion and accept the feature request for ILIAS 11 with the following modification:

  • Text entries keep the option of uniqueness (as required by Matthias). This will allow to keep existing workflows for the data collection, e.g. submission of suggestions. An additional feature request can tackle this problem by adding a kind of input check to prevent the use of empty spaces and similar characters to fool the uniqueness check.

6 Implementation

Feature will be implemented by Szmais, Ingmar [iszmais]

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}

  • {Test case number linked to Testrail} : {test case title}

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

Last edited: 17. Mar 2025, 22:33, Samoila, Oliver [oliver.samoila]