Bucket 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.
+operations on user records.
Editing users
+++++++++++++
-The fields can now be changed in batch via an action on the User Bucket
+These 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
* 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.
+Changes made in this interface can be rolled back.
As a batch process, rather than a direct edit, this mechanism explicitly skips
processing of Action/Trigger event definitions for user update.
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.
+Changes made in this interface can be rolled back.
As a batch process, rather than a direct edit, this mechanism explicitly skips
processing of Action/Trigger event definitions for user deletion.
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.
+Category Entries is permanent and cannot be rolled back.
As a batch process, rather than a direct edit, this mechanism explicitly skips
processing of Action/Trigger event definitions for user update.
--- /dev/null
+User buckets
+============
+
+Introduction
+------------
+indexterm:[patron buckets]
+indexterm:[patrons, batch operations]
+
+You can select and group a set of users into a User Bucket.
+You can add users to a User Bucket from the Patron Search
+interface or directly from the User Bucket interface by user barcode.
+It is also possible to add users to a User
+Bucket 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 on the group of users you have identified.
+
+Editing users
+-------------
+indexterm:[batch edit, patrons]
+
+You can change the following fields in batch:
+
+ * Active flag
+ * Primary Permission Group (group application permissions consulted)
+ * Juvenile flag
+ * Home Library (if you have the UPDATE_USER permission for both the original and destination libraries)
+ * Privilege Expiration Date
+ * Barred flag (if you have the BAR_PATRON permission)
+ * Internet Access Level
+
+NOTE: You will need the UPDATE_USER permission.
+
+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, so users will
+not receive any notifications that they might otherwise receive when their accounts
+are edited.
+
+Deleting users
+--------------
+indexterm:[batch delete, patrons]
+
+You may also delete users as a batch.
+
+NOTE: You will need 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 completely purge the user from the database. User data
+will still be available to system administrators with database access.
+
+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.
+
projects / Evergreen.git / commitdiff