[Koha-bugs] [Bug 17150] New: Cancelling holds over process needs improvement

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Fri Aug 19 01:21:17 CEST 2016


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17150

            Bug ID: 17150
           Summary: Cancelling holds over process needs improvement
 Change sponsored?: ---
           Product: Koha
           Version: master
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5 - low
         Component: Hold requests
          Assignee: koha-bugs at lists.koha-community.org
          Reporter: cbrannon at cdalibrary.org
        QA Contact: testopia at bugs.koha-community.org
                CC: gmcharlt at gmail.com

Created attachment 54584
  -->
https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=54584&action=edit
Cancel Hold buttons

I'm not seeing a bug with all of this spelled out exactly, so if I repeat
something already posted, I'm sorry.  It may be that some of this needs to be
broken into different bugs, or is already addressed in another bug.  I am
linking together what I know to be part of the problem, but not the whole
picture.

Cancelling a hold that is over is a tedious process at best.  I'll try to
explain what we are seeing.

So, when we go to the Holds over tab in the Holds awaiting pickup, we find the
item.

Issue #1 (holds01.png): Even though the buttons are different, they don't act
different, they are not even necessarily accurate about the item, and they have
lost functionality between 3.18 to 3.22.

Issue #2:  Even though a transfer might be triggered, you have to check the
item in to get the slip.  Waste of time.  It should come up with this choice
when the transfer is triggered while cancelling (holds04.png).

Issue #3:  Even though the item might have another hold request, it isn't
revealed when you cancel the hold.  So, you have to check EVERYTHING in that
you cancelled to see if there is a hold, or a pending transfer.  Again, this
should happen when cancelling the hold.

Issue #4: As mentioned in issue #1, the buttons are not very accurate about
what happens next with the item.  Sometimes there is a hold request at the
current location (holds05.png).  So, you have to check ALL of these items in to
find out if they have holds.  Again, this should happen when cancelling the
hold.

Issue #5: Even though there is a hold request for an item you are cancelling,
cancelling the hold applies a transfer.  So, when you check the item in after
cancelling, you see a transfer to the item's home location AND the hold request
(holds06.png).  This is CONFUSING and crazy.  Especially if it is to the same
location.  We end up having to cancel the hold, check the item in, cancel the
transfer, check the item in again, and then trigger the hold.  Why not just
skip cancelling the transfer and trigger the hold?  Because the transfer will
still be in the system!  Crazy!

Issue #6: When you cancel a hold, you get bounced back to the Holds waiting
tab, so you have to click back over to the Holds over tab for the next item.  I
think there is another bug on this one, but I can't find it at the moment.

So, why don't we just use the Cancel All button (by the way, shouldn't it read
"Cancel all")?  Because not all the items are still in our hands.  Some items
end up walking out without being checked out.

Issue #7: It would be great if there were a button to mark the item missing, or
maybe someone calls and finds out the person has the item, so a button to check
the item out to that patron would be great.

Issue #8: I've noticed another little quirk.  If you compare holds04.png with
holds06.png, you'll see that the transfer popups are different.  holds04.png
has no buttons.  Just links.  I know that one transfer is related to the hold,
which doesn't make sense because when we cancel it, it doesn't affect the hold.

Issue #9: You may also notice on holds06.png, the address fits on the full line
in the transfer popup, but not in the holds popup.  The popup boxes are the
same size, and the bullets offset in the same place, so something is off on the
formatting.

Issue #10: Cancelling a hold takes 2 to 3 times longer in 3.22 than it did in
3.18.  This is surprising since the popups were taken away!

So, ideally, if these are legitimate issues, and are addressed, this is what we
would expect to see:

1: Just show a Cancel button for all items with the words "Cancel hold".  What
happens when you click the button should be self explanatory.  Perhaps if Koha
didn't have to determine the next status of the item just to create a button,
the refresh of the page would improve.  Hmmmmm....
2: When you cancel a hold, if the item needs to go home, it will show the
transfer popup to let you print the slip.
3: When you cancel a hold, if the item has a hold, it doesn't trigger a
transfer, and only shows the hold popup, whether it is a local hold or going
somewhere else.
4: Whether it has a popup or not, when done with the popup it should put you
back on the same tab you were last on.
5: Buttons should be on the transfer popup.
6: Formatting should be consistent between the hold and transfer popups (I
know, this is sooooo trivial).
7: We should have more options for holds that are over, than just Cancel, since
there are other things that can be happening, like missing or already with the
patron.  A "Mark missing" button and a "Checkout to this patron" button would
be nice.

Sorry if this sounds like a rant.  I know that how we do things isn't the way
everyone does things, but this has bugged me for a LONG time, and I think these
are some great improvements, even if they need to be tweaked a bit to
accommodate other workflows.  I will add the screens and see alsos in a moment.

-- 
You are receiving this mail because:
You are watching all bug changes.
You are the assignee for the bug.


More information about the Koha-bugs mailing list