docs/RELEASE_NOTES_NEXT/Circulation/Batch_User_Editing.adoc

   1 Batch Editing of Patron Records
   2 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   3 There is a now a new interface analogous to the Copy Bucket interface
   4 to record the selection and grouping of a set of users into a User Bucket.
   5 The addition of users to a User Bucket is possible from the Patron Search
   6 interface by the use of a new grid Action, and directly on the User Bucket
   7 interface by user barcode. It is also possible to add users by uploading
   8 a text file that contains a list of user barcodes.
   9
  10 From this interface it is possible to perform a set of specific batch update
  11 operations against users generally.
  12
  13 Editing users
  14 +++++++++++++
  15
  16 The fields can now be changed in batch via an action on the User Bucket
  17 grid if the staff user has the UPDATE_USER permission:
  18
  19  * Active flag
  20  * Primary Permission Group (group application permissions consulted)
  21  * Juvenile flag
  22  * Home Library (UPDATE_USER checked against both old and new value)
  23  * Privilege Expiration Date
  24  * Barred flag (BAR_PATRON permission consulted)
  25  * Internet Access Level
  26
  27 Each change set requires a name. Buckets may have multiple change sets. All
  28 users in the Bucket at the time of processing are updated when the change
  29 set is processed, and change sets are processed immediately upon successful
  30 creation. The interface delivers progress information regarding the
  31 processing stage and percent of completion.
  32
  33 While processing the users, the original value for each field edited is
  34 recorded for potential future rollback. Users can examine the success and
  35 failure of applied change sets.
  36
  37 The user will be able to rollback the entire change set, but not parts thereof.
  38 The rollback will affect only those users that were successfully updated by the
  39 original change set and may be different from the current set of users in the
  40 Bucket. Users can manually discard change sets, removing them from the
  41 interface but preventing future rollback.
  42
  43 As a batch process, rather than a direct edit, this mechanism explicitly skips
  44 processing of Action/Trigger event definitions for user update.
  45
  46 Deleting users
  47 ++++++++++++++
  48
  49 The batch edit mechanism also allows for the batch deletion of user.  The staff
  50 user must have both the UPDATE_USER and DELETE_USER permissions.
  51
  52 Each delete set requires a name. Buckets may have multiple delete sets. All
  53 users in the Bucket at the time of processing are marked as deleted when
  54 the delete set is processed. The interface delivers progress information
  55 regarding the processing stage and percent of completion.
  56
  57 While processing the users, the original value for the "deleted" field will be
  58 recorded for potential future rollback. Users are able to examine the
  59 success and failure of applied delete sets in the same interface used for the
  60 above described change sets.
  61
  62 As a batch process, rather than a direct edit, this mechanism explicitly skips
  63 processing of Action/Trigger event definitions for user deletion.
  64
  65 This mechanism does not use the Purge User functionality, but instead simply
  66 marks the users as deleted.
  67
  68 Editing Statistical Category Entries
  69 ++++++++++++++++++++++++++++++++++++
  70
  71 All users in the bucket can have their Statistical Category Entries
  72 modified. Unlike user data field updates, modification of Statistical
  73 Category Entries is permanent and cannot be rolled back. No named change
  74 sets are required. The interface will deliver progress information regarding
  75 the processing stage and percent of completion.
  76
  77 As a batch process, rather than a direct edit, this mechanism explicitly skips
  78 processing of Action/Trigger event definitions for user update.
  79
  80 New service requirement
  81 +++++++++++++++++++++++
  82
  83 This new functionality makes use of the QStore service, which was previously
  84 unused in production.  If this service has been removed from the configuration
  85 of a live Evergreen instances, it will need to be added back in order for
  86 batch user editing to succeed.