Bug 3514 - Returning items through patron Details tab doesn't activate all circulation functions
Summary: Returning items through patron Details tab doesn't activate all circulation f...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P3 new feature
Assignee: Bugs List
QA Contact: Bugs List
URL:
Keywords:
: 3345 4468 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-08-07 03:20 UTC by Jane Wagner
Modified: 2024-05-28 14:27 UTC (History)
20 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Display Return syspref off screenshot (45.57 KB, image/jpeg)
2009-08-07 15:20 UTC, Chris Cormack
Details
Proposed incremental fix (4.63 KB, patch)
2011-04-13 16:23 UTC, Owen Leonard
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 01:11:36 UTC


---- Reported by jwagner@ptfs.com 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 jwagner@ptfs.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 chris@bigballofwax.co.nz 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: chris@bigballofwax.co.nz.
   Previous reporter was jwagner@ptfs.com.
The original submitter of attachment 1378 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.

Comment 1 Liz Rea 2011-03-09 22:21:02 UTC
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
Comment 2 Paul Poulain 2011-03-22 12:52:28 UTC
patch available at: https://github.com/ptfs/Koha-PTFS
Comment 3 Nicole C. Engard 2011-03-22 21:21:03 UTC
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.
Comment 4 Guillaume Hatt 2011-04-04 11:59:44 UTC
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 jwagner@ptfs.com, 2009-08-07).
Comment 5 Owen Leonard 2011-04-13 16:23:42 UTC
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.
Comment 6 Chris Cormack 2011-04-14 22:44:06 UTC
Pushed, quite a major bug, and this incremental fix is well worth getting in there before the release
Comment 7 Katrin Fischer 2011-04-24 14:39:05 UTC
*** Bug 3345 has been marked as a duplicate of this bug. ***
Comment 8 Katrin Fischer 2011-04-24 14:54:03 UTC
*** Bug 4468 has been marked as a duplicate of this bug. ***
Comment 9 Melia Meggs 2012-05-03 23:06:51 UTC
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?
Comment 10 Nicole C. Engard 2014-06-10 14:44:09 UTC
This seems to have fallen to the wayside and is still an issue in 3.14 and master.
Comment 11 Christopher Brannon 2014-06-10 14:55:38 UTC
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.

Christopher
Comment 12 Nicole C. Engard 2014-06-10 14:57:15 UTC
From IRC:
----------

[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
Comment 13 Jessie Zairo 2018-11-09 20:01:01 UTC
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.
Comment 14 Ray Delahunty 2019-02-01 09:47:37 UTC
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.
Comment 15 Ray Delahunty 2019-02-07 08:37:14 UTC
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.
Comment 16 Corinne Hayet 2021-03-25 14:53:00 UTC
We have the same problem in koha 19.11.09.000. No patch since the creation of this report ?
Comment 17 Corinne Hayet 2021-03-25 14:54:18 UTC
Holds are not active if we use the checkin box
Comment 18 AspenCat Team 2024-05-14 13:58:15 UTC
Just commenting on this, because it has been stagnant for a bit, but having this fixed is something we would be interested in - Bob Bennhoff
Comment 19 Christopher Brannon 2024-05-14 16:09:17 UTC
I am still of the opinion this feature is useless if it can't do everything that check-in is supposed to do.  A half way job is a useless job.
Comment 20 Katrin Fischer 2024-05-15 07:40:35 UTC
I think this might be done via API at some point and then it would probably be easier to enforce the same behavior.
As of now you can hide the column and deactivate the feature that way. 
But we find it useful for "batch checkins" and also in libraries that don't have barcodes in their books and use the fallback feature.