Report graphql queries and backwards compatibility

[andreievg]

A placeholder to record this conversation: https://github.com/openmsupply/open-msupply/pull/1979#discussion_r1261858646

An outcome of this issue would be a strategy to deal with potential changes to graphql api that may affect report. (for now we should not make any breaking changes to query API).

Back of an envelop solutions could include:

• API versioning in reports and outside of reports, with translators
• Some sort of test (a bit hard in sync system with different remote server versions)

Suggested solution

Manifest file to include min omSupply version, allow multiple reports with the same name (can't put in just report json since report arguments can change), add om_ field for version in mSupply. See epic for easy of deployment and testing

[andreievg]

There seems to be a break in standard report, as mentioned in telegram chat.

Looks like it happened because default query was changed, if query is not specified (and the template considers data in the previous query shape). We did emphasises the importance of not changing API for reports, but missed the point about changing default queries.

I see this as a very high impacts area (a lot of effort to fix and a lot of disruption to users workflow) with medium likelihood, so very high risk.

Would propose we add tests for standard reports and add for consideration in triage

[andreievg]

I think this needs to be looked at by Ruru team during report work

[mark-prins]

Note that the breaking change was to the default graphQL queries, if we bundle gql with the report then we don't repeat that particular issue. there is potential to introduce a breaking change to the graphQL schema - that could well break other parts of the app too though.

[andreievg]

that could well break other parts of the app too though.

Our codegen would tell us, but yes there is a potential to break other parts of the system as a whole (integrations)

[roxy-dao]

Already done in epic #4800