Hi,
On Thu, Feb 28, 2013 at 4:39 PM, BWS Johnson <[email protected]> wrote:
>> 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?)
But I find that imparts a special tang to the reading experience!
Seriously, thanks for the example, and that does sound like a
situation that could occur often enough to account for in the checkin
and transit workflow.
> 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.])
Thanks! This is all giving me the impression that many of these use
cases could be handled with a good interface for cancelling transfer
(requests).
Regards,
Galen
--
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email: [email protected]
direct: +1 770-709-5581
cell: +1 404-984-4366
skype: gmcharlt
web: http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
_______________________________________________
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/
