Bug 3792

Summary: Checking out on-hold item to someone else replaces item-level hold with next available
Product: Koha Reporter: Jane Wagner <jwagner>
Component: Hold requestsAssignee: Galen Charlton <gmcharlt>
Status: CLOSED WORKSFORME QA Contact: Bugs List <koha-bugs>
Severity: normal    
Priority: P3 CC: cbrannon, liz, smoreland
Version: master   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:

Description Chris Cormack 2010-05-21 01:15:02 UTC


---- Reported by jwagner@ptfs.com 2009-11-18 18:13:28 ----

Here's the scenario.  A patron places an item-level hold on a particular copy of a title and is first in line (priority 1).  Another patron brings that particular item up to the desk and wants to check it out; library policy allows that even though it's on hold for other people.  When the item is checked out, the screen warns that it's on hold for patron A and do you want to proceed with the checkout.  If you click Yes, the item is checked out, but the item-level hold for patron A is now replaced by a "next available" hold.  I replicated this on latest Koha head.

The system should retain the item-level link when putting Patron A back in the holds queue.  This may be related to the problem described in http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2830 -- it's not the same problem, but that's the only similar report I found.

Any ideas on how to fix?



---- Additional Comments From jwagner@ptfs.com 2009-11-19 13:14:47 ----

We had a lengthy discussion on the IRC about this yesterday, which I've edited down below.  To summarize, possible solutions to fix this without breaking other things would be:

(a) if the reserve table entry has a barcode but "waiting" status hasn't been set yet (the hold hasn't been triggered), recreate the hold as item level with that barcode; otherwise recreate as title level.  This could miss some item-level holds that had already been triggered.

or (b) investigate how the constraint field is presently used; if one of the settings means item level, then recreate that hold as item level.  Otherwise recreate as title level.

Any other comments or ideas?


hdl		jwagner: see 2830 should be the same. I wanted to fix that for 3.0.4 and then for 3.0.5 But had no time. I could ask nahuel to do it he had some ideas about that and a clear vision of C4/Reserves.pm but might take time as well

jwagner		hdl, I saw 2830, but it seemed to be the reverse -- comment #2 says it's going back into the holds queue as a copy specific instead of next available.  I'm guessing it's probably related, though.

wizzyrea	I don't think you can specify the behavior either way because we would WANT it to be title level if that happened which is probably what 2830 is saying...

jwagner		No, the problem my people are having is that an item-specific hold suddenly becomes a title level hold, which is a problem if they're trying to reserve one particular issue of a journal, for example.

wizzyrea	right, but if you change it then that would break the way we use it (or want it to work) seewhatimean?

jwagner		no.  Why wouldn't you want to keep an item-level hold as item-level?

chris		it should be an option

jwagner		But this one makes sense to me -- an item-level hold should STAY an item-level hold.  Same for a title-level hold.

chris		liz is saying they want an item level to change to title level

wizzyrea	if it has been checked out to another patron

wizzyrea	in NExpress, we really try to avoid starting out with item level holds

jwagner		Right, but I don't understand why you would want it to change to a title level hold.  Our particular case is journal issues, for example.  If you've put a hold on Vol 32. No 5, you don't want it satisfied by Vol 31. No 2.

chris		this all worked fine in koha 1 cos you had group level holds so if you had 2 copies of Vol 32. No 5 you could place a group level reserve, and either of those would satisfy it.

chris		the problem with item level, say you have 28 copies of the same thing (in a consortia quite possible)

jwagner		Hmmm.  But a checkin of something outside that group wouldn't fill the hold?

chris		jwagner: thats right

wizzyrea	that would probably be an enhancement to the special holds rules (walkin, local hold) etc

jwagner		Well, that sounds like a useful feature.  I take it that it bit the dust with later versions?

wizzyrea	so you were looking at both macro and micro title

chris		it died when we started storing marc interntally

chris		koha used to have a three tier structure, biblio, biblioitem and item 1 to many, 1 to many.  now its 1 to 1, 1 to many

jwagner		(one biblio, one biblioitem, many items?)

chris		thats how it is now cos marc doesnt understand manifestations of the same work or similair work.  we'll get back there, its a tradeoff, internal marc support, breaking the group model

chris		now we just have to reimplement groups

