--- /dev/null
+Browser Client Settings & Preferences Stored on the Server
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Browser cilent settings and preferences that should persist over time are
+now stored as settings on the server. This allows settings to follow
+users and workstations and reduces problems associated with losing settings
+as a result of clearing browser data.
+
+The browser client honors setting values stored as user settings, workstation
+settings, and org unit settings, depending on which setting types are
+locally configured.
+
+Setting Types
++++++++++++++
+
+* No setting can be both a user and workstation setting. They are mutually
+ exclusive.
+* Any setting can be an org unit setting in addition to being a user or
+ workstaion setting.
+
+Read-Only Settings
+++++++++++++++++++
+
+Read-only settings are useful for defining values that staff can use but
+not modify. For example, admins may wish to prevent users from locally
+modifying the grid configuration for a given interface so it remains
+consistent for all users.
+
+A setting is read-only when an org unit setting type exists (regardless of
+whether a value is applied) and no user or workstation setting type exists.
+
+Upgrade Notes
++++++++++++++
+
+A new permission APPLY_WORKSTATION_SETTING has been added to control who
+may apply values to workstation settings. Use something like the following
+to apply the permission to all staff accounts (mileage may vary):
+
+[source,sh]
+--------------------------------------------------------------------------
+INSERT INTO permission.grp_perm_map (grp, perm, depth)
+VALUES (
+ (SELECT id FROM permission.grp_tree WHERE name = 'Staff'), -- name may vary
+ (SELECT id FROM permission.perm_list WHERE code = 'APPLY_WORKSTATION_SETTING'),
+ 0 -- or 1, 2, etc.
+);
+--------------------------------------------------------------------------
+
+Workstation setting types matching values previously stored in the browser
+(via localStorage or Hatch) are created as part of this feature. During
+upgrade, admins should consider whether any of these new setting types
+should be transferred to user and/or org unit settings instead. Setting
+type changes can be made at any time, but when a setting type is deleted
+all of its data is deleted, so a change in type means re-applying the
+settings in the browser client.
+
+Values stored in the browser will automatically migrate to server settings
+as each setting is accessed in the browser client. Once migrated, the
+in-browser copies are deleted.
+
+If a setting type does not exist where the browser expects one, the
+value is stored in-browser instead and a warning is issued in the console.
+
+