Hello world, We are reviewing Koha for 3.0 Release & Joshua pointed something important: the way issuingrules worked in koha 2.2. In Koha 2.2, the way it works is : - you define the rules depending on itemtype / patron category / branch - you have "wildcard" that means "all of them". For example, * / adult / * = 5 means "an adult patron can't issue more than 5 items whatever the branch". - The circ module check ALL the rules & warn if one is not correct. So, if you don't fill a cell, it's considered as 0 (= no issue possible) - you must fill book / * / * by understanding it means : "no patron can't issue more than X book(s)" This behaviour troubled a lot users, as we often have questions about warnings that were not expected. Joshua think, and i' fully agree with him, that the user understand the wildcard as 'default if nothing specified'. So, for example, book / * / * would mean : if a specific rule is not defined for patron category, then use this default value. We should not have a "check ALL the rules", but a "check the 1st available, from most to less specific + check the total rule if available.". The "wildcard" on itemtype being renamed to "total", and being applied if defined, as total document the patron can issue. so we could have something like that adult children default book empty 3,21 5,21 serial 4,14 3,21 5,21 comic 5,21 3,21 empty total 7 empty 5 which would mean : - an adult can issue 5 books for 21 days (default rule) - an adult can issue 4 serials for 14 days (specific rule) - an adult can issue 7 documents total - a child can issu 3 books, 3 serials, 3 comics, but 5 document maximum The "branch level" has the same behaviour : it a rule for a branch is defined, then it's applicable, otherwise, it's the default rule of the default branch. Let us know your opinion on this. It would require some tweaking on issuingrules definition & a small rewrite the CanBookBeIssued sub, to check only 2 rules (1st found + total), not 8 (every cell that fit the issue). -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19
I would like to place what little influence I have in favor of this idea. I am one of those who had trouble with the way issuing rules workes in 2.2. I have gone as far as implementing something very similar to this already in my install. I will add that, as I recall, there are two places in the 2.2 code that I had to change. I haven't seen the 3.0 code, so that may not be the case anymore. I'll look at the 2.2 code to see if I can find the other place again. Let's see... One was in C4/Circulation/Circ.pm::TooMany, also C4/Circulation/Fines.pm::CalcFine. I've change CalcFine() so much though, that it's hard to tell if you will need to make adjustments there or not. I suspect you will. On Tue, 2007-10-09 at 15:21 +0200, Paul POULAIN wrote:
Hello world,
We are reviewing Koha for 3.0 Release & Joshua pointed something important: the way issuingrules worked in koha 2.2.
In Koha 2.2, the way it works is : - you define the rules depending on itemtype / patron category / branch - you have "wildcard" that means "all of them". For example, * / adult / * = 5 means "an adult patron can't issue more than 5 items whatever the branch". - The circ module check ALL the rules & warn if one is not correct. So, if you don't fill a cell, it's considered as 0 (= no issue possible) - you must fill book / * / * by understanding it means : "no patron can't issue more than X book(s)"
This behaviour troubled a lot users, as we often have questions about warnings that were not expected.
Joshua think, and i' fully agree with him, that the user understand the wildcard as 'default if nothing specified'. So, for example, book / * / * would mean : if a specific rule is not defined for patron category, then use this default value.
We should not have a "check ALL the rules", but a "check the 1st available, from most to less specific + check the total rule if available.".
The "wildcard" on itemtype being renamed to "total", and being applied if defined, as total document the patron can issue.
so we could have something like that adult children default book empty 3,21 5,21 serial 4,14 3,21 5,21 comic 5,21 3,21 empty total 7 empty 5
which would mean : - an adult can issue 5 books for 21 days (default rule) - an adult can issue 4 serials for 14 days (specific rule) - an adult can issue 7 documents total - a child can issu 3 books, 3 serials, 3 comics, but 5 document maximum
The "branch level" has the same behaviour : it a rule for a branch is defined, then it's applicable, otherwise, it's the default rule of the default branch.
Let us know your opinion on this. It would require some tweaking on issuingrules definition & a small rewrite the CanBookBeIssued sub, to check only 2 rules (1st found + total), not 8 (every cell that fit the issue).
Hi, I've read the message and I do agree. I just want to mention some of our own developments. We have 2 types of items in case of biblios representing books. We have "room" and "common" items; "common" items use the standard issuing rules but "room" items cannot be on loan during working days, our librarians lend them to the users for the weekend. What is the porpouse of this? well, not to have a book sleeping in the shelve during the weekend if a borrower needs it. This can't be done during working days (Monday to Friday) because we must always have one copy (item) to be used in the lecture room. The circulation depends on one item field which has the value specifying it's a "normal" or "room" one. We also don't work with fees and fines, we penalize with suspensions, we've developed a module for this. Perhaps some of this ideas can be integrated into 3.0, just a suggestion, I'm not asking for it. I don't know if this situation exists in other libraries. We can't share this lines of code because we have merged them with other particular modifications which only apply to our university (as far as I know). What we can do is send you ALL the code, we don't have the time (at this moment) to extract a clean module to send it to you. Regards, -- Ernesto Silva. Coordinador de Desarrollo Web y Sistemas Abiertos Centro de Procesamiento de Datos Universidad ORT Uruguay. E-mail: silva@ort.edu.uy Tel: (+598-2) 902-1505 ext. 206 Fax: (+598-2) 900-2952 Paul POULAIN wrote:
Hello world,
We are reviewing Koha for 3.0 Release & Joshua pointed something important: the way issuingrules worked in koha 2.2.
In Koha 2.2, the way it works is : - you define the rules depending on itemtype / patron category / branch - you have "wildcard" that means "all of them". For example, * / adult / * = 5 means "an adult patron can't issue more than 5 items whatever the branch". - The circ module check ALL the rules & warn if one is not correct. So, if you don't fill a cell, it's considered as 0 (= no issue possible) - you must fill book / * / * by understanding it means : "no patron can't issue more than X book(s)"
This behaviour troubled a lot users, as we often have questions about warnings that were not expected.
Joshua think, and i' fully agree with him, that the user understand the wildcard as 'default if nothing specified'. So, for example, book / * / * would mean : if a specific rule is not defined for patron category, then use this default value.
We should not have a "check ALL the rules", but a "check the 1st available, from most to less specific + check the total rule if available.".
The "wildcard" on itemtype being renamed to "total", and being applied if defined, as total document the patron can issue.
so we could have something like that adult children default book empty 3,21 5,21 serial 4,14 3,21 5,21 comic 5,21 3,21 empty total 7 empty 5
which would mean : - an adult can issue 5 books for 21 days (default rule) - an adult can issue 4 serials for 14 days (specific rule) - an adult can issue 7 documents total - a child can issu 3 books, 3 serials, 3 comics, but 5 document maximum
The "branch level" has the same behaviour : it a rule for a branch is defined, then it's applicable, otherwise, it's the default rule of the default branch.
Let us know your opinion on this. It would require some tweaking on issuingrules definition & a small rewrite the CanBookBeIssued sub, to check only 2 rules (1st found + total), not 8 (every cell that fit the issue).
Hi Ernesto, Thanks for giving us some indication about your preferences for issuing rules, and also the information about what you've developed inhouse. Now that the official Koha project runs Git, it will be much easier for your team to contribute select features, and also manage a local repo that can be synchronized with the main Koha repo (it's the main reason we switched to a distributed version control system). Just in case you haven't seen these links: Instructions on how to use Git http://wiki.koha.org/doku.php?id=en:development:git_usage Git repo for the 3.0 release http://git.koha.org Git allows us to take advantage of some powerful tools for merging 'branches' of Koha ... it gives you the opportunity to share things very easily, and for us to ingest them into the main Koha repo ... it'd be well worth the time to learn how it works before our codebases get too divergent. In fact, I think the main reason we weren't able to integrate your code into this release was not because we weren't interested in it, it was because we simply didn't have time to hunt and peck through it and figure out what has changed. As always, we're available any time on the #koha channel on IRC if you'd like to discuss anything in real time. Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS ----- "Ernesto Silva" <silva@ort.edu.uy> wrote:
Hi, I've read the message and I do agree. I just want to mention some of our own developments.
We have 2 types of items in case of biblios representing books. We have "room" and "common" items; "common" items use the standard issuing rules but "room" items cannot be on loan during working days, our librarians
lend them to the users for the weekend. What is the porpouse of this? well, not to have a book sleeping in the
shelve during the weekend if a borrower needs it. This can't be done during working days (Monday to Friday) because we must always have one
copy (item) to be used in the lecture room. The circulation depends on
one item field which has the value specifying it's a "normal" or "room" one.
We also don't work with fees and fines, we penalize with suspensions,
we've developed a module for this.
Perhaps some of this ideas can be integrated into 3.0, just a suggestion, I'm not asking for it.
I don't know if this situation exists in other libraries. We can't share this lines of code because we have merged them with other particular modifications which only apply to our university (as far as I know). What we can do is send you ALL the code, we don't have the time (at this moment) to extract a clean module to send it to you.
Regards,
-- Ernesto Silva. Coordinador de Desarrollo Web y Sistemas Abiertos Centro de Procesamiento de Datos Universidad ORT Uruguay. E-mail: silva@ort.edu.uy Tel: (+598-2) 902-1505 ext. 206 Fax: (+598-2) 900-2952
Paul POULAIN wrote:
Hello world,
We are reviewing Koha for 3.0 Release & Joshua pointed something important: the way issuingrules worked in koha 2.2.
In Koha 2.2, the way it works is : - you define the rules depending on itemtype / patron category / branch - you have "wildcard" that means "all of them". For example, * / adult / * = 5 means "an adult patron can't issue more than 5 items whatever the branch". - The circ module check ALL the rules & warn if one is not correct.
So, if you don't fill a cell, it's considered as 0 (= no issue possible) - you must fill book / * / * by understanding it means : "no patron
can't issue more than X book(s)"
This behaviour troubled a lot users, as we often have questions about warnings that were not expected.
Joshua think, and i' fully agree with him, that the user understand
the wildcard as 'default if nothing specified'. So, for example, book / * / * would mean : if a specific rule is not
defined for patron category, then use this default value.
We should not have a "check ALL the rules", but a "check the 1st available, from most to less specific + check the total rule if available.".
The "wildcard" on itemtype being renamed to "total", and being applied if defined, as total document the patron can issue.
so we could have something like that adult children default book empty 3,21 5,21 serial 4,14 3,21 5,21 comic 5,21 3,21 empty total 7 empty 5
which would mean : - an adult can issue 5 books for 21 days (default rule) - an adult can issue 4 serials for 14 days (specific rule) - an adult can issue 7 documents total - a child can issu 3 books, 3 serials, 3 comics, but 5 document maximum
The "branch level" has the same behaviour : it a rule for a branch is defined, then it's applicable, otherwise, it's the default rule of the default branch.
Let us know your opinion on this. It would require some tweaking on issuingrules definition & a small
rewrite the CanBookBeIssued sub, to check only 2 rules (1st found +
total), not 8 (every cell that fit the issue).
_______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel
Thanks Joshua, in the following days I'll try to connect to the GIT repository and upload our code so anyone can use it. Best regards, -- Ernesto Silva. Coordinador de Desarrollo Web y Sistemas Abiertos Centro de Procesamiento de Datos Universidad ORT Uruguay. E-mail: silva@ort.edu.uy Tel: (+598-2) 902-1505 ext. 206 Fax: (+598-2) 900-2952 Joshua M. Ferraro wrote:
Hi Ernesto,
Thanks for giving us some indication about your preferences for issuing rules, and also the information about what you've developed inhouse. Now that the official Koha project runs Git, it will be much easier for your team to contribute select features, and also manage a local repo that can be synchronized with the main Koha repo (it's the main reason we switched to a distributed version control system).
Just in case you haven't seen these links:
Instructions on how to use Git http://wiki.koha.org/doku.php?id=en:development:git_usage
Git repo for the 3.0 release http://git.koha.org
Git allows us to take advantage of some powerful tools for merging 'branches' of Koha ... it gives you the opportunity to share things very easily, and for us to ingest them into the main Koha repo ... it'd be well worth the time to learn how it works before our codebases get too divergent. In fact, I think the main reason we weren't able to integrate your code into this release was not because we weren't interested in it, it was because we simply didn't have time to hunt and peck through it and figure out what has changed.
As always, we're available any time on the #koha channel on IRC if you'd like to discuss anything in real time.
Cheers,
Hi Paul, While you're revisiting the issuing rules, you might want to consider moving renewalsallowed and possibly rentalcharge from itemtypes to issuingrules. It would allow for more flexibility in large library systems. Or maybe a syspref to control whether these fields are defined in itemtypes or issuingrules, for those libraries that don't need to have differing rules on a per-library or per-patrontype basis? Cheers, Cindy -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cindy Murdock Network Administrator Meadville Public Library | CCFLS http://meadvillelibrary.org | http://ccfls.org
one more request: change default branch to '*', so that all 'defaults' are handled the same way. this makes local modifs to the circ subs much easier to manage. for those currently running '2.9x', a simple UPDATE issuingrules set branchcode='*' where branchcode=''; should suffice. I have a syspref-governed mod to issuingrules to commit... it does require this change. Is there any reason to treat branchcode differently here, Paul? Ryan Higgins ----LibLime---------------------------------- Providing Open-Source Solutions for Libraries Migration, Training, Maintenance and Support Featuring Koha ILS : http://liblime.com/koha --------------------------------------------- ----- "Cindy Murdock" <cmurdock@ccfls.org> wrote: | Hi Paul, | | While you're revisiting the issuing rules, you might want to consider | | moving renewalsallowed and possibly rentalcharge from itemtypes to | issuingrules. It would allow for more flexibility in large library | systems. Or maybe a syspref to control whether these fields are | defined | in itemtypes or issuingrules, for those libraries that don't need to | have differing rules on a per-library or per-patrontype basis? | | Cheers, | Cindy | | -- | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Cindy Murdock | Network Administrator | Meadville Public Library | CCFLS | http://meadvillelibrary.org | http://ccfls.org | | | _______________________________________________ | Koha-devel mailing list | Koha-devel@nongnu.org | http://lists.nongnu.org/mailman/listinfo/koha-devel
Ryan Higgins a écrit :
one more request:
change default branch to '*', so that all 'defaults' are handled the same way. this makes local modifs to the circ subs much easier to manage.
for those currently running '2.9x', a simple UPDATE issuingrules set branchcode='*' where branchcode=''; should suffice.
I have a syspref-governed mod to issuingrules to commit... it does require this change. Is there any reason to treat branchcode differently here, Paul?
nope. It's fixed (on the way to git-send-email the patch to chris) -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19
Cindy Murdock a écrit :
Hi Paul,
While you're revisiting the issuing rules, you might want to consider moving renewalsallowed and possibly rentalcharge from itemtypes to issuingrules. It would allow for more flexibility in large library systems. Or maybe a syspref to control whether these fields are defined in itemtypes or issuingrules, for those libraries that don't need to have differing rules on a per-library or per-patrontype basis?
Hi Cindy, i have fixed the issuing rules as explained, but could not handle your request atm. Can I suggest to fill en enhancement request to bugs.koha.org ? -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19
participants (6)
-
Cindy Murdock -
Ernesto Silva -
Joshua M. Ferraro -
Michael Hafen -
Paul POULAIN -
Ryan Higgins