Storing user-specific settings for OpenMRS 3.0

There are a growing number of examples within OpenMRS 3.0 of needing to be able to store user-specific application state. Here’s a recent example in Slack…

The current default approach is to use user_property with namespaced property names. This may work for simple cases, but faces a few challenges:

  • user_property currently limits property name to 100 chars and values to 255 chars
  • Applications will certainly want rapid/immediate access to a subset of properties and our APIs may not currently live up to this expectation
  • There will undoubtedly be user-patient-specific state as well (e.g., user preference for priority of conditions in the patient’s condition list)

While we can propose a convention for namespacing user property names, I would suggest we go a little further:

  • Refactor user_property to accommodate longer names and values.
  • Support separate namespace & property names so, for example, an application can say “I’m com.acme.foobar and I need [to set] my baz property for this user” allowing the API to manage how namespacing is handled rather than leaving it up to all clients to property follow a convention.
  • Come up with a plan for handling user-patient-specific state. Do we build this in on a case-by-case basis? Or do we create a centralized user_patient_property?

/cc @mksd @ibacher @grace @jdick @mseaton

1 Like

@burke this seems like a great idea. How do you want to move this forward?

I would suggest also including the ability to add access checks for the user->patient access, in case it is revoked between when the property is saved and the next access.

Maybe also setting a maximum number, pruning rules - after a period time, or a number of patients as this can grow exponentially large and slow down the views

Not being a member of the MF squad maybe it would be good to define these namespaces for a specific module without the ability for clients to override them to prevent conflicts, overwrites and clashes - even determine how to clean up orphaned configurations