RFC 3.2 - put item hold request flag in circulation policy matrix
At present, if a patron is allowed to place hold requests, they can request any item that is not on loan or doesn't have the binding, lost, or notforloan statuses set. However, some LibLime customers to need more precisely control which items are available for hold requests. For example, a library may want to permit loans for certain item types but not hold requests. To meet this requirement, LibLime proposes to add a "holdability" flag to the circulation matrix (i.e., issuingrules). This would allow a library to specify for each branch which patron categories are allowed to place holds on which item types. This holdability flag would be the hold request equivalent of the recall flag proposed in the recalls RFC. Adding this setting will influence: * what item records are available to fill a title-level hold request * what items a patron is allowed to place an item-level hold request for During database upgrade, the holdability flag would be turned on for all existing issuingrules rows, thus preserving the current behavior of allowing all available items to be the target of hold requests. A copy of this RFC is available on the Koha wiki at http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_holdability_fl... Thanks in advance for comments. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Galen Charlton a écrit :
At present, if a patron is allowed to place hold requests, they can request any item that is not on loan or doesn't have the binding, lost, or notforloan statuses set. However, some LibLime customers to need more precisely control which items are available for hold requests. For example, a library may want to permit loans for certain item types but not hold requests.
In 2 words : add an "notforhold" field, as we have a "notforloan" now. Sounds a great idea to me ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08
On Thu, Jul 31, 2008 at 5:59 PM, Paul POULAIN <paul.poulain@free.fr> wrote:
Galen Charlton a écrit :
At present, if a patron is allowed to place hold requests, they can request any item that is not on loan or doesn't have the binding, lost, or notforloan statuses set. However, some LibLime customers to need more precisely control which items are available for hold requests. For example, a library may want to permit loans for certain item types but not hold requests.
In 2 words : add an "notforhold" field, as we have a "notforloan" now.
This is not quite clear to me (yet). What I know from the previous system I managed is not that the item is "notforloan" or "notforhold", but that the item has 2 statuses (stored in a separate table, I think) : - a "permanent" status (item status), e.g. "normalbook2weeks" which can be loaned, can be renewed, can have holds, is displayed in Opac, etc. - a "temporary" status (item process status), e.g. "Binding" which can itself be loaned, etc. The item status is chosen by the librarian when she first creates the item. The item process status is either chosen by the librarian at some point (binding) or triggered by the system (e.g. "in process" when the item is received from a vendor). If the item currently has an "item process status" applied to it, this takes precedence over the "item status". Having a separate "item process status" allows libraries to create their own: the name a process status, answer the questions (can be loaned? etc): it won't be triggered by any action within the system, but it'll be usable nonetheless; e.g. "hold-for-tomorrow" can be created by the library if they wish. I think that type of logic would allow for Galen's RFC... and many other needs. But maybe I'm just not yet comfortable enough with Koha, maybe it could do these things another way. My 2cts... Nicolas
participants (3)
-
Galen Charlton -
Nicolas Morin -
Paul POULAIN