wizzyrea	i am pretty sure, that in the case of magazines, each month has a bib, and every library adds their copy to that bib. this may be the wrong method of handling it (that's in NExpress)

jwagner		That would mean that you get gazillions of hits in the hitlist, if you search that title?

wizzyrea	yes

wizzyrea	but you could say Time, january

chris		so the solution for that, well a solution is a meta record that groups biblio records together so you can group all the months together, and the search displays just one row.  this doesnt exist in koha yet but its on my list.  personally i hate nothing more than getting 6 rows of the same item

wizzyrea	BUT, I can say that once an item is assigned to a patron, it essentially becomes an item level hold, and if that item is checked out to another patron, we WANT it to go back to being a title level, instead of waiting in the queue for that specific item

chris		*nod*

jwagner		Yes, a de-duping routine of some kind would be nice.

chris		that is the problem right there wizzyrea

wizzyrea	i'm afraid that if you fixed all item level holds to only map back to item level holds, that functionality would break

jwagner		So it sounds like fixing it the way we want really wouldn't work for you, wizzyrea.

wizzyrea	right, that's what I was trying to get across, I think

chris		once a hold is marked waiting, its switched to item-level from title. but if it gets issued, it needs to go back to title

jwagner		I have one of the programmers looking at it now.  Sounds like we could either do it as a local fix, or maybe make it controlled by one of the all-proliferating sysprefs?

chris		consequently, if it started as item at the start, it should stay item its a trickier problem than it seems. to do it properly, you need to know the state the reserve started in, not how it is now if that makes sense

wizzyrea	yes yes yes

jwagner		It makes sense.  Does the barcode in the reserves table change if it gets assigned?

wizzyrea	thank you, I knew there was something there that made my gut go EEKS!

chris		in the case of a title level hold, an item now gets assigned

jwagner		I know if you place an item-level hold to begin with, it embeds the barcode.  The hold isn't triggered yet when our problem starts, it's still sitting there as priority 1.  So at that point, if there's a barcode, it should be because it was set that way.


chris		yep, but a barcode gets set once an item is marked waiting

wizzyrea	I think this is a case for a special hold rule. I really do

chris		so if you just check that, a title level hold that is waiting, looks the same as an item-level

jwagner		So if there's a barcode but the "waiting" flag isn't set yet, keep the hold as an item-level, otherwise make title-level?

* wizzyrea	thinks that would work

wizzyrea	that seems logical to me, insomuch as my puny brain can grasp it

jwagner		chris, do you think that would be enough of a safeguard?

chris		that oughta work

wizzyrea	i like this, actually

mdhafen		what about the constraint column in reserves?  I believe it was used for group reserves, but I don't know what it's for now.  Maybe targeted holds?

chris		there used to be a field that had either an a or an o in it.  a = all o = only the ones specified in constraints.  if that is still in use, all you need to check is that column

mdhafen		right.  Maybe that field could be re-purposed to track the original state of the hold? I suspect it is still in use, but I'm not certain.  I don't see many item-level holds

wizzyrea	we don't either. i can say it's relatively annoying that holds become true item level once assigned. they're hard to work around, those irritating exceptions that make ILS's so hard to write.

mdhafen		chris is right, if the field is still in use it would indicate if a reserve was originally item level, I think. the reservecontraints table doesn't have itemnumber though, so maybe that isn't right. be cool if it did though. reserve constraints could be expanded to track item-level holds too.





---- Additional Comments From jwagner@ptfs.com 2009-11-19 15:04:49 ----

As a followup, the system does not presently seem to be using the constrainttype field in any way -- whether a hold is title level or item level, it sets this field as 'a'.  Not sure if this could be re-implemented without other issues.



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

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

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.

Comment 1 Christopher Brannon 2013-11-21 22:14:52 UTC
This bug looks old.  I tried this on 2.10 and could not replicate the problem.

Can anyone else confirm this bug exists or is resolved?

Christopher
Comment 2 Christopher Brannon 2013-11-21 22:16:00 UTC
(In reply to Christopher Brannon from comment #1)
> This bug looks old.  I tried this on 2.10 and could not replicate the
> problem.
> 
> Can anyone else confirm this bug exists or is resolved?
> 
> Christopher

That should read 3.10.  Sorry.

Christopher
Comment 3 Liz Rea 2013-11-22 00:12:26 UTC
I just tested this on master, and I could not replicate it. I say we close it.

Liz