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
