Comment 5 for bug 1750894

Hey, Mike. Thanks for the reply. "Settings" definitely doesn't capture it...

The key concern for this bug is all the data that may be saved in the browser client that are only persisted in-browser (or Hatch), primarily in localStorage, sessionStorage, and Hatch files. It is a smorgasbord of settings (sticky boxes, grid columns, etc.) and other stuff (modified print templates, etc.).

Many of these data could be persisted using existing mechanisms (org / user settings), but there are 2 new features that don't exist today: settings that follow a workstation and multi-home/cascading values (e.g. try user value first, then try tree-aware org value).

I share your concern about adding Yet Another Settings Container. And arguably some existing user settings could benefit from cascading support. So maybe we should make those tables smarter...

For the sake of discussion, I'll make a dev proposal. This is the more ambitious version.

1. Add a new actor.workstation_setting table, analogous to user_setting/org_unit_setting.

2. Add a new meta settings type table config.setting_type which absorbs and replaces config.org_unit_setting_type and config.user_setting_type (and a theoretical config.workstation_setting_type).

It contains the master list of all settings and it defines which storage options (org/user/workstation) are available to each.