RFC 3.2 - system groups and extending independent branches
The independent branches feature in Koha 3.0 gives multi-branch or consortial users of Koha the ability to achieve some separation between branches. For example, with independent branches turned on, a staff user can circulate only within their own branch and only see orders and item records from their own branch. However, independent branches currently has some limitations. On the one hand, most library parameters are global; things like item types, notice templates, MARC matching rules, system preferences, etc., are accessible to all branches, but it would be useful if these settings could have different values from one branch to the next. On the other hand, independent branches can restrict circulation between branches too much. For example, if a library is sharing a Koha database with another library, the two libraries may not do any shared circulation of their materials, and therefore would turn independent branches on. However, if the first library has more than one branch, that library cannot readily circulate between its branches without representing all of its physical branches as a single Koha branch. To improve the ability of Koha to support administrative separation of multiple libraries, LibLime proposes to implement something we're calling system groups. The two main concepts that would be added are: 1. Adding the ability to link settings to a branch. This means that a setting can be "owned" by a branch, i.e., have one value or set of values at one branch and a different value at another. Settings that could be owned by a branch include: * item types * patron categories * acquisitions settings such as funds and currencies * selected system preferences * authorized values * notice templates (note that this is related to Mason's RFC of May 29). * calendars * MARC record matching rules 2. Allow parent-child relationships between branches. This means that a branch can belong to a parent branch, and inherit settings from its parent. For example, suppose two independent libraries, the Dewey Library and the Ranganathan Library, share a Koha database. Furthermore, suppose that the Dewey Library has two branches, Melvyl and John. The John and Melvyl branches would be "children" of the Dewey Library. The Dewey Library and Ranganathan Library would be children of a notional root library, which holds global settings for all branches in the database. A circulation calendar could be set for Dewey. The John branch would then inherit it. However, if we suppose that the Melvyl branch is closed on Mondays, and needs a different calendar, the Melvyl branch could own its own calendar, overriding the one inherited from Dewey. Some settings would be inherited but not overridable. For example, two item types could be defined for Dewey, and John could also define a third one. The independent branches setting as it affects circulation would then become a library setting - Dewey and Ranganathan could have completely separate circulation, while John and Melvyl could allow circulation between the two branches. Bibliographic records would not have branch ownership - the Dewey and Ranganathan libraries could share the same pool of bib records. The implementation of this feature would be include the following changes to the database: * the establishment of a table to track parent-child relationships between branches * the addition of a branch ownership fields to most tables that contain settings * the addition of a table to allow a staff operator to have privileges at more than one branch. The main changes to Koha's code architecture would include * Making most lookups of settings take the operator's branch into account. * Refactoring as needed to move all settings lookups into C4. The main UI changes would include * Making the Administration pages sensitive to the operators branch. * UI changes to make it apparent when a setting inherited from a parent branch is overridden by a child. To ensure that system groups does not add unnecessary complication to Koha users that have a single library in their database, the following compatibility requirements will be met: * Branch ownership of settings will be an option. * Parent-child relations between branches will be an option. * In the database, the default value for the new branch ownership columns will be NULL. For more information on this proposal, please consult the Koha wiki at http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_system_groups 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
Very interesting! Here are my immediate thoughts. Is a multi-level branches hierarchy via parent-child relationship really necessary? Do you really plan to have something like that? (with your example): Dewey Library John branch John-John sub-branch Caroline sub-branch Melvil branch Ranganathan Library I see 3 obvious levels, no more, in the vast majority of situations: 1. Koha -- global settings 2. Library -- settings for each library 3. Branch -- branches belong to one library inherit parameters from it and can override some of them Then you enable/disable multi-libraries, multi-branches functionalities. _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Hi, On Mon, Jun 9, 2008 at 12:03 PM, Frédéric DEMIANS <f.demians@tamil.fr> wrote:
I see 3 obvious levels, no more, in the vast majority of situations:
1. Koha -- global settings 2. Library -- settings for each library 3. Branch -- branches belong to one library inherit parameters from it and can override some of them
Deeper hierarchies are not implausible. For example, a Koha database used by a consortium of academic libraries could have six levels: Consortium (Koha DB) : University : Campus : Library : Branch : Circulation/Reserve Desk While I admit this is a stretch, I didn't want to arbitrarily limit the maximum depth of the hierarchy, nor require that any user specify a fixed number of levels. For example, my former home state of Alaska has a lot of mixed library consortia, i.e., consortia that are based on geographic area and can have academic, public, historical society, and school libraries as members. In such a consortium, the academic library may want four or five levels, while the public library needs only two, and the historical society one. With the proposed parent/child structure, there is no need to require that the tree of libraries and branches be balanced, thus allowing "simple" and "complicated" libraries coexist in the same database. The other advantage of a parent/child structure is that except for the special case of the global level, most code will not have to care about what level of organization it's dealing with at the moment - it just has to know what the current branch is. Further, you don't have to have separate library and branch entities - a library and branch are the same thing from the point of view of the code, i.e., an entity that can have policy settings, own items, and circulate, and have parents and children. 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
Deeper hierarchies are not implausible. For example, a Koha database used by a consortium of academic libraries could have six levels:
Consortium (Koha DB) : University : Campus : Library : Branch : Circulation/Reserve Desk
Thank you for this explanation. I appreciate to learn more about consortium problematics. Being on the question of system parameters, and improvement, can I ask about current Koha syspref management? Parameters are retrieved by Perl scripts from systempreferences table. This table is read and re-read and re-re-read multiple times for sysprefs. Wouldn't it better to have application-wide constants which would be retrieved by perl script? You could create an hierarchical data structure, stored in server RAM, directly accessed by program, which could be map into a XML config file. Easier to browse that DB tables, isnt'it. Here is the picture: <site> <name>Alaska Consortium</name> ... <syspref id="AmazonTag">kdsflkdsl</syspref> <syspref id="... ... <libraries> <libray> <name>Frozen University</name> <syspref id="AmazonKey">...</syspref> ... <libraries> <library> <name>South Campus</name> <syspref id="... </library> <library> <name>East Campus</name> </library> </libraries> </lbrary> <library> <name>Ice Cube University</name> <syspref id="AmazonKey">...</syspref> ... </library> </lbraries> </site> My 2c! _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
This sounds brilliant. How about being able to customise certain things (Add/Edit user page) to show/hide fields depending on which branch/group you are a member of. For example : Library 1 might only need First name, Surname and Email address where as Library 2 might require full address details. A simple way to do it would be to have a syspref which allows Branches/Groups to change the template file used for certain pages. For example : Memberentrytpl = library1memberentry.tpl However a more sophisticated way to do it would be to provide an interface so an admin can tick which boxes they want shown on add/modify/other page. - L -----Original Message----- From: koha-devel-bounces@lists.koha.org [mailto:koha-devel-bounces@lists.koha.org] On Behalf Of Galen Charlton Sent: 09 June 2008 16:22 To: Koha Devel Mailing List Subject: [Koha-devel] RFC 3.2 - system groups and extending independent branches The independent branches feature in Koha 3.0 gives multi-branch or consortial users of Koha the ability to achieve some separation between branches. For example, with independent branches turned on, a staff user can circulate only within their own branch and only see orders and item records from their own branch. However, independent branches currently has some limitations. On the one hand, most library parameters are global; things like item types, notice templates, MARC matching rules, system preferences, etc., are accessible to all branches, but it would be useful if these settings could have different values from one branch to the next. On the other hand, independent branches can restrict circulation between branches too much. For example, if a library is sharing a Koha database with another library, the two libraries may not do any shared circulation of their materials, and therefore would turn independent branches on. However, if the first library has more than one branch, that library cannot readily circulate between its branches without representing all of its physical branches as a single Koha branch. To improve the ability of Koha to support administrative separation of multiple libraries, LibLime proposes to implement something we're calling system groups. The two main concepts that would be added are: 1. Adding the ability to link settings to a branch. This means that a setting can be "owned" by a branch, i.e., have one value or set of values at one branch and a different value at another. Settings that could be owned by a branch include: * item types * patron categories * acquisitions settings such as funds and currencies * selected system preferences * authorized values * notice templates (note that this is related to Mason's RFC of May 29). * calendars * MARC record matching rules 2. Allow parent-child relationships between branches. This means that a branch can belong to a parent branch, and inherit settings from its parent. For example, suppose two independent libraries, the Dewey Library and the Ranganathan Library, share a Koha database. Furthermore, suppose that the Dewey Library has two branches, Melvyl and John. The John and Melvyl branches would be "children" of the Dewey Library. The Dewey Library and Ranganathan Library would be children of a notional root library, which holds global settings for all branches in the database. A circulation calendar could be set for Dewey. The John branch would then inherit it. However, if we suppose that the Melvyl branch is closed on Mondays, and needs a different calendar, the Melvyl branch could own its own calendar, overriding the one inherited from Dewey. Some settings would be inherited but not overridable. For example, two item types could be defined for Dewey, and John could also define a third one. The independent branches setting as it affects circulation would then become a library setting - Dewey and Ranganathan could have completely separate circulation, while John and Melvyl could allow circulation between the two branches. Bibliographic records would not have branch ownership - the Dewey and Ranganathan libraries could share the same pool of bib records. The implementation of this feature would be include the following changes to the database: * the establishment of a table to track parent-child relationships between branches * the addition of a branch ownership fields to most tables that contain settings * the addition of a table to allow a staff operator to have privileges at more than one branch. The main changes to Koha's code architecture would include * Making most lookups of settings take the operator's branch into account. * Refactoring as needed to move all settings lookups into C4. The main UI changes would include * Making the Administration pages sensitive to the operators branch. * UI changes to make it apparent when a setting inherited from a parent branch is overridden by a child. To ensure that system groups does not add unnecessary complication to Koha users that have a single library in their database, the following compatibility requirements will be met: * Branch ownership of settings will be an option. * Parent-child relations between branches will be an option. * In the database, the default value for the new branch ownership columns will be NULL. For more information on this proposal, please consult the Koha wiki at http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_system_groups 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 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
participants (3)
-
Frédéric DEMIANS -
Galen Charlton -
Lloyd Palfrey