Closed jmbrunskill closed 6 months ago
Note: this isn't a trivial fix because all locations aren't synced to central server currently. Because central server is just another store, it doesn't get access to other store's remote data (such as locations)
Yea I don't see a way around this other than pursuing making OMS central server having all data from all sites synced to it - something ultimately planned todo.
Quick fix would be for OMS to send locations to legacy and OMS Central. That would cover most new use cases at least...
Bit confused by this issue - is it conflating 2 things? Deleting an asset and syncing locations to central?
On another issue I was suggesting that we hide the Location field for central users as they likely won't be concerned about where individual stock is kept in each asset and so wouldn't need to see / manage locations for assets that are not in their store?
Ah to add - I was imaging the central server would be where national asset management would be done, and that the users would need to log in as their actual central medical store if they wanted to manage their own assets for their own store (where they would then see the location field again)
Sorry I think I got confused when creating the issue too, was testing deleting but noticed the location bug. Updated the issue to be consistent now.
The problem is that the locations just don't exist on the central OMS server currently, so we can't show them. If it's acceptable I like the idea of just hiding the field entirely on the central server....
Hmm, I think it's probably acceptable to hide it as the main use case envisioned for the central user is to a) manage the distribution of the assets throughout the country and b) update any missing facility data required for CCEI Gaps Analysis.
But I can't see them ever wanting to interfere in the day-to-day operations of stock management of cold products?
The only thing that's nagging me a bit is that we are linking sensors to CCE via the locations and so that's a way for the central user to be able to tell if a CCE has a temperature monitoring solution assigned to it.
So potentially there could be an argument that they need to be able to update those fields for the CCEI Gaps Analysis, but also we might need to think of a different way to make the association between sensors and CCE because a lot of facilities will be using RTMDs which will not interfacing with Open mSupply and so we won't have them in the sensors list anyway.
Hmmm
Ah to add - I was imaging the central server would be where national asset management would be done, and that the users would need to log in as their actual central medical store if they wanted to manage their own assets for their own store (where they would then see the location field again)
Do you mean having several active stores on the central server for different medical stores (to be clear when most people say central medical store there is one store/facility that is the CMS), or login to stores on central server that are active on remote sites?
Do you mean having several active stores on the central server for different medical stores (to be clear when most people say central medical store there is one store/facility that is the CMS), or login to stores on central server that are active on remote sites?
Hmm... I mean I was thinking there were plans to separate the central server config functionality from the central medical store operation functionality.
And that the national asset management should sit in the central server config functionality rather than the central medical store operation functionality.
Not sure if I'm explaining that clearly - in other words it's a central user overseeing the national system rather than a central user overseeing their own central store?
@adamdewey Right! I think generally as any kind of formal structure that might be a ways off, I believe the current recommendation is to just make a dummy store if not wishing to do any stock management on the central server.
In terms of UI I think there was a plan to put central server management stuff separate from everything else, but you'd still need to be logged into a store least we have to rewrite the permissions model we've been using for millennia
Cool gotcha.
In that case I think there would need to be a store for national management of the assets, and another store where the CMS would only see their own assets for day-to-day management?
And so the CMS user would need to see the location field when managing their own CMS assets, but I can't see much value in showing the field in the national management store because the CMS user probably wouldn't understand what the location codes mean without context and so why would they start assigning them to CCE randomly?
Yup that's fair - CMS managing their own store with rest of their data they should (and can) see their locations. Other stores active on remote sites they'd not be able see locations with the current sync system and perhaps it should just be hidden. IDK if there are FK constraints that'd prevent that at the moment, would leave that as technical details though.
Think we might have to do it the other way around though 🤔
Like the CMS store would have to be the remote site and then have a dummy central store for 'National' where Master Data config and national asset management is done?
Haven't really thought it through properly...
Think we might have to do it the other way around though 🤔
Like the CMS store would have to be the remote site and then have a dummy central store for 'National' where Master Data config and national asset management is done?
Haven't really thought it through properly...
Yup that'd work I think. In my description I was meaning in the case that central warehouse also manages the server hardware and hosting mSupply - in that case the central server could have both National
and CMS
if you wanted.
Yup that'd work I think. In my description I was meaning in the case that central warehouse also manages the server hardware and hosting mSupply - in that case the central server could have both
National
andCMS
if you wanted.
Ah I see - I guess the only issue there is that both the National and CMS stores would then see all national assets for all stores appear in their Asset Register?
triage: let's hide the location field if:
that will allow users on a central store to manage the locations of their own assets and prevent the weirdness for assets of other store.
Great!
Is there a way we could also hide all other store assets completely unless the user had a 'National asset management' permission or something?
we'd have to create that permission first, which a step too far! ( given that this is oms central, we would need to implement user permissions in oms central which is a whole load of new work )
aha!
Ok all good - I think we can get around it by recommending they don't use OMS central for their CMS store and instead create a dummy 'National store' for national asset management (and Master Data config etc)
Related to #3753?
Tested in v2.0.0 exe
The test-cases PASS, but playing around with multiple sites setup, led me to this scenario where I can assign multiple locations (from multiple sites) to same equipment and thus issues. Can be discussed here: #3927
What went wrong? 😲
Asset Locations don't appear on the central server.
Remote site:
Central Site:
Expected behaviour 🤔
An asset's location should be visible to central server administrators
How to Reproduce 🔨
Steps to reproduce the behaviour:
Your environment 🌱