feat(DHIS2-17506): enable configuring a section display options

[flaminic]

This PR adds display configuration option to the data stets, similarly to what was done for the sections metadata. This is needed in order to allow users to select the directions of tabs, if they choose to render a section as tab - Implements DHIS2-17506.

Implementation details

• The displayOptions was added as a JSON type to allow us flexibility to add more options without updating the back-end, similarly to what was done for sections. See discussion in this PR for

• The change includes a migration to create the new columns (applied in v42)

Background

We are aiming to add more form configuration options as part of an initiative to provide configurations natively to data entry forms to reduce the necessity for custom forms. Users are currently building custom forms as a workaround for shortcomings of the configuration options (ability to transpose, or customise a cell design) or implementation (such to avoid issues with RTL issues).

This is an RFC that describes the approach and the priorities for form configuration options. This is based on a thorough investigation by the functional design team for custom form use cases in real-life implementations. Based on that investigation, the ability to show section tabs vertically were one of the main reasons people choose to go the custom forms route so we're tackling these first.

UI

The ui is still work in progress but it will look like similar to this:

Screen.Recording.2024-06-25.at.16.05.35.mov

Related PRs:

data entry app
maintenance app

[david-mackessy]

Hi @flaminic , could a description be added to this PR, giving some info around why the change is needed, the approach being taken and any future plans regarding display option properties? The PR guide is handy to be aware of.
Is the new field being returned as expected?
Ideally there would be a test included for the new behaviour, I can help with that if needs be.

[flaminic]

Hi @flaminic , could a description be added to this PR, giving some info around why the change is needed, the approach being taken and any future plans regarding display option properties? The PR guide is handy to be aware of. Is the new field being returned as expected? Ideally there would be a test included for the new behaviour, I can help with that if needs be.

Hey, I hope now it's better :)
I think so, tested it locally using postman and both post and get work well. But I will keep the PR in draft for a bit longer, until I fully tested it with the new UI.
I would love some help with the tests!

[jbee]

Looks good.

As David said we usually try to add at least a test for something surfacing in API but since this is purely for the UI I don't see a need to test this as part of the backend as it should be tested as part of the app using it.

I might have already said it in the PR for Section that I don't think it is such a good idea adding UI concerns to the backend model. Especially since you want JSON there is the datastore which is a perfect fit to use for settings like these. But that boat has sailed, I guess. I vaguely remember a conversation and that the solution should only be "temporary"? Or it is just me hoping it is 😂

I guess what we have no good support for yet is datastore values that are "auto-cleaned" on deletion of a metadata object. We maybe should build that feature so there are no excuses to not use the datastore :)

[flaminic]

Looks good.

As David said we usually try to add at least a test for something surfacing in API but since this is purely for the UI I don't see a need to test this as part of the backend as it should be tested as part of the app using it.

I might have already said it in the PR for Section that I don't think it is such a good idea adding UI concerns to the backend model. Especially since you want JSON there is the datastore which is a perfect fit to use for settings like these. But that boat has sailed, I guess. I vaguely remember a conversation and that the solution should only be "temporary"? Or it is just me hoping it is 😂

I guess what we have no good support for yet is datastore values that are "auto-cleaned" on deletion of a metadata object. We maybe should build that feature so there are no excuses to not use the datastore :)

Awesome, thanks @jbee .
eheh i see what you mean re the datastore. In this case, i prioritized coherence with the section work. But we did mention with @kabaros that the work on the new maintenance app will give us an opportunity to clean a few of these rendering fields. One idea was to group them all in display options, but also, i think this is a good opportunity to evaluate the different options :)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[jbee]

@flaminic we discussed the datastore feature I suggested today in the platform backend meeting and one reason to keep this information in the metadata objects themselves is that often people want this to transfer with the matadata object. So if you were to export a dataset you want the system that imports it to also get the display options. Thus it is better to have it as part of it so this information always stays together. We said that going forward what we will aim for is to consolidate all display related settings in one JSON(B) field like the one added in this PR.

[flaminic]

@flaminic we discussed the datastore feature I suggested today in the platform backend meeting and one reason to keep this information in the metadata objects themselves is that often people want this to transfer with the matadata object. So if you were to export a dataset you want the system that imports it to also get the display options. Thus it is better to have it as part of it so this information always stays together. We said that going forward what we will aim for is to consolidate all display related settings in one JSON(B) field like the one added in this PR.

Amazing thanks @jbee. Tagging @Birkbjo as he might be interested in the above comment.