Hi Bill,

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.


Can we assume the opposite is true too? While testing, I was thinking that
some sites may prefer the copy templates to be a workstation setting
instead of a user setting.

Thanks for your work on this!

Kathy

-- 
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128kluss...@masslnc.org


On Fri, Aug 3, 2018 at 2:23 PM, Bill Erickson <beric...@gmail.com> 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
>
>
>

Reply via email to