koha-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Koha-devel] reserves behaviour


From: Rachel Hamilton-Williams
Subject: Re: [Koha-devel] reserves behaviour
Date: Thu Apr 7 15:09:06 2005
User-agent: Mozilla Thunderbird 0.8 (Windows/20040913)

But now, i've some questions on reserves behaviour :
Let me explain (& ask katipo & others some questions) :

user A places a reserve on a book.
* possibility 1 => the book is being issued to user B.
When returned, the librarian is warned "Reserve found, change status to waiting and print slip + print button". This message is buggy : there is no slip printing at all, the button should be "YES" instead of "Print".

SO user B had the book and is bringing it back? this is a message you should get on *Return* of the book.

The message will come from us (Katipo/hlt), we DO print slips I think. So you get the book, and you print a slip saying who's reserved it, and then they put it on a special shelf to wait for the person to pick it up.

And then let the person know it's come in. If you're actually doing reserves, slips of paper in the book are pretty handy - but anyway that's an individual library thing I guess.


If that's the message the librariane gets when B is getting *issued* the book - causing A to miss out on it, then you need the options to

- Continue issue to B, no change to A's reserve - DEFAULT

- Continue issue to B, cancel A's reserve - UNUSUAL I think as there is no reason to assume that just because B has the item, A doesn't want it anymore.

- Stop the issue to B, Change status of Item to Waiting, (print or not the slip), let A know the book is waiting for them -



I've changed this for 2.2.2
There should also be an option to say "NO, cancel reserve". We should also see the reserve date.

As in when the reserve was placed? Sounds fair, so you can judge wether it seems current?

You can however have mulitple reserves on an item (a popular new fiction book for example), and so you'd need to be careful that you think through what to do then. If there are multiple reserves you'll have to cancel each one individually, you really don't want a librarian to cancel all reserves accidentally.

At a library like Horowhenua people pay for reserves, so you need to be pretty careful here.


We could also have a system preference to change status without querying the librarian.

I personally think that's a bad idea - the librarian I think has to actually do something with the book - put it on a special shelf, or in a box or whatever, so interupting the flow of returns seems pretty important else it'll just go back on the shelf won't it?


When it's issued again, and it's to person C - and person A is still waiting for it, I don't think you want to encourage the library staff to be cancelling people's reserves. And that this happens is why you need Koha to make a big song and dance when items are returned, so they don't go back on the shelf to get into this mess.

* possibility 2 => the book is NOT being issued for instance.
In this case, the reserve will stay pending until :

- user A issues it. In this case, the reserve is cancelled & the book is issued.

- user B tries to issue it. In this case, the librarian is warned "book reserved by A, do you want to cancel issue to B or not, do you want to cancel reserve from A or not ?". works fine now that i've fixed bug 965

Yep - I would think in most cases the person with the book in their hand will get priority - but you'll want to confirm the issue to B, and probably the librarian would tell them that they will need to bring it back in good time because others want it, and then decide wether the reserve is still "good".


- nobody tries to issue the book. In this case, the book never becomes "waiting" in opac-user A screen. I think we need a way to say "the book is waiting for you". It could be automatic (=book in the library when the reserve is placed means the book is directly set to "waiting" and can't be issued anymore).

I can't see how that would work in the actual library (Rather than in the code :-). Waiting should mean it really is waiting - it's fair for a customer to assume that if a book is on a shelf they can borrow it.

We also need a screen for the librarian that could show all requests, to enable them to get the book and manually change it's status.

YES - so you need to know which books are on request, and *should* be in the library, so you can go look for them (and shoot whoever let them through returns :-), and put them on the waiting shelf, and change them to waiting.

A list of all reserves is probably good as well - but that may just need to be a report.

Am I missing something here ? does this last feature exist or not ?
Does this sound a good idea for everybody ?

Hope it helps

Cheers
R


--
-----------------------------
Rachel Hamilton-Williams
General Manager
Katipo Communications Ltd

Phone:  +64-4-934 1285
Mobile: 021 389 128
E-mail: address@hidden
Web:    www.katipo.co.nz




reply via email to

[Prev in Thread] Current Thread [Next in Thread]