[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Koha-devel] reserves behaviour
From: |
Paul POULAIN |
Subject: |
Re: [Koha-devel] reserves behaviour |
Date: |
Fri Apr 8 00:45:07 2005 |
User-agent: |
Mozilla Thunderbird 1.0 (X11/20041206) |
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)