multi-calendar next steps

[kabaros]

We discussed the next steps for supporting multi-calendar work (on Monday 19th of June).

The current situation

We added support for multiple calendrical systems to 2.40. This involved:

• Creating UI components in the dhis/ui library: Calendar and CalendarInput that work with different calendrical systems (Ethiopic and Nepali for example)
• We added support for multi-calendar period generation in @dhis2/multi-calendar-dates, among other periods and dates utilities. Documentation for the current supported methods can be found here.
  • This was used to replace period generation logic in analytics library.
• The Data Visualizer (through analytics library) and Data Quality apps now support multi-calendar systems.

The current state of support can be seen in this Jira epic. Next, we want to support the rest of the apps, with the aim of eventually having full support for multiple calendar systems across DHIS2.

Next steps and actions

• Backend: To add support for Tracker. Before then, they will revisit the current implementation, and see if any refactoring should be done. To be led by: @abyot @jbee

  • some open questions are: how many tracker endpoints are affected? who does the actual work once defined and scoped?

• Analytics: Confirm that Line Listing and Dashboard work as expected (with the upgrade of analytics library), and that there are no other use cases for the date picker in Analytics. Done by @edoardo and confirmed that no further changes needed.

• Analytics: Discuss year on year calculation, mainly how reconciliation of differences between different month lengths should be handled. Is it a FE or BE concern or both? @edoardo to lead discussion with different stakeholders

• Tracker FE: FE will start with integrating the new UI component - Owner @JoakimSM

  • Tracker has identified issues they would like tackled before releasing the changes, but none of them should block starting the integration: LIBS-418 is the main one

• Mobile: start a PoC for using Kotlin multi-platform for generating periods (and other date utilities) to replace the core logic in @dhis2/multi-calendar-dates - next step would be to define what that PoC can tackle jose @vgarciabnz @marcamsn @andresmr

• Platform: Add support to Import/Export app @kabaros

• Platform: Implement tweaks and fixes to the UI components, and any other requests from the teams for adding period generation or dates logic to the multi-calendar library. @kabaros

Other notes

• In the current use cases, the FE sends dates in the specified calendar system (not converted to gregory). Any conversions needed happen in the backend. If that changes as a result of the code refactor, then we'd need to revisit the apps already supported. This is not a difficult task but something to keep in mind.
• If we decide Year on Year edge cases are to be handled in the Frontend, then we can encapsulate the logic in helpers in multi-calendar dates to keep it centralised and reusable.

[edoardo]

If we decide Year on Year edge cases are to be handled in the Frontend, then we can encapsulate the logic in helpers in multi-calendar dates to keep it centralised and reusable.

This logic requires to manipulate the analytics API responses, if the logic needs to be in helpers the analytics responses need to be passed in from the app/plugin and the resulting data sent back to the app/plugin for feeding the chart engine.