Bug 4234 - Automatic transfer shouldn't take precedence over a hold transit
Summary: Automatic transfer shouldn't take precedence over a hold transit
Status: CLOSED WORKSFORME
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: rel_3_2
Hardware: All All
: P5 - low normal
Assignee: Galen Charlton
QA Contact: Bugs List
URL:
Keywords:
Depends on: 22162
Blocks: 22160
  Show dependency treegraph
 
Reported: 2010-02-19 08:58 UTC by Liz Rea
Modified: 2023-12-28 20:43 UTC (History)
4 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

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


---- Reported by wizzyrea@gmail.com 2010-02-19 20:58:57 ----

With AutomaticItemReturn preference set to "Do automatically transfer items to their home branch when they are returned." 

When checking in an item that will be automatically transferred home, but also has the potential to be "confirm hold and transferred," the hold transfer should always take precedence over the "send home" transfer.

A "going home" item should only be transited home if the hold is ignored.



---- Additional Comments From smoreland@nekls.org 2010-02-22 23:00:35 ----

Screencast of this.  Item belonging to Library B is checked in at Library A but needed at Library C to fill a hold. 

http://screencast.com/t/Njg0M2M2Y



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:24 UTC  ---

This bug was previously known as _bug_ 4234 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4234

Actual time not defined. Setting to 0.0
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.

Comment 1 Katrin Fischer 2013-04-13 17:55:40 UTC
Liz, could you take a look at this and see if it's still valid?
Comment 2 Marc Véron 2016-03-27 05:57:31 UTC
Still valid?
Comment 3 Martin Renvoize (ashimema) 2019-12-20 14:38:05 UTC
Pretty sure this is still valid... ModItemTransfer just obliterates any existing transfer and replaces it.
Comment 4 Katrin Fischer 2023-01-07 21:39:41 UTC
I have done tests with 2 different use cases:

* Item from A is checked out to user in B
* Hold is placed with pickup in C
* Items return home
* Item is checked in at B
* Transfer is to library C for hold pickup

Similar as above, but the item is not checked out, when returned in B:
* Transfer is to library C for hold pickup

And then to verify that the holds behavior took precedence:
* Item from A (without holds) is checked in at B
* Item is sent to return to A 

I assume that this is fixed, please reopen if I missed something!