LP#1689608: Batch user editing

LP#1689608: Batch user editing

Summary
-------

Currently, editing and deleting of users must be performed on a user-by-user
basis. There are workflows that would benefit from the ability to act on a
set of users, where the changes to all users in the set are the same.

This commit provides 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
-------------

In order to facilitate the update of user data fields, specifically:

 * 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

This commit contains a new set of business logic allowing staff to supply new
values for these fields. Creation and immediate processing of a change set
will be made available through a grid Menu item. If the staff user does not
have the UPDATE_USER permission, this option will be disabled.

Each change set requires a name. Buckets may have multiple change sets. All
users in the Bucket at the time of processing will be updated when the change
set is processed, and change sets are processed immediately upon successful
creation. The interface will deliver progress information regarding the
processing stage and percent of completion.

While processing the users, the original value for each field edited will be
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
--------------

In order to facilitate the batch deletion of users, this commit creates a new
set of business logic allowing staff to set the Deleted flag on users.
Creation and immediate processing of a batch delete is made available through
a grid Menu item. If the staff user does not have both the UPDATE_USER and
DELETE_USER permission, this option is disabled. Because of the potential for
damage and the additional required permission, this field change is
specifically segregated from the general Editing functionally described above.

Each delete set requires a name. Buckets may have multiple delete sets. All
users in the Bucket at the time of processing will be marked as deleted when
the delete set is processed. The interface will deliver 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 will be 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. Future enhancement could add such functionality.

Editing Statistical Category Entries
------------------------------------

In order to facilitate the batch editing, addition, and removal of
Statistical Category Entries for users, this commit creates a new set of
business logic allowing staff to either remove or add & update Entries for
Statistical Categories to which the staff member has access. Processing of
Statistical Category Entry modifications will are available through a grid
Menu item.

All users in the bucket will 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.

Signed-off-by: Mike Rylander <mrylander@gmail.com>