web client: Can delete copy that is not in ideal status without warning

Bug #1735566 reported by Kathy Lussier
110
This bug affects 24 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Medium
Unassigned
3.3
Fix Released
Undecided
Unassigned

Bug Description

Evergreen version: master

In certain web client interfaces, a user with COPY_DELETE_WARNING.override can delete a copy whose status has restrict_copy_delete set to true without any warning. If the user does not have permission to override this warning, they get a message that doesn't clearly indicate what is preventing the deletion.

For users that have the aforementioned permission, if they attempt to delete an item with a checked out status, for example, from the item status interface or the holdings view interface, the item will delete without a warning prompt. In the xul client, this user would get a prompt that says 'the copy in question is not in an ideal status for deleting.' The user then needs to force the action to proceed.

This prompt does appear in the web client copy bucket interface.

For users that do not have the aforementioned permission, the prompt they receive says 'Permission Denied: COPY_DELETE_WARNING.override. Another staff member with the above permission may authorize this specific action. Please notify your library administrator if you need this permission. If you feel you have received this exception in error, please inform your friendly Evergreen developers or helpdesk staff of the above permission.'

This message doesn't clearly convey why the copy cannot be deleted, leading to a situation where an administrator may decide to override the message without realizing they are deleting an item that is in precarious status.

The web client copy buckets interface has a clear warning prompt for users who do and do not have the permission to override this block. This prompt should be employed in the item status and holdings view interfaces as well as any other interfaces where copies can be deleted.

Changed in evergreen:
status: New → Confirmed
Revision history for this message
Robert J Jackson (rjackson-deactivatedaccount) wrote :

Confirming that this is still an issue on 3.2 version running at Evergreen Indiana. Staff without the COPY_DELETE_WARNING.override are prompted to attempt with another account that might have this permission without explanation as to the root cause.

Andrea Neiman (aneiman)
tags: added: delete
tags: removed: delete
Revision history for this message
Christopher Burton (cburton) wrote :

We also have this issue that staff have asked for a solution. Hoping one is coming

Revision history for this message
Eva Cerninakova (ece) wrote :

He have this issue too, in the Evergreen 3.3.2

Changed in evergreen:
assignee: nobody → Jane Sandberg (sandbej)
Revision history for this message
Jane Sandberg (sandbergja) wrote :

Here is a branch that resolves this for AngularJS (note that the Angular experimental catalog will also need a similar fix): user/sandbergja/lp1735566_delete_copy_not_ideal_status

Here is a link: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/sandbergja/lp1735566_delete_copy_not_ideal_status

And here are the testing notes from the commit message:

1) Apply this commit.
2) Log in as a user with COPY_DELETE_WARNING.override permission.
3) Go to item status and scan an item in a non-ideal status (like #1:
checked out)
4) Delete the item. Note that you are alerted of the item's non-ideal
status, and you can confirm that you actually want to delete it.
5) Repeat steps 3-4 with an item in an ideal status (like #0:
Available). Note that no such alert appears.
6) Open the holdings view and repeat steps 4-5.
7) Log in as a user without the COPY_DELETE_WARNING.override
permission. Note that you are still informed about the non-ideal status,
but you aren't able to continue with the deletion without an admin
using their credentials.

Changed in evergreen:
assignee: Jane Sandberg (sandbej) → nobody
tags: added: cataloging pullrequest
Revision history for this message
Garry Collum (gcollum) wrote :

Tested with an item that was checked-out and one that was in-transit. Works as advertised. Signed-off at https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gcollum/lp1735566_deleted_copy_not_ideal-signoff

tags: added: signedoff
Revision history for this message
Rogan Hamby (rogan-hamby) wrote :

Works as advertised.

2nd signoff pushed to user/rogan/lp1735566_non_ideal_status_for_deleting_signoff

Bill Erickson (berick)
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Revision history for this message
Bill Erickson (berick) wrote :

For Angular: bug #1860460.

Revision history for this message
Bill Erickson (berick) wrote :

Issue and fix confirmed. Thanks, All! I've merged to 3.3 and up.

Changed in evergreen:
milestone: none → 3.4.2
assignee: Bill Erickson (berick) → nobody
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.