Re: [Koha-devel] reserves behaviour

[Paul POULAIN]

Rachel Hamilton-Williams a écrit :
> > 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.

That's how it works

> 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.

I just have changed the name of the button. The text is still "reserve 
found, change status to waiting and print slip ?" It's just the button 
that has a "YES" instead of a "Print". More clear I think.

I've found that I have commented the "printslip" line. Don't remember 
why, but it means that the slip won't be printed anyway. You should do 
some tests to see what happends when uncommenting this line.
For libraries that don't print slips( ie : don't have a printer ? with a 
-new- systempref printslips ? question still to decide), we still need 
the behaviour (=change status to waiting) but without slips.

> 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 -

No, that's the message when the book is RETURNED.

> > 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.

OK.

> > 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?

right. One point for you here.

> 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".

In a public library probably. But in a specialized library, the teacher 
may have reserved & the student want to issue. In this case, the teacher 
has priority. So we need a librarian decision.

> > - 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.

for instance, when a reserve is placed, the user can't know wether :
* the book is available & can be picked in the shelves.
* the book is on loan & the user must still wait for it to be returned.

Maybe we could just add an information : when a reserve is placed, add a 
issuing status like :
"book is in our shelves"
"book is being issued, should be returned before dd/mm/yyy"
(and when returned, the message becomes "book returned, waiting for you")

> > 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.

we are OK here.

Any other opinion from France or USA ? Does this sound coherent ?

(anyway, all those features will be for 2.2.3, it's 2.2.2 day now)

--
Paul POULAIN
Consultant indépendant en logiciels libres
responsable francophone de koha (SIGB libre http://www.koha-fr.org)