No warning for Delete All from Catalog in Copy Buckets

[Sarah Childs]

Evergreen Indiana 2.1

When you use the Delete All from Catalog button in Copy Buckets, the items in the bucket are deleted immediately without a warning message. Deleting items from the Holdings Maintenance screen or Item Status screen causes a message to pop up that asks if you're sure you want to delete the items, requiring you to click OK to continue or Cancel to abort.

This is really needed in Copy Buckets as well, especially since this action deletes all the items in the bucket. You could accidentally delete 100s of items, (or um, 18 items, ahem) from the catalog with a single errant click.

[Sarah Childs (sarahc)]

Just curious why the priority was downgraded?

[Jason Stephenson (jstephenson)]

It is not a bug as in broken functionality. It is a request to have a feature added, the warning when deleting all copies in a bucket. Therefore it is a wishlist item.

[Ben Shum (bshum)]

This is not a security bug, still just a wishlist for new feature.

[Elizabeth Thomsen (et-8)]

Sorry -- I must have marked this one as a security issue by accident when I was subscribing to it.

[Sarah Childs (sarahc)]

As I recall, Elizabeth, you marked it as a security issue to draw attention to how serious a potential problem this is for catalogers, that it is possible to accidentally delete 100s or even 1000s of items without even noticing.

Not only is there no "are you sure you want to delete message", as there is for every other delete item function, there is no message that tells you the items have been deleted, so you could accidentally click the button and not even realize it until items showed up as not in catalog.

Since the other delete functions in the cataloging module provide an are you sure message and an items delete message, it creates an expectation of how delete will work across the board, which makes this seem a bug, not a wishlist item. I can't think of a reason why it would be desirable for delete to work differently in this one instance, and in fact since you're dealing with multiple items, it's even more desirable for there to be a warnings for this.

This is as a good example of why catalogers tend to feel like our problems are ignored.

[Elizabeth Thomsen (et-8)]

Sorry, Sarah, I don't remember marking this as a security issue (I don't think I even know how to do that) and assumed I did it accidentally.

I suppose this is a matter of semantics -- does Security here mean that the system is vulnerable to someone maliciously accessing data or making changes or otherwise cause problems, or does it include situations like this one, where a simple accident by a staff member can have major, unintended consequences?

As a cataloger who supervises catalogers, I certainly do see this as a request for a "feature" that's really a fix for a design flaw, and I see it as a high-priority item. Every "delete" should have a warning (and better yet, an UNDO option) but it's especially important here where the user may be working with a large number of items and may also be confusing DELETE and REMOVE, a common error in bucket situations.

[Joe Atzberger (ohiocore)]

Right, this is a semantic difference. The feature is working as designed, it just isn't exactly what you want.

It would be a bug if you clicked "add" and it deleted all your items. It would be a security bug if you clicked "delete" and it deleted *someone else's* items. Your comments about interface consistency are valid criticisms, but of a different scope and severity than expected for security bugs. The problem is not being ignored, it is being reclassified from the (private) security category to the proper public desired feature category, thus increasing the chances that someone will work on it.

[Pasi Kallinen (paxed)]

Here's a quickly hacked fix, it shows a popup confirmation dialog when the button is pressed: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/paxed/delete-all-confirmation

[Jason Etheridge (phasefx)]

I'm in favor of reworking how that interface handles "batch" actions altogether, given how some folks want to do non-batch actions on bucket contents. I've never been quite happy with it.

A quick "fix" in the meantime would be to remove the DELETE_COPY permission, and give it to a more restricted account. The client will prompt for the credentials when such an action is attempted without the permission. That has the side-effect of adding even more speedbumps to copy deletion elsewhere.

A more general strategy in the long run may be to have settings that can throw overridable event "speedbumps" for any action, but have them be "weaker" than permission denied events. Then folks can configure warning dialogs for whatever actions they think merit it. Or, if the proliferation of yet more configuration options is too much for us to bear, we can come up with a development policy of what should and should not throw warning dialogs and just stick to it.

[Ben Shum (bshum)]

Thanks Joe for the explanation about security bugs.

I can tell those following along that the primary reason I declassified this bug from having the security status was just to make sure it wasn't hidden from view. Security bugs in Launchpad are only viewable by the Evergreen security team and the original reporters of the bug. Marking a bug as security does hide it from view by others limiting potential discussion/fixes.

And speaking of working on it, thanks paxed for the new working branch! We'll check it out soon!

[Sarah Childs (sarahc)]

Elizabeth--perhaps I just assumed that's why you made the change at the time.

Ben--thanks for changing it back, looks like it was effective in getting it seen!

Joe--The trouble is when a feature works as designed, but is not what anyone would reasonably want, it's hard for the user to view that as anything but a bug. I do understand both sides. And I didn't mean that Ben changing it back to wishlist was an example of why catalogers can feel ignored, I meant this bug sitting here for over a year while we debate about whether it's wishlist or not is an example of why catalogers feel our problems are ignored.

But thanks for all the attention it's getting today. Thanks so much for the patch, Pasi!

And Jason, from my perspective, removing the Delete_Copy permission would cause too much daily annoyance to be worth the prevention of accidental deletions.

I'm curious what you have in mind about reworking batch actions in copy buckets. For the most part, I currently find them superfluous. The only batch action I intentionally use is Show Status, because I prefer to do my batch editing from Item Status. I use copy buckets for storage of groups of items for future batch actions. I also keep my copy buckets configured to display only TCN so I can use it conveniently export lists of OCLC numbers.

To me it seems much more desirable to have consistent warnings than configurable warnings, so
+1, as you say, to the idea of a development policy of what should and should not throw warning dialogs

[Jason Etheridge (phasefx)]

Sara, I'm thinking a Select All button (and a Control+A shortcut), and have the actions available just affect the selected entries. Technically it works like that now, except that a given action auto-selects everything in the list first. I also think we need true server-side actions for some batch actions to better handle large quantities of entries in a bucket. I believe there's another launchpad entry for that.

Pasi++

[Elizabeth Thomsen (et-8)]

I agree with Sarah -- we don't need the speed bump of having a separate permission for deleting items -- just the warning is sufficient to remind people that they just clicked the option to delete items from the catalog, not the option to remove items from the bucket.

I also agree with Sarah about the actions for copy buckets -- we don't really use them either, especially since the batch actions work on ALL records, rather than selected records. We work mostly with the Item Status screen, where you can work on selected records or all records and can do so much more, and just store groups of records in the buckets.

[Ben Shum (bshum)]

Picked paxed's change to master. Thanks everyone for your feedback on this.