More granular permissions for deleting items/bibs
In Polaris, a single delete of a bib/item record will result in that record being 'marked for deletion.' It is no longer visible in the PAC, but is still visible in Polaris with a Deleted status. Deleting a record in Deleted status, or what we've termed 'double-delete,' will result in the record being fully purged from the database.
Sometimes, staff will delete a record and go back to it to verify the deletion. They see it's still visible in Polaris (missing the Deleted status) and delete it a second time. This accidental purging results in no longer being able to 'undelete' the record or pull circ statistics if needed. As a consortium with a shared database, this is problematic.
Currently, there is only one permission responsible for the ability to delete and purge records. We would like separate permissions for deleting records and purging records to help curb accidental purging.
Nicole M.
shared this idea
-
Phil Agnew
commented
There are a few different permissions that I think should have more granular configuration, but this is the biggest one. There is a major difference between "Marked for deletion" and "Removed from the database" and the fact that there isn't a way to assign those permissions separately is... problematic. Furthermore, there isn't even much visual distinction between the two actions, leading to those accidental "double delete" actions others have described. It would be helpful if, at the very least, the text in the action menu changed from "Delete" to "Remove from database" for items that have already been "Marked for deletion" (RecordStatusID = 4).
But separate permissions would be best. Case and point, I had a branch manager call me after approving a weeding record set because they changed their mind about one of the items on the list. Because they didn't have the Delete/Undelete Item records permission, they were unable to add it back into the collection. If there were separate permissions for the initial Delete/Undelete action and the second Delete/Purge action, I wouldn't have any concerns or reservations over allowing a broader group of staff to have access to that first permission, which would have prevented this problem from ever occurring.
Fortunately, it appears the Delete/Undelete Item Records permission applies to Bulk Change actions, so we can effectively prevent staff from purging a large amount of items... but only if we don't allow access to the Delete/Undelete permission. On the other hand, any staff with access to the Delete/Undelete permissions have the potential to perform highly destructive, irreversible damage to database records on a large scale... Granted it requires more intentional actions and a higher degree of technical expertise to execute, but the scope is much broader. Hypothetically, if a staff member has both the Delete/Undelete Item Records and Bulk Change Item Records, there is nothing preventing them from purging every item record in the database, except perhaps a couple alerts for "Last copy" or other configured item deletion blocks... I mention this only to express the significance of separating the Delete/Purge permissions.
-
Catherine Eilers
commented
Staff accidentally "double deleting" causes problems for us because (as I understand it) those items don't go through our consortium's process to have our OCLC holdings removed.
-
C Mulder
commented
We would also find this useful. We have our page staff delete weeded item records and they will accidentally double delete a record set of items, which causes issues for our weeding tracking and stats.
-
It would be helpful to have these permissions separated. We currently discourage library staff from deleting at all except where a record was created in error. Instead, we update items to deleted if they have been withdrawn/lost/missing for a certain amount of time.
