Branch Specific System Preferences
Recently the need has arisen locally to run the self-checkout (sco) under multiple user accounts to accommodate multiple branches using the sco module. To the best of my understanding this is not currently possible due to the way in which the user for the sco module is defined using a system preference. While there may be a number of ways to accomplish this, it seems that it may be desirable to have a category of "branch specific" system preferences. This would be an attempt to group system preferences into one of two general categories of "global" or "branch." Before launching out into writing such a feature, I thought I'd run it by both lists to see if a) I'm way off base, b) if such a feature is desirable, and c) if I'm off on an insanely hard project. Kind Regards, Chris
Chris, I've been meaning to write a Contextual Preferences Engine for Koha for a while now, to solve the problems we have with the Circ Matrix, as well as with global sysprefs that should really be more configurable. The idea is that it will be a DB table with 5 main columns: Branch, Patron Category, Item Type, Key and Value. Any of the first 3 can be a specific value or "default". If a contextual preference doesn't make sense to factor in one of the 3 values, it'll be ignored. This, along with a rewritten editor and rules tester tool, would solve a bunch of our customizability problems in one go, without necessarily introducing too much complexity for users (provided we make a good interface). I hope to have a patch for this started after 3.8 releases (and all our DB revs are stable for a while). Any help would be welcomed. -Ian 2012/3/22 Chris Nighswonger <cnighswonger@foundations.edu>
Recently the need has arisen locally to run the self-checkout (sco) under multiple user accounts to accommodate multiple branches using the sco module. To the best of my understanding this is not currently possible due to the way in which the user for the sco module is defined using a system preference. While there may be a number of ways to accomplish this, it seems that it may be desirable to have a category of "branch specific" system preferences. This would be an attempt to group system preferences into one of two general categories of "global" or "branch." Before launching out into writing such a feature, I thought I'd run it by both lists to see if a) I'm way off base, b) if such a feature is desirable, and c) if I'm off on an insanely hard project.
Kind Regards, Chris
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Hi Ian, On Thu, Mar 22, 2012 at 1:25 PM, Ian Walls <koha.sekjal@gmail.com> wrote:
Chris,
I've been meaning to write a Contextual Preferences Engine for Koha for a while now, to solve the problems we have with the Circ Matrix, as well as with global sysprefs that should really be more configurable.
The idea is that it will be a DB table with 5 main columns: Branch, Patron Category, Item Type, Key and Value. Any of the first 3 can be a specific value or "default". If a contextual preference doesn't make sense to factor in one of the 3 values, it'll be ignored.
Is the goal is to allow any or a defined set of system preferences to be "contextualized" based on branch, patron category, and/or item type?
This, along with a rewritten editor and rules tester tool, would solve a bunch of our customizability problems in one go, without necessarily introducing too much complexity for users (provided we make a good interface).
Agreed.
I hope to have a patch for this started after 3.8 releases (and all our DB revs are stable for a while). Any help would be welcomed.
Sounds good. I need this functionality to be in place by August of this year, so I'm very interested in getting started as soon as possible. I will be carving out time during my workday for it over the next several months. Kind Regards, Chris
Chris, I'm seeing the Contextual Preferences Engine (CPE) as a replacement to the issuingrules and related tables, first and foremost. It would be put in place, then be migrated into slowly over time by developers, since switching the subroutine calls from issuingrules and sysprefs to the CPE would be a good level change in a lot of different places. Users would not be able to contextualize a syspref on their own from the staff client; it would need to be a separate enhancement. The CPE just provides a unified platform for the developers to work with, making adding new context-sensitive behaviours easier to code. One major bonus is that each rule is granular and independent of other rules. Instead of having to maintain a huge circ matrix of rules and exceptions and exceptions to exceptions, you define you base case, then the few things that are different can be made different. The tester page will let you quickly confirm which rules you'll be getting in any given situation, so if there is any unexpected behaviour, you can trace it out. Rough implementation plan: Create new table in DB Create interface to manipulate values in table (get basics of templates and subroutines in place) Create interface to test which rules are applied to any given combo of Branch, Patron and Itemtype --- Up to here can be done behind the scenes without changing any other part of Koha --- Migrate over issuing rules Spruce up interface now that there is data Begin changing Circ subroutines to use CPE instead of smart rules Migrate over some sysprefs that need further contextualization (see bug for some that have been identified) --- much later --- Drop the smart rules pages and database tables once the migration is complete and stable. The first section could be completed by June very easily; that'd give us the CPE framework to work in, and it'd just be a matter of changing system calls to use it instead of whatever they're currently using. If that code is committed to master, then your need for per-branch SCO settings could be handled quickly before August. It would still need to wait until the next release in October before it's part of stable, but so would any kind of change like this. I hope this makes sense. As I said, any assistance, either in design, implementation or both, is welcome. I've been meaning to do this for a long while, but other things (like testing Hourly Loans) have taken priority recently. I'd love to have this in place for 3.10, to some degree or another. Cheers, -Ian On Thu, Mar 22, 2012 at 13:44, Chris Nighswonger < cnighswonger@foundations.edu> wrote:
Hi Ian,
On Thu, Mar 22, 2012 at 1:25 PM, Ian Walls <koha.sekjal@gmail.com> wrote:
Chris,
I've been meaning to write a Contextual Preferences Engine for Koha for a while now, to solve the problems we have with the Circ Matrix, as well as with global sysprefs that should really be more configurable.
The idea is that it will be a DB table with 5 main columns: Branch, Patron Category, Item Type, Key and Value. Any of the first 3 can be a specific value or "default". If a contextual preference doesn't make sense to factor in one of the 3 values, it'll be ignored.
Is the goal is to allow any or a defined set of system preferences to be "contextualized" based on branch, patron category, and/or item type?
This, along with a rewritten editor and rules tester tool, would solve a bunch of our customizability problems in one go, without necessarily introducing too much complexity for users (provided we make a good interface).
Agreed.
I hope to have a patch for this started after 3.8 releases (and all our DB revs are stable for a while). Any help would be welcomed.
Sounds good. I need this functionality to be in place by August of this year, so I'm very interested in getting started as soon as possible. I will be carving out time during my workday for it over the next several months.
Kind Regards, Chris
RFC up on the wiki: http://wiki.koha-community.org/wiki/Contextual_Preferences_RFC It's pretty rough... I got about 2 hours of it written yesterday, then my IP changed and I lost all my text when trying to submit. This rewrite is simplified, with the hopes of expanding further later. Another element I'm not sure how best to factor in: language. Especially for HTML blocks, it'd be handy to have a way to provide multiple options depending on the user's language. This isn't universally applicable to all preferences, only text-based values... thoughts? -Ian On Thu, Mar 22, 2012 at 3:46 PM, Ian Walls <koha.sekjal@gmail.com> wrote:
Chris,
I'm seeing the Contextual Preferences Engine (CPE) as a replacement to the issuingrules and related tables, first and foremost. It would be put in place, then be migrated into slowly over time by developers, since switching the subroutine calls from issuingrules and sysprefs to the CPE would be a good level change in a lot of different places. Users would not be able to contextualize a syspref on their own from the staff client; it would need to be a separate enhancement. The CPE just provides a unified platform for the developers to work with, making adding new context-sensitive behaviours easier to code.
One major bonus is that each rule is granular and independent of other rules. Instead of having to maintain a huge circ matrix of rules and exceptions and exceptions to exceptions, you define you base case, then the few things that are different can be made different. The tester page will let you quickly confirm which rules you'll be getting in any given situation, so if there is any unexpected behaviour, you can trace it out.
Rough implementation plan:
Create new table in DB Create interface to manipulate values in table (get basics of templates and subroutines in place) Create interface to test which rules are applied to any given combo of Branch, Patron and Itemtype
--- Up to here can be done behind the scenes without changing any other part of Koha ---
Migrate over issuing rules Spruce up interface now that there is data Begin changing Circ subroutines to use CPE instead of smart rules Migrate over some sysprefs that need further contextualization (see bug for some that have been identified)
--- much later ---
Drop the smart rules pages and database tables once the migration is complete and stable.
The first section could be completed by June very easily; that'd give us the CPE framework to work in, and it'd just be a matter of changing system calls to use it instead of whatever they're currently using. If that code is committed to master, then your need for per-branch SCO settings could be handled quickly before August. It would still need to wait until the next release in October before it's part of stable, but so would any kind of change like this.
I hope this makes sense. As I said, any assistance, either in design, implementation or both, is welcome. I've been meaning to do this for a long while, but other things (like testing Hourly Loans) have taken priority recently. I'd love to have this in place for 3.10, to some degree or another.
Cheers,
-Ian
On Thu, Mar 22, 2012 at 13:44, Chris Nighswonger < cnighswonger@foundations.edu> wrote:
Hi Ian,
On Thu, Mar 22, 2012 at 1:25 PM, Ian Walls <koha.sekjal@gmail.com> wrote:
Chris,
I've been meaning to write a Contextual Preferences Engine for Koha for a while now, to solve the problems we have with the Circ Matrix, as well as with global sysprefs that should really be more configurable.
The idea is that it will be a DB table with 5 main columns: Branch, Patron Category, Item Type, Key and Value. Any of the first 3 can be a specific value or "default". If a contextual preference doesn't make sense to factor in one of the 3 values, it'll be ignored.
Is the goal is to allow any or a defined set of system preferences to be "contextualized" based on branch, patron category, and/or item type?
This, along with a rewritten editor and rules tester tool, would solve a bunch of our customizability problems in one go, without necessarily introducing too much complexity for users (provided we make a good interface).
Agreed.
I hope to have a patch for this started after 3.8 releases (and all our DB revs are stable for a while). Any help would be welcomed.
Sounds good. I need this functionality to be in place by August of this year, so I'm very interested in getting started as soon as possible. I will be carving out time during my workday for it over the next several months.
Kind Regards, Chris
hi All i've just noticed all 3.6 (and 3.8) manuals are missing, here... http://download.koha-community.org/manual_pdf/ is there anything i can do to help fix this issue?
There are no PDFs of the 3.6 or 3.8 manual. There were issues with the script that generated PDFs (as far as I know) and so they aren't running anymore. Nicole On Thu, May 10, 2012 at 12:16 AM, Mason James <mtj@kohaaloha.com> wrote:
hi All
i've just noticed all 3.6 (and 3.8) manuals are missing, here... http://download.koha-community.org/manual_pdf/
is there anything i can do to help fix this issue?
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Nicole
There are no PDFs of the 3.6 or 3.8 manual. There were issues with the script that generated PDFs (as far as I know) and so they aren't running anymore.
Are those issues recorded anywhere, so people can try fixing? Thanks, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/
On Fri, May 11, 2012 at 6:25 AM, MJ Ray <mjr@phonecoop.coop> wrote:
Are those issues recorded anywhere, so people can try fixing?
MJ I can ask around - but like I said, I'm not the right person to be answering these questions :) I update the XML, push the patches, and they automagically post to the web in HTML :) Nicole
On 11 May 2012 15:23, Nicole Engard <nengard@gmail.com> wrote:
On Fri, May 11, 2012 at 6:25 AM, MJ Ray <mjr@phonecoop.coop> wrote:
Are those issues recorded anywhere, so people can try fixing?
MJ I can ask around - but like I said, I'm not the right person to be answering these questions :) I update the XML, push the patches, and they automagically post to the web in HTML :)
If someone is going to mess around with things in this area, could they please consider setting up an automated conversion to ePub format too? With dbtoepub it's as simple as this: $ dbtoepub -o /path/to/manual.epub /path/to/manual-in-git/en/manual.xml I have an old demo here: http://div.libriotech.no/kohaebook/ I have not found a good way to convert to .mobi yet, so please disregard those parts. Best regards, Magnus Enger libriotech.no
Le 10/05/2012 02:47, Ian Walls a écrit :
RFC up on the wiki: It's pretty rough... I got about 2 hours of it written yesterday, then my IP changed and I lost all my text when trying to submit.
do you know the Firefox extension called Lazarus ? It's pretty usefull for this kind of problem... -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Ian, Looking at your RFC, extending this onto language-centric sysprefs for the block-HTML stuff would be pretty easy; add a column "language" to the table you propose. For things like circ rules, it would be NULL, as language is not a factor there...and for the blocks of HTML, some of your columns (like itemtype) would be NULL. +1 for this new table. *D Ruth Bavousett* Lead Migration Specialist ByWater Solutions Support and Consulting for Open Source Software Headquarters: Santa Barbara, CA Office: Lawrence, KS Phone/Fax (888)900-8944 http://bywatersolutions.com ruth@bywatersolutions.com On Thu, May 10, 2012 at 3:47 AM, Ian Walls <koha.sekjal@gmail.com> wrote:
RFC up on the wiki: http://wiki.koha-community.org/wiki/Contextual_Preferences_RFC
It's pretty rough... I got about 2 hours of it written yesterday, then my IP changed and I lost all my text when trying to submit. This rewrite is simplified, with the hopes of expanding further later.
Another element I'm not sure how best to factor in: language. Especially for HTML blocks, it'd be handy to have a way to provide multiple options depending on the user's language. This isn't universally applicable to all preferences, only text-based values... thoughts?
-Ian
On Thu, Mar 22, 2012 at 3:46 PM, Ian Walls <koha.sekjal@gmail.com> wrote:
Chris,
I'm seeing the Contextual Preferences Engine (CPE) as a replacement to the issuingrules and related tables, first and foremost. It would be put in place, then be migrated into slowly over time by developers, since switching the subroutine calls from issuingrules and sysprefs to the CPE would be a good level change in a lot of different places. Users would not be able to contextualize a syspref on their own from the staff client; it would need to be a separate enhancement. The CPE just provides a unified platform for the developers to work with, making adding new context-sensitive behaviours easier to code.
One major bonus is that each rule is granular and independent of other rules. Instead of having to maintain a huge circ matrix of rules and exceptions and exceptions to exceptions, you define you base case, then the few things that are different can be made different. The tester page will let you quickly confirm which rules you'll be getting in any given situation, so if there is any unexpected behaviour, you can trace it out.
Rough implementation plan:
Create new table in DB Create interface to manipulate values in table (get basics of templates and subroutines in place) Create interface to test which rules are applied to any given combo of Branch, Patron and Itemtype
--- Up to here can be done behind the scenes without changing any other part of Koha ---
Migrate over issuing rules Spruce up interface now that there is data Begin changing Circ subroutines to use CPE instead of smart rules Migrate over some sysprefs that need further contextualization (see bug for some that have been identified)
--- much later ---
Drop the smart rules pages and database tables once the migration is complete and stable.
The first section could be completed by June very easily; that'd give us the CPE framework to work in, and it'd just be a matter of changing system calls to use it instead of whatever they're currently using. If that code is committed to master, then your need for per-branch SCO settings could be handled quickly before August. It would still need to wait until the next release in October before it's part of stable, but so would any kind of change like this.
I hope this makes sense. As I said, any assistance, either in design, implementation or both, is welcome. I've been meaning to do this for a long while, but other things (like testing Hourly Loans) have taken priority recently. I'd love to have this in place for 3.10, to some degree or another.
Cheers,
-Ian
On Thu, Mar 22, 2012 at 13:44, Chris Nighswonger < cnighswonger@foundations.edu> wrote:
Hi Ian,
On Thu, Mar 22, 2012 at 1:25 PM, Ian Walls <koha.sekjal@gmail.com>wrote:
Chris,
I've been meaning to write a Contextual Preferences Engine for Koha for a while now, to solve the problems we have with the Circ Matrix, as well as with global sysprefs that should really be more configurable.
The idea is that it will be a DB table with 5 main columns: Branch, Patron Category, Item Type, Key and Value. Any of the first 3 can be a specific value or "default". If a contextual preference doesn't make sense to factor in one of the 3 values, it'll be ignored.
Is the goal is to allow any or a defined set of system preferences to be "contextualized" based on branch, patron category, and/or item type?
This, along with a rewritten editor and rules tester tool, would solve a bunch of our customizability problems in one go, without necessarily introducing too much complexity for users (provided we make a good interface).
Agreed.
I hope to have a patch for this started after 3.8 releases (and all our DB revs are stable for a while). Any help would be welcomed.
Sounds good. I need this functionality to be in place by August of this year, so I'm very interested in getting started as soon as possible. I will be carving out time during my workday for it over the next several months.
Kind Regards, Chris
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Le 10/05/2012 02:47, Ian Walls a écrit :
RFC up on the wiki: http://wiki.koha-community.org/wiki/Contextual_Preferences_RFC A question: do we really need a new table ? I think that the systempreference table can be extended with those
columns, with a rule saying "branchcode/categorycode/itemtype = empty => default value"
For example: variable | branchcode | value LibraryName | | "Welcome to the union catalog" LibraryName |BRANCH1| "Welcome to branch 1, a library of the union catalog" The C4::Context->preference("LibraryName") would then be: SELECT * FROM systempreference WHERE variable="LibraryName" and branchcode=? if (fetchrow is empty) { return the result of SELECT * FROM systempreference WHERE variable="LibraryName" and branchcode IS NULL } -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Paul, Creating a new table allows us to develop this in parallel and commit progress incrementally without risking damage to the existing system (until we're ready to do the swapover, that is). It also forces us to review the subroutines that access this table, and make them clean in the Koha namespace. I think building new would be better here than modifying what we already have, since C4::Circulation is already pretty messy. Cheers, -Ian On Thu, May 10, 2012 at 8:15 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:
Le 10/05/2012 02:47, Ian Walls a écrit :
RFC up on the wiki: http://wiki.koha-community.org/wiki/Contextual_Preferences_RFC A question: do we really need a new table ? I think that the systempreference table can be extended with those
columns, with a rule saying "branchcode/categorycode/itemtype = empty => default value"
For example: variable | branchcode | value LibraryName | | "Welcome to the union catalog" LibraryName |BRANCH1| "Welcome to branch 1, a library of the union catalog"
The C4::Context->preference("LibraryName") would then be:
SELECT * FROM systempreference WHERE variable="LibraryName" and branchcode=? if (fetchrow is empty) { return the result of SELECT * FROM systempreference WHERE variable="LibraryName" and branchcode IS NULL }
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Le 10/05/2012 17:04, Ian Walls a écrit :
Paul,
Creating a new table allows us to develop this in parallel and commit progress incrementally without risking damage to the existing system (until we're ready to do the swapover, that is). does the new table REPLACE the systempreference one or is it added ? (If it's a replacement, then I'm OK)
It also forces us to review the subroutines that access this table, and make them clean in the Koha namespace. I think building new would be better here than modifying what we already have, since C4::Circulation is already pretty messy.
Unless i'm missing something, the accessor to preferences is centralized in C4::Context, and I don't see the relation to C4::Circulation. I agree that the switch to Koha namespace is a valid reason, but we must plan & define it clearly & with as many details as possible. Probably a topic for the hackfest next month... -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
This table could, theoretically, completely replace systempreferences. I'm not sure that's the best idea... but I can't really say why. If something should truly be global, then it could just be NULL/NULL/NULL for the context. We're going to be supplying context-sensitive keys in the each time we call, anyway, so we just won't for global things, or we won't supply itemtype for things that are univeral for item type, etc. I think that it should, however, completely replace issuingrules, and that's where I'm thinking most of the C4/Circulation changes would come in. -Ian On Thu, May 10, 2012 at 11:53 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:
Le 10/05/2012 17:04, Ian Walls a écrit :
Paul,
Creating a new table allows us to develop this in parallel and commit progress incrementally without risking damage to the existing system (until we're ready to do the swapover, that is). does the new table REPLACE the systempreference one or is it added ? (If it's a replacement, then I'm OK)
It also forces us to review the subroutines that access this table, and make them clean in the Koha namespace. I think building new would be better here than modifying what we already have, since C4::Circulation is already pretty messy.
Unless i'm missing something, the accessor to preferences is centralized in C4::Context, and I don't see the relation to C4::Circulation.
I agree that the switch to Koha namespace is a valid reason, but we must plan & define it clearly & with as many details as possible. Probably a topic for the hackfest next month...
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Le 22/03/2012 18:18, Chris Nighswonger a écrit :
Recently the need has arisen locally to run the self-checkout (sco) under multiple user accounts to accommodate multiple branches using the sco module.
Hi chris, I had the idea of just adding a "branchcode" column to the systempreferences and let the library define systempreferences for "" (default behaviour) or "specified branch" In C4->context(preference)->{anysyspref}, we could just do: SELECT * FROM systempreference WHERE variable="anysyspref" AND branchcode=<userbranchcode>; if no result SELECT * FROM systempreference WHERE variable="anysyspref" AND branchcode=""; Thus, any syspref could be not systemwide, but librarywide. That could be very nice to have, for example, the default library network logo if you're not logged in in OPAC, then your own library logo once you're logged in. Or css, or any syspref. For a few sysprefs that would be totally irrelevant to have "local" sysprefs (like MARC flavour or IndependantBRanches), but that's so obvious that I don't think we even should care in the code, just warn in the doc. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On Thu, Mar 22, 2012 at 1:39 PM, Paul Poulain <paul.poulain@biblibre.com>wrote:
Le 22/03/2012 18:18, Chris Nighswonger a écrit :
Recently the need has arisen locally to run the self-checkout (sco) under multiple user accounts to accommodate multiple branches using the sco module.
Hi chris,
I had the idea of just adding a "branchcode" column to the systempreferences and let the library define systempreferences for "" (default behaviour) or "specified branch"
I like the "KISS" approach, although I'm interested to hear a Ian's response to this thought. Kind Regards, Chris
participants (8)
-
Chris Nighswonger -
Ian Walls -
Magnus Enger -
Mason James -
MJ Ray -
Nicole Engard -
Paul Poulain -
Ruth Bavousett