---- Reported by firstname.lastname@example.org 2009-08-07 15:20:20 ----
Created an attachment
Display Return syspref off screenshot
If you check in an item by using the Return boxes on the patron Details tab's list of checkouts, it does not seem to activate the same functionality that doing a return through Circulation, Checkin would. In particular, I've noticed that holds aren't triggered. I think the problem is due to different scripts driving the different pages -- members/moremember.pl controls functionality on patron Details, but circ/returns.pl controls circulation checkin.
Any circ activity from the patron Details tab needs to obey all the rules that are checked and enforced through circulation scripts (anything to do with returns, renewals, and holds).
As a workaround I have done a patch with a system preference (PatronDisplayReturn) which turns on or off the Returns column in the Details tab checkout list. This will force staff to use Circulation, Returns and will stop the problem of holds not being triggered. A more thorough investigation and fix is still needed.
---- Additional Comments From email@example.com 2010-05-12 13:14:02 ----
Updated fix for this bug (in ptfs-harley) can be pulled from the public git repository at http://github.com/Koha-PTFS, branch http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3514
The updated version also turns off the column on the patron checkout tab.
--- Bug imported by firstname.lastname@example.org 2010-05-21 01:11 UTC ---
This bug was previously known as _bug_ 3514 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3514
Imported an attachment (id=1378)
Unknown operating system Windows 2000. Setting to default OS "All".
Actual time not defined. Setting to 0.0
The original reporter of this bug does not have
an account here. Reassigning to the person who moved
it here: email@example.com.
Previous reporter was firstname.lastname@example.org.
The original submitter of attachment 1378 [details] is unknown.
Reassigning to the person who moved it here: email@example.com.
Something needs to be done re: fixing the functionality. Hiding the column is cool, but libraries do like being able to batch check in, and those returns should behave correctly:
-they should trigger transits
-they should trigger holds
patch available at: https://github.com/ptfs/Koha-PTFS
A patch needs to be submitted based on master for this - and either a link
right to the patch or an attached patch is necessary.
Patch from koha-patch mailing list does not apply([PATCH] "Bug 3514 syspref to control whether the Return column is active in Patron Details checkout", from firstname.lastname@example.org, 2009-08-07).
Created attachment 3912 [details] [review]
Proposed incremental fix
Hiding the "check in" checkbox for items which are on hold. This
mitigates the problem of checkins not triggering holds prompts
by forcing the librarian to check in these items individually.
This fix should be considered temporary until a more comprehensive
fix can be developed which incorporates handling for holds.
Pushed, quite a major bug, and this incremental fix is well worth getting in there before the release
*** Bug 3345 has been marked as a duplicate of this bug. ***
*** Bug 4468 has been marked as a duplicate of this bug. ***
I have a question about this bug.
Looks like Owen's fix addressed handling holds, but what about triggering transits? We have a library on 3.6.4 that reports that "if you check in books that belong to another library from this screen, no transfer notice appears and the book just says available."
If that's not fixed, should this bug be reopened? Or should a new bug be created? Or perhaps this is fixed in 3.8?
This seems to have fallen to the wayside and is still an issue in 3.14 and master.
To be specific, this feature is located on both the circulation.pl and moremember.pl pages.
I would suggest that the check in feature on these lists be completely disabled until it can be fixed. As is, we are having to use jquery to hide this feature. We wind up marking a lot of items lost because items wind up on the wrong shelves and in the wrong libraries. It is not worth leaving active in this condition.
Please fix or remove this feature.
[09:54] <cait> nengard: there shoudl be no check box now if the item is on hold
[09:54] <cait> so a return should not be possible in that case
[09:54] <cait> i think maybe transfers are not caught
[09:54] <nengard> cait it still doesn't trigger transfers
[09:54] <nengard> right
[09:54] <nengard> i have confirmed this is the case on master and 3.14.x
[09:55] <nengard> transfers are not triggered still
[09:55] <cait> by transfer you mean a transfer caused by a hold?
[09:55] <nengard> nope
[09:55] <nengard> i mean a transfer
[09:55] <cait> or is there a way to request a transfer without?
[09:55] <nengard> here's the scenario
[09:55] <cait> ah, so when the book needs to 'go back home' after return?
[09:55] <nengard> yes
[09:55] <nengard> i'll stop typing the scenario :)
[09:56] <cait> ah ok :)
[09:56] <cait> sorry :)
[09:56] <nengard> no it's okay!
[09:56] <nengard> Your 1 sentence was way better than the 6 I was going to write :) hehe
If you use the option to checkin, and the item needs to be transferred to another branch, or back to a home location, the item is transferred in the system marking the item in transit, but a pop up is not triggered alerting the staff member it needs transferred.
We have 6 college libraries and had recently noticed what appeared to be one library "stealing" another's stock. We now know of course that the problem is down to this bug. We have a report to identify the problem records (Report Note read "Item's home library not equal to item's holding library, AND item is not on loan AND item is not in transit, AND item type not REVIEW and neither the home or holding branch is [central processing] AND Item is not marked as lost"). It may not be the prettiest of SQL but it did identify 150 problem records. Cleaning these up is proving tedious, requiring a lot of shelf checking and inter-site communication. We were alerted to this problem following a complaint from a student when a reservation / hold on one of the problem records went wrong... It would be great to have a fix. In the meantime we have reviewed workflows (so some staff training) and are considering hiding circulation actions within the Patron Detail, via jQuery.
Assisted by our support company we have been able to make improvements. We have hidden the Return functionality on the Patron Detail screen using the Administration > Configure columns feature. Under Circulation in the id=issues-table, we ticked the Hide checkbox for "checkin", and under User in the id=issues-table we ticked the Hide checkbox for "checkin". However I don’t see a way of using this columns configuration functionality to hide the ability to cancel a reservation on the Patron Detail page. I guess what I am looking for is a id=holds table under Users (there is currently one under Circulation). If there were that table with the Column name being Delete we could hide the functionality that is causing the problem. (We are on 17.05 and I checked 18.05 and while there is an additional table / view under Users it doesn’t offer what I need). Our support company has used css to hide the “actions” options (including the Cancel marked holds and Suspend all holds), which works- it does leave the Delete? column with the tickbox, but applying the actions is not possible.