Split-Up Standard Fields Table and Move to DataTable

1 Initial Problem

With ILIAS 10 we will want and have to move the current table showing the list of Standard Fields for the user profile to a DataTable from UI-Components. This will lead to a few changes as the current implementation relies on form inputs inside the table. Additionally this table presently mixes Profile Fields and User Settings. 

2 Conceptual Summary

The Standard Fields will be Split-Up. The Profile Fields ("First Name", "Last Name", "Title, Birthday", "Salutation", "Avatar", "General Interests", "Offering Help", "Looking for Help", "Institution", "Department", "Street, Zip Code / Post Code", "City, State", "Country (Drop Down Selection)", "Phone, Office", "Phone, Home", "Phone, Mobile", "Fax", "E-Mail", "Second E-Mail", "Interests/Hobbies", "How did you hear about ILIAS?", "Matriculation Number", "Roles", "Organisational Units") will be shown together with the "Custom Fields" and the "User Profile Info" in a new Tab "User Profile".

The Remaining Fields ("Password", "Language", "Default Skin / Style", "Hits/Page", "Show your Account in "Who-is-Online", "Allow Contact Requests", "Allow On-Screen Chat Conversations", "Broadcast Typing", "Preferences", "Incoming Mail") will be kept in the Tab "Settings", but renamed to "User Default Settings".

We propose to get rid of the Field "Country (Free Text Input)" for new installations. For existing installations two migrations will be provided:

The two tables will be moved to a DataTable. The following changes will be made:

The table under "User Profile" >> "Standard Fields" will additionally have the following changes:

The table under "Settings" >> "User Default Settings" will additionally have the following changes:

3 User Interface Modifications

3.1 List of Affected Views

3.2 User Interface Details

Video Player

00:00

00:00

00:00

Use Up/Down Arrow keys to increase or decrease volume.

Video Player

00:00

00:00

00:00

Use Up/Down Arrow keys to increase or decrease volume.

3.3 New User Interface Concepts

It is proposed to add a new column type `Listing` that only accepts listings.

3.4 Accessibility Implications

Ensuring accessibility will be simplified by moving to the UI-Components.

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 date give a short explanation why it is necessary to use that date. }

6 Security

Ensuring security will be simplified by moving to the more consistent and standardized methods of data retrival provided by the DataTable.

7 Contact

8 Funding

9 Discussion

JourFixe, ILIAS [jourfixe], 22 JAN 2024: Suggestion is highly appreciated and feature scheduled for ILIAS 10. The current suggestion violates the guideline from the KS and the Guideline for presenting Actions buttons in tables. There might be good reasons to always have a dropdown (also when only one action is available). Stephan will discuss the issue with the KS coordinators and UI/UX experts and probably suggest a change of the guideline(s).

Kergomard, Stephan [skergomard], 06 JUN 2025:

During the development of this feature it became progresively clearer to me, that this feature request doesn't go far enough in the clean-up, so I suggest the following changes, to clarify its structure and make it possible to manage these settings reasonably:

• The tabs are reduced to three: Settings, Password, and Delete Account (if everything is activated).
• The settings in the «Settings»-tab are grouped into sections, only the first one will be shown by default, the others are only opened if the user has changed one of the settings from its side-wide default configuration.
• Currently four sections are available:
  
  • Main: Settings in this section are shown directly. Currently it only contains the language setting.
  • Date and Time
  • Communication
  • Additional Settings
• All settings need to have the option to define their visibility in Administration/User/Settings/User Settings. Settings that do not have this right now, will be set to visible on update.
• Only two visibility settings are provided “Changeable in User Settings” and “Changeable in Local User Administration”. The visibility settings are nonsensical in this case.
• The option to set a default value will be removed. The corresponding settings will be distributed. They cannot be seen as “default values” they are actually the global settings of a component, ie. the component Mail will notify it’s users. The only question the settings of the user do answer is, if the user is allowed to change that. On the other hand the option to make the setting of a starting point possible by the user will be moved here (it then is a simple question of the input being available or not).
  
  • "Show Your Account in ‘Who-Is-Online?" will be moved to the administration of "Who-Is-Online"-tool.
  • "Allow Contact Requests" will be moved to the administration of the user contacts.
  • "Allow On-Screen Chat Conversations" and "Broadcast Typing" will be moved to the administration of the chat.
  • "Incoming Mail" will be moved to the administration of Mail and an additional setting for “New Mail Notifications” will be added.
  • "Session Reminder" will be kept in the user and moved to Authentication as soon as a more viable settings form exists there.
• It is suggested to rename the input to set the format of the Date from “Date Input Format” to “Date Format”. It is a reality that it is used in this way in many places and this should be acknowledged.
• The setting to make username changeable by the user, will be moved to the default pattern (ie. it is set by a visibility setting in the table) and removed from the users administrative settings. The corresponding sub-settings will be grayed out, if the username is not visible to the user, the byline will provide the necessary information.
• Small language change: The column will not be called “Exportable”, but the original “Export”, as it is not exportable, but simply will be exported, leaving the exporter no choice.
• Components can provide settings by implementing an interface. Currently the contributions are collected during setup, in the future this should happen at runtime, allowing the injection of dependencies.
• The separate table for the custom fields in the profile will be removed. There is no stringent reason to separate the two. There will simply be fields that can be deleted and others that cannot. To make the fields easily distinguishable a column “type” will be added to the table. This will thus incorporate the feature request Move Custom Fields to Data Table  into this one. 
• When creating a custom field an option to select the section it will be shown in, is provided. There is no way to add additional sections.
• The plugin slot to add field types will be removed and replaced by a simple mechanism collecting the available types.

Questions

• A column showing the system value for the settings could be shown in the table, if desired.
• There is a setting called “Preferences” (“Benutzerspezifische Einstellungen”) with the quirk that it cannot be switched off for the “Profile”. I was completely unable to figure out, what it should do. It will be removed, if nobody can clarify what we expect from it.

10 Implementation

{ The maintainer has to give a description of the final implementation and add screenshots if possible. }

Test Cases

Privacy

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

Approval

Approved at {date} by {user}.