omSupply Central Server Transition Carry Over

[andreievg]

Carry over issue for: https://github.com/msupply-foundation/open-msupply/issues/2062

Related PRs:

• [x] https://github.com/msupply-foundation/open-msupply/pull/2820
• [x] https://github.com/msupply-foundation/open-msupply/pull/2819
• [x] https://github.com/msupply-foundation/open-msupply/pull/2818
• [x] https://github.com/msupply-foundation/open-msupply/pull/2799
• [x] https://github.com/msupply-foundation/open-msupply/pull/2798

Carry Over Tasks

• [x] https://github.com/msupply-foundation/open-msupply/issues/3111
• [x] https://github.com/msupply-foundation/open-msupply/issues/3119
• [ ] https://github.com/msupply-foundation/open-msupply/issues/3113
• [x] Organise a meeting to talk over the questions
• [x] https://github.com/msupply-foundation/open-msupply/issues/3115
• [ ] https://github.com/msupply-foundation/open-msupply/issues/3116
• [x] Make sure all central data is soft deleted (there are TODO about this)
• [x] I had to add "../app_data" for test service for integration tests (since hardware id for the 'test' site is populated when omSupply central server for the test starts), and it needs to match when sites is created
• [ ] Investigate stack overflow, this happened when I tried by accident to push unknown shape to original central mSupply server, do we get infinite loop of there is some error in push to original central mSupply server ?
• [ ] I noticed invoices don't have is_sync_update, does it mean when transfer arrives we sync it back ? Or do we have another mechanism to filter out (by name_id ?) Should we just use is_sync_update to be consistent ?
• [x] Make sure that in conflict resolutions we rename Open mSupply Mobile accordingly
• [ ] is_sync_update on sensor record was removed in this PR,https://github.com/msupply-foundation/open-msupply/pull/2798, check this comment: https://github.com/msupply-foundation/open-msupply/pull/2798#discussion_r1472010044, maybe it needs to be reinstated because of the use case where CCA app syncs directly to the central ?
• [ ] https://github.com/msupply-foundation/open-msupply/issues/3117 Change i32 on cursor to i64 and migrate cursors to bigint (https://github.com/msupply-foundation/open-msupply/pull/2818#discussion_r1480733654)
• [ ] Relocate common API shapes to a shared space: https://github.com/msupply-foundation/open-msupply/pull/2818#discussion_r1480817799
• [x] https://github.com/msupply-foundation/open-msupply/issues/3118

Questions

1. When we omSupply central server in production, we will need to make sure it's backed up, and backup would need to match mSupply backup ? Or do we just try to backup the data that's different to mSupply ?
2. Should we allow omSupply remote sites to run without central server for now ? (since it's just central data and worst case the configuration would be missing ?)
3. Where to put sync steps for omSupply central ?
4. How do we determine is central server ? With env variable ? (also this: https://github.com/msupply-foundation/open-msupply/pull/2818#discussion_r1481981187)
5. The idea to use change log, purely, would it scale ?
6. What do feel about branching and fragmenting logic with is central server flag ? Do we split code base
7. Mirror server for future ? (i don't think it should be needed, since omSupply central would be easily accessible via browser and wont' require much bandwidth)
8. In order for all features for omSupply central to work, more information is required, which currently lives on original central server, do we sync it ? how ?
9. In the future, what would happen with existing mSupply sites if we decide to bring existing mSupply data to omSupply central sync ? (also how do we version/migrate existing omSupply sites for this ?)
10. Is current authentication modal ok for now ? (against original mSupply server)
11. Way forward ? I think we have enough for assets btw
12. Dashboard ?

Other thoughts

• Front end plugins to be installed on central and sync to remote
• Explore how to 'sync' updates for remote sites

[andreievg]

Proxy vs port offset, would prefer Proxy

[andreievg]

Reduce branching logic in front end by always using central server api for some operations

[andreievg]

central and remote as different crates using base

[andreievg]

For, is this central server, from this comment https://github.com/msupply-foundation/open-msupply/pull/2819#issuecomment-1955364839

• In legacy central mSupply central server configurations with configure which site is 'central' and how it can be reached (this is just stored against the 'sites' table).
• Before every sync operation, there is a call to some 'info' end point, this will double check that it's ok to sync this site and also will return back is this site central omSupply server and where is central omSupply server. That should give us enough flexibility and an easy way to inform existing sites that are updated, where to find omSupply server