RFC : More granular rules for Reserves
Hi all, We are trying to find the great way to do more granular rules for reserves. I think the faster way is to patch the actual reserves system, but we are not sure of our solutions is the better one, so we are asking you for comments. The reserves will be edited via smart-rules.pl, this will allow to have rules by branch, category(of borrowers), and item type. * Which branch to use? Our first question was this, we decided to use circcontrol syspref, it seems to be the best choice. * Then, comes the question how to manage if the circcontrol's value is item's holding or home branch and the holding doesn't specify the item to reserve but the record reserved. The solution we propose, is to check if the borrower have remaining reserve rights to one of all the libraries which have an item of this record, if yes, so we allow the reserve. Next step, is the check-in of the item, at each check-in, we will check the reserve queue for the record, and the remaining reserves rights of the user in this library, if it's true, we allow the librarian to put the document in the "waiting to checkout" queue. The problem we see with this way to do, is if the user checkout any of his other reserves, the rights at the check-in times won't be the same as when he did the reserve. So he will have more rights than he had, and he will be able to do more reserves than allowed(if no library is specified). Can we consider we don't care? Or perhaps someone have another idea? Or perhaps we can force the user to choose one of the items if circcontrol value isn't one of the item's branch? Waiting for your comments, bests, -- Nahuel ANGELINETTI
Nahuel ANGELINETTI <nahuel.angelinetti@biblibre.com> wrote:
I think the faster way is to patch the actual reserves system, but we are not sure of our solutions is the better one, so we are asking you for comments.
I am broadly supportive of your approach, BUT:
The problem we see with this way to do, is if the user checkout any of his other reserves, the rights at the check-in times won't be the same as when he did the reserve. So he will have more rights than he had, and he will be able to do more reserves than allowed(if no library is specified).
Why shouldn't we revalidate the rights at the user checkout event? Thanks, -- MJ Ray (slef). LMS developer and supporter for a small, friendly worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237
Hi, Le Wed, 20 May 2009 13:55:14 +0100, MJ Ray <mjr@phonecoop.coop> a écrit :
Nahuel ANGELINETTI <nahuel.angelinetti@biblibre.com> wrote:
I think the faster way is to patch the actual reserves system, but we are not sure of our solutions is the better one, so we are asking you for comments.
I am broadly supportive of your approach, BUT:
The problem we see with this way to do, is if the user checkout any of his other reserves, the rights at the check-in times won't be the same as when he did the reserve. So he will have more rights than he had, and he will be able to do more reserves than allowed(if no library is specified).
Why shouldn't we revalidate the rights at the user checkout event?
The problem is, if the user have a reserve on a biblio record(not a specific item), we don't know how to count the remaining rights on the library where the item is checked-in. Like this: Library1 : 2 reserves maximum Library2 : 3 reserves maximum Record1 : 1 item in Library1, and 1 item in Library2 User1 have 2 reserves to Library1 et 2 reserves to Library2 When he will do the reserves on Record1, he will have the right to reserve, because he still have a right on library2 which have an item of this record. But then, when the librarian check-in the document on Library1, do we put the document for the User1?(because he had no more rights on this library)... It's quiet difficult to manage think kind of case. Or we can force the user to choose a library where he want to check-out the item. Any ideas? bests, -- Nahuel ANGELINETTI
Nahuel ANGELINETTI <nahuel.angelinetti@biblibre.com> wrote:
MJ Ray <mjr@phonecoop.coop> a écrit :
Why shouldn't we revalidate the rights at the user checkout event?
The problem is, if the user have a reserve on a biblio record(not a specific item), we don't know how to count the remaining rights on the library where the item is checked-in. Like this: Library1 : 2 reserves maximum Library2 : 3 reserves maximum
Record1 : 1 item in Library1, and 1 item in Library2
User1 have 2 reserves to Library1 et 2 reserves to Library2 When he will do the reserves on Record1, he will have the right to reserve, because he still have a right on library2 which have an item of this record. But then, when the librarian check-in the document on Library1, do we put the document for the User1?(because he had no more rights on this library)... It's quiet difficult to manage think kind of case. Or we can force the user to choose a library where he want to check-out the item. Any ideas?
I'd offer the user the choice, with a sensible default (their home library? the place they have most unused rights? the place they use most often?). That seems the best solution. I don't understand "force the user to choose". It's offering a choice because there seems no good way to solve this automatically. Hope that helps, -- MJ Ray (slef). LMS developer and supporter for a small, friendly worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237
Le Thu, 21 May 2009 11:05:33 +0100, MJ Ray <mjr@phonecoop.coop> a écrit :
Nahuel ANGELINETTI <nahuel.angelinetti@biblibre.com> wrote:
MJ Ray <mjr@phonecoop.coop> a écrit :
Why shouldn't we revalidate the rights at the user checkout event?
The problem is, if the user have a reserve on a biblio record(not a specific item), we don't know how to count the remaining rights on the library where the item is checked-in. Like this: Library1 : 2 reserves maximum Library2 : 3 reserves maximum
Record1 : 1 item in Library1, and 1 item in Library2
User1 have 2 reserves to Library1 et 2 reserves to Library2 When he will do the reserves on Record1, he will have the right to reserve, because he still have a right on library2 which have an item of this record. But then, when the librarian check-in the document on Library1, do we put the document for the User1?(because he had no more rights on this library)... It's quiet difficult to manage think kind of case. Or we can force the user to choose a library where he want to check-out the item. Any ideas?
I'd offer the user the choice, with a sensible default (their home library? the place they have most unused rights? the place they use most often?). That seems the best solution.
I don't understand "force the user to choose". It's offering a choice because there seems no good way to solve this automatically.
So, we "force him" choosing the checkout library? He cannot anymore choose "next available"? bests, -- Nahuel ANGELINETTI
Bonjour peoples I am about to do some development work to add item-type level hold- fees, and item-type level 'not-for-hold' restrictions in koha3 the reasons? 1) Currently in koha3, an item's reserve-fee (aka hold-fee) is set per patron-type - not per item-type, which is not ideal for libraries that want to charge different reserve-fees for different itemtypes eg: DVD, magazines, best-sellers etc... 2) There is no ability to make an itemtype loan-able, but *not* hold- able. 'best-seller' and 'reference' items are good examples for this problem What do people think about allowing a item-type level 'not-for-hold' checkbox, and a item-type level hold-fee (that overrides the patron-type level hold-fee) a good/bad idea? is this something other people are working on? potential problems i may have missed? cheers, Mason.
Hi Mason, I think this is a good idea and must be implemented. I would make that part of the circulation & fines rules. This would allow us to set it per item types and per patron categories. I know Nahuel is working on something similar at the moment. He is adding the number of renewals to this page. See http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3218 I'll let him comment if this is something he planned to add or not. This made me think that we could also move the rental cost in this page. Currently, this is set at the item level. After those 2 features implemented, all circulation information would be available on per items/per patron base, in the 'Circulation and Fines rules' page, which make a lot of sens to me. Something to discuss: what are we doing with those values in the Patrons and Item pages? Do we keep them for backward compatibility (and using them as default) or we want to remove them and create rules during the migration? Eric Mason James wrote:
Bonjour peoples
I am about to do some development work to add item-type level hold- fees, and item-type level 'not-for-hold' restrictions in koha3
the reasons?
1) Currently in koha3, an item's reserve-fee (aka hold-fee) is set per patron-type - not per item-type, which is not ideal for libraries that want to charge different reserve-fees for different itemtypes eg: DVD, magazines, best-sellers etc...
2) There is no ability to make an itemtype loan-able, but *not* hold- able. 'best-seller' and 'reference' items are good examples for this problem
What do people think about allowing a item-type level 'not-for-hold' checkbox, and a item-type level hold-fee (that overrides the patron-type level hold-fee)
a good/bad idea? is this something other people are working on? potential problems i may have missed?
cheers, Mason. _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
2009/5/25 Eric Bégin <Eric.Begin@inlibro.com>
Hi Mason,
I think this is a good idea and must be implemented.
I would make that part of the circulation & fines rules. This would allow us to set it per item types and per patron categories.
I know Nahuel is working on something similar at the moment. He is adding the number of renewals to this page.
See http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3218
I'll let him comment if this is something he planned to add or not.
This made me think that we could also move the rental cost in this page. Currently, this is set at the item level.
After those 2 features implemented, all circulation information would be available on per items/per patron base, in the 'Circulation and Fines rules' page, which make a lot of sens to me.
Something to discuss: what are we doing with those values in the Patrons and Item pages? Do we keep them for backward compatibility (and using them as default) or we want to remove them and create rules during the migration?
Eric
Mason James wrote:
Bonjour peoples
I am about to do some development work to add item-type level hold- fees, and item-type level 'not-for-hold' restrictions in koha3
the reasons?
1) Currently in koha3, an item's reserve-fee (aka hold-fee) is set per patron-type - not per item-type, which is not ideal for libraries that want to charge different reserve-fees for different itemtypes eg: DVD, magazines, best-sellers etc...
2) There is no ability to make an itemtype loan-able, but *not* hold- able. 'best-seller' and 'reference' items are good examples for this problem
What do people think about allowing a item-type level 'not-for-hold' checkbox, and a item-type level hold-fee (that overrides the patron-type level hold-fee)
a good/bad idea? is this something other people are working on? potential problems i may have missed?
cheers, Mason. _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
The development version of Koha allows hold policies to be set up by branch and itemtype (and soon, patron type) that can allow holds, allow them only to patrons from the item's home branch, or disallow them. So #2 will be possible in 3.2. -- Jesse Weaver
What do people think about allowing a item-type level 'not-for-hold' checkbox, and a item-type level hold-fee (that overrides the patron-type level hold-fee)
The development version of Koha allows hold policies to be set up by branch and itemtype (and soon, patron type) that can allow holds, allow them only to patrons from the item's home branch, or disallow them.
So #2 will be possible in 3.2.
-- Jesse Weaver
Hi Jesse, I just spotted your hold-policy stuff in 3.2 after i sent the email :) It looks really good too Mason
Hi, Le Mon, 25 May 2009 13:47:26 -0600, Jesse <pianohacker@gmail.com> a écrit :
2009/5/25 Eric Bégin <Eric.Begin@inlibro.com>
[...]
The development version of Koha allows hold policies to be set up by branch and itemtype (and soon, patron type) that can allow holds, allow them only to patrons from the item's home branch, or disallow them.
That we are planning to develop, is to koha users to set hold limits(no policies) by i(tem)type/branchcode/categorycode, and the same parameter for renewals allowed. Jesse, the feature you're talking about seems to be only policies, no restriction in holds count, isn't it? -- Nahuel ANGELINETTI
2009/5/26 Nahuel ANGELINETTI <nahuel.angelinetti@biblibre.com>
Hi,
Le Mon, 25 May 2009 13:47:26 -0600, Jesse <pianohacker@gmail.com> a écrit :
2009/5/25 Eric Bégin <Eric.Begin@inlibro.com>
[...]
The development version of Koha allows hold policies to be set up by branch and itemtype (and soon, patron type) that can allow holds, allow them only to patrons from the item's home branch, or disallow them.
That we are planning to develop, is to koha users to set hold limits(no policies) by i(tem)type/branchcode/categorycode, and the same parameter for renewals allowed. Jesse, the feature you're talking about seems to be only policies, no restriction in holds count, isn't it?
-- Nahuel ANGELINETTI
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Yeah. Only policies, not restrictions on hold count. -- Jesse Weaver
Nahuel ANGELINETTI <nahuel.angelinetti@biblibre.com> wrote:
Nahuel ANGELINETTI <nahuel.angelinetti@biblibre.com> wrote:
The problem is, if the user have a reserve on a biblio record(not a specific item), we don't know how to count the remaining rights on the library where the item is checked-in. [...]
I'd offer the user the choice, with a sensible default (their home library? the place they have most unused rights? the place they use most often?). That seems the best solution.
I don't understand "force the user to choose". It's offering a choice because there seems no good way to solve this automatically.
So, we "force him" choosing the checkout library? He cannot anymore choose "next available"?
Well, it looks like either that or we add yet another syspref to let librarians choose between "strict" and "relaxed" rights accounting, doesn't it? Regards, -- MJ Ray (slef). LMS developer and supporter for a small, friendly worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237
Le Thu, 04 Jun 2009 10:04:26 +0100, MJ Ray <mjr@phonecoop.coop> a écrit :
Nahuel ANGELINETTI <nahuel.angelinetti@biblibre.com> wrote:
Nahuel ANGELINETTI <nahuel.angelinetti@biblibre.com> wrote:
The problem is, if the user have a reserve on a biblio record(not a specific item), we don't know how to count the remaining rights on the library where the item is checked-in. [...]
I'd offer the user the choice, with a sensible default (their home library? the place they have most unused rights? the place they use most often?). That seems the best solution.
I don't understand "force the user to choose". It's offering a choice because there seems no good way to solve this automatically.
So, we "force him" choosing the checkout library? He cannot anymore choose "next available"?
Well, it looks like either that or we add yet another syspref to let librarians choose between "strict" and "relaxed" rights accounting, doesn't it?
I didn't do this. You should watch my 2 patches from last week, it introduce "granular" reserves rules, and renewals rules. bests, -- Nahuel -- Nahuel ANGELINETTI
participants (5)
-
Eric Bégin -
Jesse -
Mason James -
MJ Ray -
Nahuel ANGELINETTI