[FOLIO-3538] User-specific preferences Created: 23/Nov/17  Updated: 11/Jul/22

Status: Draft
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P4
Reporter: Mike Taylor Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: for-next-sprint, sprint27, sprint29
Remaining Estimate: Not Specified
Time Spent: 1 hour
Original estimate: Not Specified

Issue links:
Blocks
blocks STRIPES-541 Create ui-myprofile module Closed
blocks STCOR-110 Repositionable App Icons Closed
is blocked by FOLIO-649 User-specific preferences in mod-config Closed
Duplicate
is duplicated by STRIPES-470 User-specific preferences in Stripes Closed
Relates
relates to UIP-1 Figure out UX for settings vs. prefer... Closed
relates to STSMACOM-51 Abstract out a smart component for co... Closed
relates to UIU-324 Refine User Record Layout (View) Closed
Requires
is required by UXPROD-1398 User Preferences Open
Sprint:

 Description   

We now have several requirements that need user-specific preferences to be stored and retrieved. These include:

  • Saved order of application icons ( STCOR-110 Closed )
  • User-specific locales: for Spanish-speaking students in a Texas university
  • User-specific key-bindings
  • Per-user plug preferences: one user wants an OPAC-like view of items, another wants a MARC-like view.
  • Profile pictures (part of UIU-324 Closed )

We need to figure out the best approach to storing and retrieving such information.



 Comments   
Comment by Mike Taylor [ 23/Nov/17 ]

I can see three broad approaches to storing user-specific configuration information:

1. Just keep it in the browser's local storage, using localForage – as we already do for the user's Okapi session information, so that returning to the browser will continue with the same logged-in session.
2. Store it in the user record, along with existing details such as the user's first and last name, telephone number, etc.
3. Store it in mod-configuration.

#1 is not really appropriate, because people are expected to change workstation (especially in shared-workspace environments like university libraries), and will likely switch between desktop and mobile devices, etc.

#2 is appealing in some respects, but would involve disruptive changes to the user schema, and a release cycle, every time we wanted to store some new piece of information. Also, which some information feels like it "belongs" in the user record – avatar image, for example – other information does not – stored order of application icons, for example.

#3 seems like the best, most general way to go. We already use mod-configuration to store tenant-wide information such as the default locale, so it's the obvious place to also store the user-specific override for the same information. In fact, we can implement a nice, generic mechanism for user-specific overriding of tenant-wide defaults, There are still decisions to be made about how to do this: e.g. do we want one big record in some text format, or lots of little records, one for each piece of configuration?

Comment by Mike Taylor [ 23/Nov/17 ]

The underlying requirement for user-specific preferences already exists in mod-configuration: it was added a while back in FOLIO-649 Closed . A new userId field was added to the configuration schema, which is ours to use as we wish.

We could store the username, but it's more honest to store the actual user-ID (i.e. the UUID).

At present, configuration record such as that for the tenant-level default locale are simply PUT and POSTed with no userId at all. That means the field is simply not present in the persisted representation. shale99 is looking into whether there is a way in CQL to look for field-not-present. If so, we'll have easy ways to isolate both the system-wide and user-specific versions of a configuration record.

Comment by Mike Taylor [ 23/Nov/17 ]

If It turns out that there's a good way to find records with no userId, we can use that. Otherwise, instead of simply omitted that field in tenant-wide configuration records, as we do now, we can set it to an "impossible" (non-UUID-format) value like "tenant".

Then consider the following CQL queries in mod-configuration:

1. module=ORG and configName=locale
2. module=ORG and configName=locale and userId=a1b2c3e4
3. module=ORG and configName=locale and userId=tenant
4. module=ORG and configName=locale and userId=(a1b2c3e4 or tenant)

The first is what we presently do. The second will find the record specific to the nominated user. The third will find the tenant-wide record, ignoring the many user-specific record. But the fourth is what we will actually use. It will find the record for the specific user (if it exists) and the tenant-wide record. Then, having done a single server round-trip, stripes-core can choose to use the user's override if it exists but fall back to the tenant-wide override otherwise.

Comment by Mike Taylor [ 11/Dec/17 ]

Pushed this onto the next sprint to clear the decks for ui-search in the present sprint.

Comment by Cate Boerema (Inactive) [ 05/Jan/18 ]

I'd like to hold off on development for this for now, as we haven't yet identified any must-have v1 user preferences.

Comment by Mike Taylor [ 05/Jan/18 ]

No problem – you probably saw I already pushed it down to P4, as it's distant from the Codex work that I am presently focused on.

Comment by Mike Taylor [ 01/Oct/18 ]

Zak Burke Good luck with this one: I think it'll be fun to work on.

Comment by Khalilah Gambrell [ 09/Jul/19 ]

Closing this story until feature UXPROD-1398 Open is prioritized. Added description as a comment to that feature to ensure we address.

Generated at Thu Feb 08 23:28:52 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.