When returning items from the self checkout screens is allowed, there is no link to do so in GUI. It looks like the table of checkouts should have a return item link in the manual, but there is only a renew link visible https://koha-community.org/manual/20.05/en/html/circulation.html#self-checkout To test: - Activate WebBasedSelfCheck and SCOAllowCheckin - Go to the self checkout in OPAC - Check an item out - Verify there is only a renew link and no visible option to return it
Seems like this may relate to Bug 25147?
@Andrew, it doesn't since SCOAllowCheckin is already the renamed setting. Anyhow, I'd like to bump this up again as I just came across this issue in Koha 24.05.01 - after using this feature for years. Unfortunately, I don't know when exactly this did start to occur. And, interestingly, it only affects some users... Will report back when I know more...
My issue was caused by a recent regression. See bug 37525. That said, I agree that the UX is not as intuitive as it could be. When you allow "SCOAllowCheckin" this enables multiple buttons to "Return" or "Check in" an item. The one you're missing is the "Check in" button in the "Renew" column of the "Checkouts" table (on the main SCO page). That's only visible for items that cannot be renewed. To lessen the confusion this causes, I set "SCOLoadCheckoutsByDefault" to "Don't show", such that the occasional "Check in" button isn't visible by default. The standard button(s) to return an item are provided *after* you've entered the barcode of the item to be returned. What's making this UX worse are the prominent warnings like "You cannot renew this item again" or "This item is already checked out to you" - things I never intended or know anyway. IMHO, the return workflow needs some love here. 1) When "SCOAllowCheckin" is allowed, add a "Return" column to the "Checkouts" table with a single "Check in" item in it. This speeds up bulk self-checkins and makes the "Renew -> Check in" button less confusing 2) Rephrase the individual return dialog to make returns a first-class citizen, not just a (felt) exception. Cheers
Created attachment 170758 [details] [review] Bug 26479 - Self checkout: option for returning items is missing with SCOAllowCheckin Also. When reading a barcode to the checkout-input box, and when it already is checked-out to the logged-in-patron, SCO used to show the "cancel", "return" and "renew" -options. Now the "return" is missing. This fixes the issue
*** Bug 37525 has been marked as a duplicate of this bug. ***
Created attachment 170808 [details] [review] Signed-off patch I signed off the patch as requested, but mainly in the context of related bug 37525. Thus I'll keep the current status and let Katrin do the final testing/sign-off. Cheers
(In reply to Oliver Behnke from comment #3) > My issue was caused by a recent regression. See bug 37525. > > That said, I agree that the UX is not as intuitive as it could be. When you > allow "SCOAllowCheckin" this enables multiple buttons to "Return" or "Check > in" an item. The one you're missing is the "Check in" button in the "Renew" > column of the "Checkouts" table (on the main SCO page). That's only visible > for items that cannot be renewed. To lessen the confusion this causes, I set > "SCOLoadCheckoutsByDefault" to "Don't show", such that the occasional "Check > in" button isn't visible by default. > > The standard button(s) to return an item are provided *after* you've entered > the barcode of the item to be returned. What's making this UX worse are the > prominent warnings like "You cannot renew this item again" or "This item is > already checked out to you" - things I never intended or know anyway. IMHO, > the return workflow needs some love here. > > 1) When "SCOAllowCheckin" is allowed, add a "Return" column to the > "Checkouts" table with a single "Check in" item in it. This speeds up bulk > self-checkins and makes the "Renew -> Check in" button less confusing > 2) Rephrase the individual return dialog to make returns a first-class > citizen, not just a (felt) exception. > > Cheers I believe these are indeed different bugs. Mine was about the button in the checkous table, that doesn't appear to be fixed here, since Olli wrote: "But I felt like the user should not be able to check-in books from that list, because there is no guarantee the user actually has the book." So the patch should indeed probably go on bug 37525. With self checks you never know if the user actually has the item, it's all about trust. Please be aware that there is also a separate GUI for checkins that is more advanced probably, see SelfCheckInModule system preference.
(In reply to Oliver Behnke from comment #6) > Created attachment 170808 [details] [review] [review] > Signed-off patch > > I signed off the patch as requested, but mainly in the context of related > bug 37525. Thus I'll keep the current status and let Katrin do the final > testing/sign-off. > > Cheers Thank you for the sign-off.
Comment on attachment 170808 [details] [review] Signed-off patch Obsoleting the patch that is actually addressing Bug 37525
I guess this is back to assigned status then. (for lack of being able to go back to new)