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

Bug #1735566 reported by Kathy Lussier on 2017-11-30
98
This bug affects 21 people
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned
3.3
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
Robert J Jackson (rjackson) 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) on 2019-04-24
tags: added: delete
tags: removed: delete
Christopher Burton (cburton) wrote :

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

Eva Cerninakova (ece) wrote :

He have this issue too, in the Evergreen 3.3.2

Jane Sandberg (sandbej) on 2019-08-20
Changed in evergreen:
assignee: nobody → Jane Sandberg (sandbej)
Jane Sandberg (sandbej) 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
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
Rogan Hamby (rogan-hamby) wrote :

Works as advertised.

2nd signoff pushed to user/rogan/lp1735566_non_ideal_status_for_deleting_signoff

Bill Erickson (berick) on 2020-01-21
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Bill Erickson (berick) wrote :

For Angular: bug #1860460.

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  Edit
Everyone can see this information.

Other bug subscribers