Uploaded image for project: 'OpenMRS Core'
  1. OpenMRS Core
  2. TRUNK-6020

Add support for storing user-specific settings for OpenMRS 3.0



    • Low


      There are a growing number of examples within OpenMRS 3.0 of needing to be able to store user-specific application state.

      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?

      Gliffy Diagrams


          Issue Links



                tendomart tendo kiiza Martyn
                tendomart tendo kiiza Martyn
                0 Vote for this issue
                3 Start watching this issue