Comment 9 for bug 1750894

I've pushed a few more commits to the working branch. Here's what I have so far.

1. We have workstation settings, similar to user and org unit settings.

2. We have an API that returns the best value for a setting, be it user, workstation, or org unit, depending on the context and local configuration.

3. We have an API that can apply a value to a user or workstation setting depending on local configuration.

Applying org unit settings is unchanged. The existing user settings get/set API is also unchanged for backwards compatibility and for user settings that will only ever be user-only settings.

4. The browser client (via hatch.js) is now able to get and set server-stored settings using the above APIs.

5. I've created enough sample data to move the workstation settings from the browser client checkin UI to the server. (e.g. Ignore Precataloged Items, Suppress Holds and Transits, etc.)

For now, and possibly as a part of the migration strategy, the settings that are supported on the server are hard-coded in Hatch. Until we have all settings supported/migrated on the server, this will likely be necessary to avoid chaos in the browser client.

===

TODO:

1. Create workstation settings for needed browser values. Most values set via hatch.setItem() will need a corresponding workstation setting.

* For consistency with the existing browser client code, I'm assuming we want to migrate existing browser values as workstation settings. However, sites will have the option to change setting types to user and/or org unit settings depending on the desired behavior.

2. Migration plan. At some point, the browser has to send all of its locally stored settings to the server and delete the local copies. We'll need a way to reliably indicate when it's happened so we don't repeat the process. Maybe we track the "has migrated" status with a new workstation setting.

3. Applying values to org unit settings will have to be done on a per-interface basis and it will depend on what permissions a user has and whether an org unit setting type exists for a given setting. At least for storing grid settings, though, we can build a grid widget for handling all of the grids. May want to do this as a follow-up bug once this bug is merged.

3. I suspect that removal of Hatch storage features will have to be a separate bug also, targeting one release after this code is merged.