From: Bill Erickson <berickxx@gmail.com>
Date: Tue, 29 May 2018 15:47:16 +0000 (-0400)
Subject: LP#1750894 Workstation/Cascade settings Release Notes
X-Git-Url: https://old-git.evergreen-ils.org/?a=commitdiff_plain;h=7790968d6410a3de13ed606150b61f148f96b2bc;p=contrib%2FConifer.git

LP#1750894 Workstation/Cascade settings Release Notes

Signed-off-by: Bill Erickson <berickxx@gmail.com>
Signed-off-by: Kathy Lussier <klussier@masslnc.org>
---

diff --git a/docs/RELEASE_NOTES_NEXT/Client/workstation-server-settings.adoc b/docs/RELEASE_NOTES_NEXT/Client/workstation-server-settings.adoc
new file mode 100644
index 0000000000..94855df792
--- /dev/null
+++ b/docs/RELEASE_NOTES_NEXT/Client/workstation-server-settings.adoc
@@ -0,0 +1,63 @@
+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.
+
+