Details
-
New Feature
-
Status: Closed
-
Should
-
Resolution: Fixed
-
Platform 2.4.0
-
Low
Description
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
Attachments
Issue Links
- is related to
-
TRUNK-6026 Add Support for creating for user_patient_property into OpenMRS Data Model
-
- Closed
-
- links to
- mentioned in
-
Page Loading...