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