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

[Benjamin Kalish]

Fantastic news!

Benjamin Kalish
Forbes Library / 413-587-1012 / bkalish at forbeslibrary.org

Support Forbes Library:

   - Consider giving a gift <http://www.forbeslibrary.org/giving> to Forbes
   Library
   - Vote for the Friends of Forbes in the Florence Bank Community Grant
   Program <https://www.florencebank.com/vote>.
   - Join the Friends the Forbes today <https://forbeslibrary.org/friends/>!


Currently reading: *War on Peace: The End of Diplomacy and the Decline of
American Influence *by Ronan Farrow
Just Finished: *Hunger: A Memoir of (My) Body *by Roxane Gay
For information about accessibility at the library, please see:
http://forbeslibrary.org/accessibility/









On Fri, Aug 3, 2018 at 2:23 PM, Bill Erickson <berickxx at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20180803/387fc80d/attachment.html>