LP#1689608: add release notes

Signed-off-by: Galen Charlton <gmc@equinoxinitiative.org>

diff --git a/docs/RELEASE_NOTES_NEXT/Circulation/Batch_User_Editing.adoc b/docs/RELEASE_NOTES_NEXT/Circulation/Batch_User_Editing.adoc
new file mode 100644 (file)
index 0000000..c4245d0
--- /dev/null
+++ b/docs/RELEASE_NOTES_NEXT/Circulation/Batch_User_Editing.adoc
@@ -0,0 +1,86 @@
+Batch Editing of Patron Records
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+There is a now a new interface analogous to the Copy Bucket interface
+to record the selection and grouping of a set of users into a User Bucket.
+The addition of users to a User Bucket is possible from the Patron Search
+interface by the use of a new grid Action, and directly on the User Bucket
+interface by user barcode. It is also possible to add users by uploading
+a text file that contains a list of user barcodes.
+
+From this interface it is possible to perform a set of specific batch update
+operations against users generally.
+
+Editing users
++++++++++++++
+
+The fields can now be changed in batch via an action on the User Bucket
+grid if the staff user has the UPDATE_USER permission:
+
+ * Active flag
+ * Primary Permission Group (group application permissions consulted)
+ * Juvenile flag
+ * Home Library (UPDATE_USER checked against both old and new value)
+ * Privilege Expiration Date
+ * Barred flag (BAR_PATRON permission consulted)
+ * Internet Access Level
+
+Each change set requires a name. Buckets may have multiple change sets. All
+users in the Bucket at the time of processing are updated when the change
+set is processed, and change sets are processed immediately upon successful
+creation. The interface delivers progress information regarding the
+processing stage and percent of completion.
+
+While processing the users, the original value for each field edited is
+recorded for potential future rollback. Users can examine the success and
+failure of applied change sets.
+
+The user will be able to rollback the entire change set, but not parts thereof.
+The rollback will affect only those users that were successfully updated by the
+original change set and may be different from the current set of users in the
+Bucket. Users can manually discard change sets, removing them from the
+interface but preventing future rollback.
+
+As a batch process, rather than a direct edit, this mechanism explicitly skips
+processing of Action/Trigger event definitions for user update.
+
+Deleting users
+++++++++++++++
+
+The batch edit mechanism also allows for the batch deletion of user.  The staff
+user must have both the UPDATE_USER and DELETE_USER permissions.
+
+Each delete set requires a name. Buckets may have multiple delete sets. All
+users in the Bucket at the time of processing are marked as deleted when
+the delete set is processed. The interface delivers progress information
+regarding the processing stage and percent of completion.
+
+While processing the users, the original value for the "deleted" field will be
+recorded for potential future rollback. Users are able to examine the
+success and failure of applied delete sets in the same interface used for the
+above described change sets.
+
+As a batch process, rather than a direct edit, this mechanism explicitly skips
+processing of Action/Trigger event definitions for user deletion.
+
+This mechanism does not use the Purge User functionality, but instead simply
+marks the users as deleted.
+
+Editing Statistical Category Entries
+++++++++++++++++++++++++++++++++++++
+
+All users in the bucket can have their Statistical Category Entries
+modified. Unlike user data field updates, modification of Statistical
+Category Entries is permanent and cannot be rolled back. No named change
+sets are required. The interface will deliver progress information regarding
+the processing stage and percent of completion.
+
+As a batch process, rather than a direct edit, this mechanism explicitly skips
+processing of Action/Trigger event definitions for user update.
+
+New service requirement
++++++++++++++++++++++++
+
+This new functionality makes use of the QStore service, which was previously
+unused in production.  If this service has been removed from the configuration
+of a live Evergreen instances, it will need to be added back in order for
+batch user editing to succeed.