Currently, one can manually deactivate user accounts as needed (e.g. if a staff member leaves the organization). UCSF will soon be working on the ability to auto-deactivate OpenMRS EMR User Accounts based on certain criteria - but we need your help to know what criteria would be helpful!
So far the 2 main use cases we’ve heard are:
Inactive Users: e.g. after XX days of inactivity (60? 90? …?) (from CDC, due to concerns about users potentially accessing records inappropriately)
Demo Users: e.g. Users on a demo server for a short time (2 days), then deactivate that account automatically (from @ningosihere)
W.r.t. implementaiton, we imagine the deactivation could be a task leveraging the scheduler, calling the API in the same way that the manual deactivation does. Implementations should be able to inject rules about how/when exactly the task runs, in case they need to customize this.
Soon we will have a joint requirements call with CDC and UCSF about this, and community members will be welcome to join too.
We haven’t run into it, but seems like something we might use… a task that deactivated users after x days of inactivity (where x is a configurable parameter, perhaps a global property) seems useable… obviously, we’d want this to be an “opt-in” feature, not something that gets turned on by default.
I assume inactivity will be determined by the last login date, and in which case we would need to store some sort of user_property for the last login date for each successful login.
+1 Mark, good call. CDC might want the OHRI package to come with a default, enabled parameter of a certain # of days, but agreed that configurable length is a wise design for implementations. Some sites are probably more nuanced than others, e.g. where staff turnover is high vs low etc.
Thanks Daniel - TBH I assumed we had something like that already. Sounds like we’d need to get that added to the core ASAP. FYI @eudson & @alaboso - this would impact OHRI sites w.r.t. their Platform version #. @dkayiwa@burke@ibacher are there any alternative, currently supported data elements we could use instead, or as a proxy? I guess we wouldn’t want to use something like a particular page being viewed (like the O3 home page for example) because that could be worked around by logging into the legacy admin page or something like that.
The authentication module that @mseaton recently created provides additional authentication logging, including tracking user logins, so that is something that might be leveraged.
Tracking the last login time would be a nice addition to core. Ideally, this timestamp would get updated whenever a user authenticates through any mechanism (whether directly logging in or using an API).
Could we introduce a user lastLoginTime with a path to evolve it to a first-class users.last_login_time on the users table supported by core? For example, something like:
Introduce a method to get user’s last login time via a module that uses a user property strategy for now.
Add users.last_login_time to core and start adding support for it – e.g., User.getLastLoginTime()
Switch the module to use the new core feature and mark the module’s method as deprecated, encouraging use of User.getLastLoginTime() going forward.
Auto-deactivating users would be best done from a module – e.g., a module that comes with a schedule task that intermittently (daily or a few times a day) scans for inactive accounts and disables them.
You’d probably want an exception for admin accounts (to avoid getting locked out of your system)
Assuming we don’t have a built-in approach for tagging demo user accounts, the module could use a user property or be configurable to identify demo accounts (e.g., any user account with the family name “Test Acccount”, a username starting with “test-”, or a system ID in the form “9-1”, “99-2”, “999-3”, etc.).
This is great! So, the module could include alert system prior to the auto deactivation of account(s). Here is a use case.
An admin receives alerts (email or onscreen alert) about accounts that would be deactivated in XX number of days. Admin user would either take steps to contact the user(s) or allow the auto process to run.
There are instances where a staff gets a temporal transfer/deployed to another work location for certain number of days before returning back to primary health facility, such account shouldn’t be deactivated to avoid creating more work for tech support guys.