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

Bill Erickson berickxx at gmail.com
Fri Aug 3 14:23:14 EDT 2018


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-dev/attachments/20180803/dfee7df4/attachment.html>


More information about the Open-ils-dev mailing list