[configuration] mapping field and tree UI features

[regisoc]

Is your feature request related to an existing module?
Implementation expected for Configuration module.
It should be accessible to anyone having already the right access to the configuration module.

Issues

Configuration is handled by:

1. the config.xml file, no UI.
2. the couple Config/ConfigSettings tables in the database, with UI.

To get a config item, the main process goes through the NDB_Config::getSettings() method which first take a look at the config.xml file, then if nothing is found, go to the db.

The problem is two-fold:

1. LORIS does not have a mapping field type implemented in the config module, which forces to hardcode them. Adding the mapping field in the config.xml file might not be the best idea as it can be very verbose e.g. redcap module config.xml section, this is a single instance, single project example, but there can be multiple of them.
2. Even if LORIS has already a recursive-enabled config tables (ConfigSettings.Parent -> ConfigSettings.ID reference), the current UI is only able to display one level. For instance, Study main category is the root level parent, and all level 1 items such as study title and study logo are displayed with their associated values. We can go deeper in the database organization/structure e.g. representing redcap module level structures, but we cannot display them on the configuration UI.

It would be very useful in a context where complex configurations or configuration details are required.
Complex configuration are handled in the config.xml because it is easier to access and modify, but the display lacks the full picture only showing the db side.

Describe the solution you'd like

1. Mapped values + UI

The goal is the include:

• a mapping element capability in the config and configsettings tables,
• PHP methods to get the mapping,
• and a UI equivalent to access them from the front-end.

For instance, adding a couple of db elements to be able to have mappings of values, even the case of listed/multiple elements.

Original	Example of change

Or even better: a different table.

UI:

• have two values on the same line for a simple mapping.
• if the items it also set as allowMultiple = true then it should have a couple of items per line.

2. Configuration tree + UI

Ideally, having interactive and collapsible blocs of elements organize in a tree-like structure should be the targeted.

I do not have a definitive UI in mind, and it should be discussed. Here is a quick proposition:

• A header for each item (similar for leaf or node items) that contains: config name, label and description.

• By default, the header is the only part visible. When clicking on a leaf header, it expands and makes the leaf properties accessible. E.g. with boolean leaf and text leaf, once clicked on the header:

• For node headers, it unfolds into its children nodes:

• And of course, the mapped values from the first point should also be included:

In DB:

• Common Table Expression (CTE) are available on MariaDB.
• Recursive CTE were added in MariaDB 10.2.
• We can limit the number of iterations with max_recursive_iterations to avoid going into neverland.
• So, technically, already set.

Example of UI: demo_html_20260414.html

Other designs can be discussed.

[ridz1208]

If I may build on this as well a couple usecases:

1. This ties into item 2 in the proposal but I think it's important to present it as a special usecase. Many of our study entities (projects, sites, cohorts) either use hacky pages stapled to the config module or simply dont have a config page. this new design should be able to handle the additon of such entities in a more standardized way. This could leverage the multi dimension config suggested above but it differs on the fact that the information itself is then stored in specialized tables and not the config tables. Having the ability to register study entities in the config module would be a major gain for the platform. I dont have a specific design in mind but I imagine a 3rd SQL Config table like ConfigExternalEntities which defines for each study entity (project, cohort, site), the list of fields they require as well as the storage location for them. In my design the regular configs and study entities would have a different interface/category

2. Another missing feature of the module is uploaders. You can currently change your logo displayed for the study but the alternate logo must be submitted through github making it unusable without developer involvement. The module should have it's own uploader and a path for config uploads to delegate such tasks purely to non-technical staff.

[regisoc]

@ridz1208 1. Yes! Can be a third point by itself. 2. Definitely, and that also ties to the media module then.

[regisoc]

1. separating categories vs. other items.
2. mapping item.
3. multidimensional.
4. complete GUI rewriting.

TBD uploader items type + study entity supported.