Salvete!
OhEmGee, Galen's ears must have been burning.
>I could see wanting to have an item
> auto-transfer to C after a period of time, a la rotating collections.
I agree and I'll think on the other one some more. I would say that
rotating collections are common.
> Perhaps our modeling needs to distinguish between transfers and
> transfer requests. The former would be the record that an item is
Yes definitely. I found as I was describing and asking things of Liz that
there were two entangled articulations. I'd rather have 2 related but hopefully
not inextricable articulations.
> either in transit (i.e., branchtransfers where datearrived is null) or
> that it was successfully transferred in the past (datearrived is not
> null), while the later would be a request saying that at some
> specified future time the item *should* transit, either
> unconditionally or when it's not needed to fill a hold request.
*nod* This also would beg the contruction of olde data for those things,
too. One could be olde transfers and the other olde reserves. I would
anticipate the latter being more useful than the former. ("I don't want to
sound stupid, but I forgot to pickup a reserve that I placed on a book I forgot
the title of...")
>> A librarian might also legitimately want to have a transfer and a
>> reserve going at the same time and choose between them at check-in time.
>
Mmm, bet hedging, classic.
> I think this should be unpacked as well ... when would one prefer to
> transit the item rather than fill a hold request?
In the case of an
item that has been damaged and needs return to processing. (You don't
like transmission fluid leaking from your Chilton's?)
In the case that the delivery driver is at the door right NAO and that hold
could theoretically come back to you quite quickly v. sitting on your holds
shelf mouldering away for quite a while.
These are related to requests, obviously. I realise a lot of this can be
done with overrides. I <3 overrides for situational stuff. Being a slave to the
LMS is no fun. Some of this stuff can be managed with clever Patron categories
and is on the Librarian rather than the database designer.
In the case of a delinquent Patron, I'd rather forward the item on to
someone that is more likely to return it than give it to someone proven to be a
bit dodgy.
In the case of a Patron what takes overly long to read in favour of one
that I know takes a day or two to worm on through. (The former is me. Don't
look at my reading records, they are not pretty on the renewal front.)
In the case of at Patron who has a time sensitive request. (Dude, my kid
needs this book for his school project what was due YESTERDAY. Doctor so and so
needs this book for surgery NAO.) These are related to requests, obviously.
In the case that the item has essentially been on world tour and really,
the collection development people are getting torqued that their book isn't on
*their* shelf. (This should be accomplished through itemtypes, but hey,
sometimes folks are nice and it's not.)
I also think this is useful to think about in the reverse. When would I
want to prefer that an item stay put rather than fill a transfer?
In the case of a Very Important Patron. (You tell that Major Sponsor they
ain't getting Consent of the Networked right now or Jo that she's not getting
Fifty Shades of Grey. Not me, I'm a coward!)
In the case where geography makes it silly and a book would ping pong
unnecessarily if behaving how it ought to under the transfer or reserves queue
alone. (This happens with ILL proper way more than local transfers, but
seriously, why would I send summat way far out only to come back again when I
can just kill all non local holds in one fell swoop?{Clearly care needs to be
taken in logic to avoid making someone wait for bloody ever for their stuff,
but suppose someone is #5 on the list and you're working on #3. Skip #4 for now
because it's a victimless crime like punching someone in the dark.})
In the case of a book club, town read, or other event that is time
sensitive. (As in hey, I happen to need 10 copies of this, but just for tonight
or 1 week from now, or whatever. [Yes you ought to have placed a group hold,
but hey, let's not talk about who smells like what for not doing so.])
Hope some of this made sense.
Cheers,
Brooke
_______________________________________________
Koha-devel mailing list
[email protected]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
