feat: export /tracker/event using different idSchemes DHIS2-14968

[teleivo]

Allow users to export tracker data using the same idSchemes supported by the importer

• UID
• CODE
• NAME
• ATTRIBUTE

and the same idScheme related request parameters. This is guaranteed by using the same type TrackerIdSchemeParams.

This PR adds support for

• idScheme
• orgUnitIdScheme
• programIdScheme
• programStageIdScheme

For example

GET /tracker/events/{uid}?fields=orgUnit&orgUnitIdScheme=CODE

Our mappers now need to know about the TrackerIdSchemeParams. All other exporters which do not yet support idSchemes other than UID are not affected as they use the TrackerIdSchemeParams.builder().build() which defaults to UID.

Out of scope for this PR:

• categoryOptionComboIdScheme, categoryOptionIdScheme, dataElementIdScheme: will come in following PRs 😅
• relationships: metadata in relationships also needs to use the requested idScheme.
• handling of metadata that does not have a value for the requested idScheme. I'll solve that in another PR.

Tests

Tests are important as idSchemes was a major source of bugs in the tracker importer and exporter in the past.

This feature is tested using a controller integration test with Postgresql. As the logic is in the web layer (mapping of metadata using the correct idScheme to string) and the repository (getting the different idSchemes).

The test only tests against the "single" event controller method as

#18943

made sure it uses the same path as the collection controller method.

The test only tests the metadata-specific request parameters as

#19060

made sure the logic of idScheme vs metadata-specific parameters is in the TrackerIdSchemeParams type and unit tested.

Example errors if we mess up our test setup and logic.

Fails if our setup misses metadata. This avoids false positives of expected == actual with null == null or "" == "".

[ERROR] Failures:
[ERROR]   IdSchemeExportControllerTest.shouldExportMetadataUsingGivenIdScheme:165->assertMetadataIdScheme:194 event metadata assertions (1 failure)
        org.opentest4j.AssertionFailedError: metadata OrganisationUnit(h4w96yEMlzO) has no value in test data for idScheme 'CODE' ==> expected: not <null>

Fails like this if the field does not show up in the response due to for example an error in our store

[ERROR] Failures:
[ERROR]   IdSchemeExportControllerTest.shouldExportMetadataUsingGivenIdScheme:165->assertMetadataIdScheme:194 event metadata assertions (1 failure)
        org.opentest4j.AssertionFailedError: field "program" is not in response {"programStage":"NpsdDv6kKSO code","orgUnit":"h4w96yEMlzO code"} for idScheme 'CODE' ==> expected: <true> but was: <false>

Fails like this if the field does not have the expected idScheme (expected takes the correct field using the idSchemeParam)

[ERROR] Failures:
[ERROR]   IdSchemeExportControllerTest.shouldExportMetadataUsingGivenIdScheme:165->assertMetadataIdScheme:194 event metadata assertions (1 failure)
        org.opentest4j.AssertionFailedError: field "program" does not have required idScheme 'CODE' in response ==> expected: <BFcipDERJnf code> but was: <BFcipDERJnf>

[sonarqubecloud]

Quality Gate failed

Failed conditions
1 New issue
1 New Code Smells (required ≤ 0)

See analysis details on SonarCloud

Catch issues before they fail your Quality Gate with our IDE extension SonarLint