Maybe I’m mis-undertanding the functionality, but, without some sort of check, doesn’t an empty table mean “getLoginLocations” would always return null/empty list and no one could log in? Or are we saying if a particular user has no entries in the user_location table that means they have no restrictions?
(We could say “the functionality is disabled if table count == 0”. I’d be okay with that, but I think it’s a bit safer/clearer to have a global property.)
Take care,
Mark
Yes, I was assuming that no entries = no restrictions.
That seems like a fair design to me.
Just catching up on this thread. Sounds reasonable. Most of my questions/concerns have already been addressed in the thread (provider roles vs. roles, the administrative burden of managing direct user-location mappings, etc.).
I don’t really follow the allowed stuff. It seems to me like you’d want the opposite (e.g., exlude). That is, you map the user to a the location(s) for which that location and all descendants with the desired tag become options. Then you only need additional entries for exceptional cases where you want to exclude specific entries for a user (e.g., don’t show surgery room 3 for this user).
This sounds like a good option – i.e., a “search for other locations” option that can be ignored in most cases. Reality is pretty good at coming up with exceptional cases that break assumptions.
Maybe off-topic, but we might also want to consider supporting a device-based (effectively a browser-based) default location for desktops & other non-mobile devices used in a single location. For example, consider an option for user or admin to set “default location for browser”. The user still able to select from their list of locations if they choose, but if a “default for this browser” option (stored in localStorage) has been set, the location would default to this device-specific location to allow the location field to be ignored 99% of the time on devices physically associated with that location.
This is definitely on our radar as something we want to do @burke - not sure if it is ticketed anywhere
@mogoodrich, @mseaton, sorry for being quiet. I’m back now and have already started working on this in our custom module this week, with the goal of moving it to Core. Should I create the JIRA ticket, or is there anything else I should consider first?