# Storing user-specific settings for OpenMRS 3.0 **URL:** \ **Category:** Development\ **Tags:** platform\ **Created:** [May 20, 2021, 5:39pm UTC](https://talk.openmrs.org/t/storing-user-specific-settings-for-openmrs-3-0/33519 "2021-05-20T17:39:11Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![burke](https://talk.openmrs.org/user_avatar/talk.openmrs.org/burke/32/17_2.png) [@burke](https://talk.openmrs.org/u/burke)\ **Post date:** [May 20, 2021, 5:39pm UTC](https://talk.openmrs.org/t/storing-user-specific-settings-for-openmrs-3-0/33519/1 "2021-05-20T17:39:12Z")
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… > [@](#): > > [**View in #microfrontend on Slack**](https://slack.com/archives/CHP5QAE5R/p1621523718036500) > > ![Dimitri_R](https://avatars.slack-edge.com/2020-03-31/1028251112881_3e2b8eb69693da8493a8_24.jpg) **@Dimitri\_R:** @Brandon\_Istenes @burke @Ian\_Bacher looks like that users will be able to star patient lists, and that’s a user-specific preference (about a given list). We could use user properties to retain that information on the backend (I think we discussed this already), but then we need to come up with conventions about how to use user properties to support user-specific preferences in O3. > > How do we go about this, TAC? Cc @grace @Nikita\_Malyschkin > > ![Ian_Bacher](https://secure.gravatar.com/avatar/26694d43ebe6c63009a05f62bcbb20cf.jpg?s=24&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0021-24.png) **@Ian\_Bacher:** Name-spaced user properties seem fine to me or at least easy from a backend perspective. > > ![grace](https://avatars.slack-edge.com/2020-06-12/1205445356592_ed269807bf89b389c738_24.jpg) **@grace:** @Ian\_Bacher do you want to discuss this with the TAC tomorrow or is it simpler than that? > > ![Ian_Bacher](https://secure.gravatar.com/avatar/26694d43ebe6c63009a05f62bcbb20cf.jpg?s=24&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0021-24.png) **@Ian\_Bacher:** Unless @burke has any objections, I don’t think there’s too much to discuss with the people who usually show-up on the TAC. Maybe this could be worked into one of the MF calls so we can discuss this and make sure it makes sense for the MF team (the problem I see with using user properties is that we essentially push a caching problem to somewhere in the MF framework). > > ![burke](https://secure.gravatar.com/avatar/3aa9bc466e63d508ceede4a7a718ed50.jpg?s=24&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0018-24.png) **@burke:** I think it might be worth summarizing in TAC. Namespacing conventions seems like a good start. Personally, I’d prefer if the API helped with those conventions (e.g., give your namespace & the property name and the API will help you store/retrieve it instead of using key/value pairs and hope every client has read & follows the conventions). Also, there may be need/expectations we can efficiently handle bulk requests for properties (e.g., fetch all properties for a given user within a given namespace). 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`](https://docs.openmrs.org/datamodel/openmrs-refapp-data-model-1.9.html#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 ---
**Author:** ![jdick](https://talk.openmrs.org/letter_avatar/jdick/32/5_5575768a8748004e209b776fc1b2916d.png) [@jdick](https://talk.openmrs.org/u/jdick)\ **Post date:** [May 26, 2021, 2:21pm UTC](https://talk.openmrs.org/t/storing-user-specific-settings-for-openmrs-3-0/33519/2 "2021-05-26T14:21:49Z")
@burke this seems like a great idea. How do you want to move this forward? ---
**Author:** ![ssmusoke](https://talk.openmrs.org/user_avatar/talk.openmrs.org/ssmusoke/32/8020_2.png) [@ssmusoke](https://talk.openmrs.org/u/ssmusoke)\ **Post date:** [May 26, 2021, 5:14pm UTC](https://talk.openmrs.org/t/storing-user-specific-settings-for-openmrs-3-0/33519/3 "2021-05-26T17:14:39Z")
> [@burke](#): > > 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` ? 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 > [@burke](#): > > 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. 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 ---
**Author:** ![tendomart](https://talk.openmrs.org/user_avatar/talk.openmrs.org/tendomart/32/6753_2.png) [@tendomart](https://talk.openmrs.org/u/tendomart)\ **Post date:** [August 27, 2021, 7:49am UTC](https://talk.openmrs.org/t/storing-user-specific-settings-for-openmrs-3-0/33519/4 "2021-08-27T07:49:17Z")
> [@burke](#): > > 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`](https://docs.openmrs.org/datamodel/openmrs-refapp-data-model-1.9.html#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` ? Created the ticket for this at [[TRUNK-6020] - OpenMRS Issues](https://issues.openmrs.org/browse/TRUNK-6020) ---
**Author:** ![dkayiwa](https://talk.openmrs.org/user_avatar/talk.openmrs.org/dkayiwa/32/179_2.png) [@dkayiwa](https://talk.openmrs.org/u/dkayiwa)\ **Post date:** [August 30, 2021, 1:29pm UTC](https://talk.openmrs.org/t/storing-user-specific-settings-for-openmrs-3-0/33519/5 "2021-08-30T13:29:07Z")
> [@burke](#): > > Refactor `user_property` to accommodate longer names and values. Cases that require longer names and values, smell like gone beyond the original purpose of user properties, and hence should probably better use something else. > [@burke](#): > > There will undoubtedly be user-patient-specific state as well (e.g., user preference for priority of conditions in the patient’s condition list) This looks like a call for another storage structure and its corresponding API. A centralised `user_patient_property` is the ideal. > [@burke](#): > > 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. Looks fair enough! > [@burke](#): > > Applications will certainly want rapid/immediate access to a subset of properties and our APIs may not currently live up to this expectation Unless you have very obviously simple optimisations, i would not address this until when it comes up as a real problem from implementations. ---
**Author:** ![burke](https://talk.openmrs.org/user_avatar/talk.openmrs.org/burke/32/17_2.png) [@burke](https://talk.openmrs.org/u/burke)\ **Post date:** [August 31, 2021, 11:29am UTC](https://talk.openmrs.org/t/storing-user-specific-settings-for-openmrs-3-0/33519/6 "2021-08-31T11:29:20Z")
> [@dkayiwa](#): > > Cases that require longer names and values, smell like gone beyond the original purpose of user properties, and hence should probably better use something else. Nowadays, especially with our frontend technology, it’s not unusual to want to store JSON as a user property. 255 chars seems overly restrictive. > [@ssmusoke](#): > > 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. Fair point. Users should not be able to read user-patient properties without “View Patient” privilege. > [@ssmusoke](#): > > maybe it would be good to define these namespaces for a specific module without the ability for clients to override them to prevent conflicts, These days, often the module _is_ the client, so we would rely on the convention of modules (including frontend modules) to provide a unique “module id” that the API could use to namespace. ---
**Author:** ![dkayiwa](https://talk.openmrs.org/user_avatar/talk.openmrs.org/dkayiwa/32/179_2.png) [@dkayiwa](https://talk.openmrs.org/u/dkayiwa)\ **Post date:** [August 31, 2021, 12:05pm UTC](https://talk.openmrs.org/t/storing-user-specific-settings-for-openmrs-3-0/33519/7 "2021-08-31T12:05:19Z")
> [@burke](#): > > Nowadays, especially with our frontend technology, it’s not unusual to want to store JSON as a user property. 255 chars seems overly restrictive. What new size values would you propose for the property and value? ---
**Author:** ![ibacher](https://talk.openmrs.org/user_avatar/talk.openmrs.org/ibacher/32/19751_2.png) [@ibacher](https://talk.openmrs.org/u/ibacher)\ **Post date:** [August 31, 2021, 1:15pm UTC](https://talk.openmrs.org/t/storing-user-specific-settings-for-openmrs-3-0/33519/8 "2021-08-31T13:15:34Z")
> [@dkayiwa](#): > > What new size values would you propose for the property and value? A simple answer would be to use the JSON data types supported by MySQL 5.7+ and Postgres 9.2+. ---
**Author:** ![burke](https://talk.openmrs.org/user_avatar/talk.openmrs.org/burke/32/17_2.png) [@burke](https://talk.openmrs.org/u/burke)\ **Post date:** [September 1, 2021, 6:24pm UTC](https://talk.openmrs.org/t/storing-user-specific-settings-for-openmrs-3-0/33519/9 "2021-09-01T18:24:31Z")
We discussed this on the [2021-09-01 Platform Team call](https://wiki.openmrs.org/x/CQFNDw#2021-2021-09-01) and came to this decision for enhancing capabilities for user properties: - Change `user_property.value` from `VARCHAR(255)` to `LONGTEXT` - Increase `user_property.property` from `VARCHAR(100)` to `VARCHAR(255)` This work is defined as: [https://issues.openmrs.org/browse/TRUNK-6020](https://issues.openmrs.org/browse/TRUNK-6020) The goal was to prevent clients from running into error from arbitrarily tight length constraints (e.g., storing a list of seven UUIDs could exceed the current 255 char limit for values). While we could migrate to JSON values in the future, we didn’t feel there was time for this with Platform 2.5 (could consider for Platform 2.6+). Since we are changing the value size, it seemed like a good time to provide a little more slack in property names (`user_property.property`), since we expect these to be namespaced and a long module ID followed by a key containing a UUID could easily push the 100 character limit. Personally, I would support moving toward having clients provide their namespace and key separately (instead of just a key, where we expect all clients to follow the same convention of namespace & key separated by a period). @tendomart will create a separate ticket (linking as related to TRUNK-6020) for creating user-patient properties. ---
**Author:** ![tendomart](https://talk.openmrs.org/user_avatar/talk.openmrs.org/tendomart/32/6753_2.png) [@tendomart](https://talk.openmrs.org/u/tendomart)\ **Post date:** [September 2, 2021, 10:00am UTC](https://talk.openmrs.org/t/storing-user-specific-settings-for-openmrs-3-0/33519/10 "2021-09-02T10:00:32Z")
We’ve got it at [https://issues.openmrs.org/browse/TRUNK-6026](https://issues.openmrs.org/browse/TRUNK-6026) ---
**Author:** ![burke](https://talk.openmrs.org/user_avatar/talk.openmrs.org/burke/32/17_2.png) [@burke](https://talk.openmrs.org/u/burke)\ **Post date:** [September 3, 2021, 12:09am UTC](https://talk.openmrs.org/t/storing-user-specific-settings-for-openmrs-3-0/33519/11 "2021-09-03T00:09:55Z")
Thanks for pulling out the user-patient properties from TRUNK-6020, @tendomart. I added a comment to [TRUNK-6026](https://issues.openmrs.org/browse/TRUNK-6026) suggesting that we make sure we have some real world examples of needing user-patient properties before working on that feature. While we can invent examples, if we don’t have real world requirements, I’d favor de-prioritizing TRUNK-6026 until we do. ---
**Author:** ![tendomart](https://talk.openmrs.org/user_avatar/talk.openmrs.org/tendomart/32/6753_2.png) [@tendomart](https://talk.openmrs.org/u/tendomart)\ **Post date:** [September 3, 2021, 2:10am UTC](https://talk.openmrs.org/t/storing-user-specific-settings-for-openmrs-3-0/33519/12 "2021-09-03T02:10:15Z")
Any implementers here with real world requirements @ssmusoke[@Mekom](https://talk.openmrs.org/groups/mekom) [@AMPATH](https://talk.openmrs.org/groups/ampath) [@PIH](https://talk.openmrs.org/groups/pih) ? ---
**Author:** ![burke](https://talk.openmrs.org/user_avatar/talk.openmrs.org/burke/32/17_2.png) [@burke](https://talk.openmrs.org/u/burke)\ **Post date:** [September 8, 2021, 5:20pm UTC](https://talk.openmrs.org/t/storing-user-specific-settings-for-openmrs-3-0/33519/13 "2021-09-08T17:20:54Z")
@grace, could we add to an upcoming OpenMRS 3.0 squad call an agenda item to simply ask “Are there any specific needs today to be able to store patient-specific settings for users?” Assuming this is an imagined need (not pressing), the Platform team will de-prioritize TRUNK-6026. The work to improve user settings is already underway. ---
**Author:** ![tendomart](https://talk.openmrs.org/user_avatar/talk.openmrs.org/tendomart/32/6753_2.png) [@tendomart](https://talk.openmrs.org/u/tendomart)\ **Post date:** [September 21, 2021, 10:17pm UTC](https://talk.openmrs.org/t/storing-user-specific-settings-for-openmrs-3-0/33519/14 "2021-09-21T22:17:06Z")
@grace did you present this to the MF squad ? And if so , did you get any feedback? ---
**Author:** ![mksd](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mksd/32/11729_2.png) [@mksd](https://talk.openmrs.org/u/mksd)\ **Post date:** [September 22, 2021, 9:38am UTC](https://talk.openmrs.org/t/storing-user-specific-settings-for-openmrs-3-0/33519/15 "2021-09-22T09:38:55Z")
@tendomart I asked a question on Slack [here](https://openmrs.slack.com/archives/GQJA12F4L/p1631688166044400?thread_ts=1631625644.043000&cid=GQJA12F4L) about it: > Is it that a `user_property` would say “on the patient chart show the allergy widget at the top”, and a `user_patient_property` could override this behaviour for a specific patient? As in “on the patient chart show the allergy widget at the top, **except for John Doe** where it should show second after the conditions widget”. If so, then I personally think this shouldn’t be prioritised as of yet, let’s get non patient-specific user customisations right first. ---
**Author:** ![tendomart](https://talk.openmrs.org/user_avatar/talk.openmrs.org/tendomart/32/6753_2.png) [@tendomart](https://talk.openmrs.org/u/tendomart)\ **Post date:** [September 22, 2021, 11:09am UTC](https://talk.openmrs.org/t/storing-user-specific-settings-for-openmrs-3-0/33519/16 "2021-09-22T11:09:18Z")
Thanks @mksd for the pointer .I actually missed out on that . ---
**Author:** ![ibacher](https://talk.openmrs.org/user_avatar/talk.openmrs.org/ibacher/32/19751_2.png) [@ibacher](https://talk.openmrs.org/u/ibacher)\ **Post date:** [September 22, 2021, 2:08pm UTC](https://talk.openmrs.org/t/storing-user-specific-settings-for-openmrs-3-0/33519/17 "2021-09-22T14:08:37Z")
> [@mksd](#): > > If so, then I personally think this shouldn’t be prioritised as of yet, let’s get non patient-specific user customisations right first. Yeah… The change we’re implementing in 2.5 is just to expand the size of the columns in the `user_property` table to allow more data to be stored as a single user property. We haven’t really gotten into the `user_patient_property` component yet. I think there’s another question of whether or not the MF squad actually wants to take advantage of that functionality yet or if the focus is on getting the basic UI right.