[OPEN-ILS-DEV] 3.2 Notes on browser client settings moving to server

[Blake Henderson]

And there was much rejoicing!

-Blake-
Conducting Magic
MOBIUS

On 8/3/2018 1:23 PM, Bill Erickson wrote:
> Hi All,
>
> With special thanks to Kathy Lussier (and Chris Sharp), 
> https://bugs.launchpad.net/evergreen/+bug/1750894 was merged to master 
> today.  This change moves persistent browser client preferences / 
> settings out of the browser (localStorage / Hatch) to the server.  
> With this, preferences and settings will persist across browser 
> sessions and be shareable across multiple browsers.  Clearing 
> localStorage will no longer delete preference values.
>
> This code will impact administration and development of new features.  
> I wanted to review some of those here since it might impact active 
> development.
>
> Developers
>
> 1. New browser client settings/preferences that should persist across 
> browser sessions require a DB upgrade script to add the needed rows to 
> config.worksation_setting_type.
>
> 2. Settings that should only be stored locally (e.g. last retrieved 
> patron) should be stored using hatch.setLocalItem / getLocalItem or 
> the key prefix should be added to the list of special prefixes in 
> hatch.js => service.browserOnlyPrefixes.
>
> 3. Beware that storing preferences on the server means more API calls 
> are needed to load the data.  Whenever possible, make use of the 
> hatch.getItemBatch call to condense lookups into fewer API calls.
>
> Admins
>
> 1. Migration from browser storage to server storage should happen 
> seamlessly as each setting is accessed using the new code.
>
> 2. A workstation setting can be turned into a user setting by creating 
> a matching user setting type (same setting name) and removing the 
> workstation setting type.  Such settings will follow the logged user 
> account instead of the workstation.
>
> 3. No setting can be both a workstation and user setting. They are 
> mutually exclusive.
>
> 4. Org settings with the same name as a user/workstation setting act 
> as a fall-through value.
>
> 5. Org setting types that match a browser preference/setting where no 
> user/workstation setting type exists (or has been deleted) act as a 
> read-only configuration for the setting.  This can be useful, for 
> example, for applying a grid display configuration that cannot be 
> changed by staff.
>
> There are more UI improvements to make for this feature, especially 
> for managing org unit settings, but I wanted everyone to be aware the 
> pieces are in place to do these things on the back-end.
>
> -b
>
>