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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
