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

[Bill Erickson]

On Fri, Aug 3, 2018 at 3:13 PM Kathy Lussier  wrote:

> 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.
>

Yes, with minor code changes.

The code that's loading the copy templates is specifically requesting user
setting values.  If that code were changed to use the new
user-or-workstation-or-yaous API, the existing user setting could be
migrated to a workstation setting.  Ditto the code that applies the values.

Generally speaking, we now have:

1. API to set and get user setting values
2. API to get and get org unit setting values
3. NEW API to get org-or-user-or-workstation setting values, depending on
configuration, context, and available data.
4. NEW API to set user-or-workstation setting values,  depending on
configuration.

I generally refer to the new stuff (#3 and #4) as Cascade Settings.  Any
existing user or org unit setting can be used as a Cascade Setting, if the
caller simply uses the new APIs to manage the code.  (Though, only user and
workstation settings can have values applied via the new API).

-b

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

[Kathy Lussier]

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  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
>
>
>

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

[Benjamin Kalish]

Fantastic news!

Benjamin Kalish
Forbes Library / 413-587-1012 / bkal...@forbeslibrary.org

Support Forbes Library:

   - Consider giving a gift  to Forbes
   Library
   - Vote for the Friends of Forbes in the Florence Bank Community Grant
   Program .
   - Join the Friends the Forbes today !


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  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
>
>
>