[Koha-bugs] [Bug 3792] Checking out on-hold item to someone else replaces item-level hold with next available

Thu Nov 19 14:14:47 CET 2009

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3792

--- Comment #1 from Jane Wagner <jwagner at 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.

-- 
Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.