From 368ecff22d8c50322beee5ac63c5d5f1bcad9541 Mon Sep 17 00:00:00 2001 From: Jane Sandberg Date: Wed, 27 Sep 2017 07:04:29 -0700 Subject: [PATCH] Docs: streamlining release notes for user buckets; adding trimmed content to the manuals Signed-off-by: Jane Sandberg Signed-off-by: Galen Charlton --- docs/RELEASE_NOTES_3_0.adoc | 34 ++--------- docs/admin/qstore_service.adoc | 6 ++ docs/circulation/user_buckets.adoc | 90 ++++++++++++++++++++++++++++++ docs/root_circulation.adoc | 6 ++ docs/root_command_line_admin.adoc | 13 ++++- docs/root_staff_client_admin.adoc | 6 ++ 6 files changed, 124 insertions(+), 31 deletions(-) create mode 100644 docs/admin/qstore_service.adoc create mode 100644 docs/circulation/user_buckets.adoc diff --git a/docs/RELEASE_NOTES_3_0.adoc b/docs/RELEASE_NOTES_3_0.adoc index b57be2cf40..267e1aad1c 100644 --- a/docs/RELEASE_NOTES_3_0.adoc +++ b/docs/RELEASE_NOTES_3_0.adoc @@ -692,12 +692,12 @@ 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 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 @@ -708,21 +708,7 @@ grid if the staff user has the UPDATE_USER permission: * 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. @@ -733,15 +719,7 @@ 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. +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. @@ -754,9 +732,7 @@ 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. +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. diff --git a/docs/admin/qstore_service.adoc b/docs/admin/qstore_service.adoc new file mode 100644 index 0000000000..cd4622e643 --- /dev/null +++ b/docs/admin/qstore_service.adoc @@ -0,0 +1,6 @@ +QStore service +-------------- + +The QStore service is used by the user buckets feature +in the Web client. + diff --git a/docs/circulation/user_buckets.adoc b/docs/circulation/user_buckets.adoc new file mode 100644 index 0000000000..d0d61b954a --- /dev/null +++ b/docs/circulation/user_buckets.adoc @@ -0,0 +1,90 @@ +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. + diff --git a/docs/root_circulation.adoc b/docs/root_circulation.adoc index d43eefdcd8..32fc0c4165 100644 --- a/docs/root_circulation.adoc +++ b/docs/root_circulation.adoc @@ -54,6 +54,12 @@ include::circulation/booking.adoc[] include::circulation/triggered_events.adoc[] +:leveloffset: 0 + +include::circulation/user_buckets.adoc[] + +:leveloffset: -1 + include::opac/using_the_public_access_catalog.adoc[] :leveloffset: 0 diff --git a/docs/root_command_line_admin.adoc b/docs/root_command_line_admin.adoc index d9dcbf14b6..b7a39a9ac0 100644 --- a/docs/root_command_line_admin.adoc +++ b/docs/root_command_line_admin.adoc @@ -52,16 +52,25 @@ Individual Evergreen Components include::development/intro_opensrf.adoc[] -include::development/pgtap.adoc[] - :leveloffset: 0 include::development/support_scripts.adoc[] include::admin/actiontriggers_process.adoc[] +Daemons and services +-------------------- + +:leveloffset: 1 + include::reports/reporter_daemon.adoc[] +include::admin/qstore_service.adoc[] + + +include::development/pgtap.adoc[] + +:leveloffset: 0 System Configuration ==================== diff --git a/docs/root_staff_client_admin.adoc b/docs/root_staff_client_admin.adoc index 3cd288eed5..6099eb27ae 100644 --- a/docs/root_staff_client_admin.adoc +++ b/docs/root_staff_client_admin.adoc @@ -150,6 +150,12 @@ Negative balances This section needs to be written +:leveloffset: 1 + +include::circulation/user_buckets.adoc[] + +:leveloffset: 0 + Circulation timesavers and workflows ------------------------------------ -- 2.43.2