fix: handle options with non-unique codes across optionsets (DHIS2-15771)

[edoardo]

This requires a backend fix.

Fixes DHIS2-15771
Fixes DHIS2-16181

Requires DHIS2-15775

---

Key features

1. lookup option set option labels correctly in the table rows
2. show the correct name in the layout chip tooltips
3. refactor how the metadata for option sets is stored in Redux

---

Description

Options for different option sets can use the same code, which is what is returned in the rows in the analytics response.
The previous way of looking up the label to display in the table simply tried to find a metadata object whom code matches the value for the option set in the response's rows.
This cause to display the wrong label when different option sets are displayed at the same time and happen to use the same code.

Refer to the screenshots below.
The 3 columns are 3 different option sets, but they all use the same code (1) for their option.
The first matching code found in metadata items (in the analytics response) was always used regardless of the option set.

The fix is to look in metadata first for the optionSet, and find the matching option by code within the listed options.
Then the option's id is used to lookup the option itself in metadata and from there the name is extracted and used in the table.

The same logic needs to be applied when looking up the name to display in the layout chip tooltip for dimensions with option set where there is a specific selection (not all values).

We also need to add the metadata for the options when loading a saved visualization.
The reason here is that the table might not have all the values there are selected for the option set, and in that case the metadata from the analytics response is partial.

While working on this I realised that we don't really need to store the metadata for the single options of an option set.
Since we need them in the options object in the option set metadata anyway for the lookup, we can have the name in there as well and skip one lookup.

---

TODO

• Cypress tests
• Update docs?
• Manual testing

---

Known issues

• a Cypress test in table.cy.js is now failing due to this change. This is not a regression, it should be working once the backend fix is available.

---

Screenshots

Table before:

Table after:

Tooltip before:
Notice the names for the selected options are wrong when a different dimension with option set has also a selection and the code used is the same:

In this example, this selection was made first:

Tooltip after:
Notice the Pain medication dimension has 5 options selected, but the tooltip for pre-eclampsia is correct:

[dhis2-bot]

🚀 Deployed on https://pr-426--dhis2-line-listing.netlify.app

[cypress]

Passing run #2004 ↗︎

0

499

0

0

0

Details:

Merge e32b1ac into 120910e...
Project: line-listing-app	Commit: 3903e1245a ℹ️
Status: Passed	Duration: 12:22 💡
Started: Nov 23, 2023 2:51 PM	Ended: Nov 23, 2023 3:03 PM

Review all test suite changes for PR #426 ↗︎

[martinkrulltott]

findOptionSetItem could be written as a single line, but I see that splitting it up increases readability. However, I'd argue that some parts are a bit unnecessary/too explicit right now, which actually decreases readability.

[martinkrulltott]

Needs Cypress tests

[edoardo]

Needs Cypress tests

Added.

[dhis2-bot]

🎉 This PR is included in version 100.10.5 🎉

The release is available on:

• AppHub release
• GitHub release

Your semantic-release bot 📦🚀