[Koha-devel] RFC 3.2 - system groups and extending independent branches

Galen Charlton galen.charlton at liblime.com
Mon Jun 9 17:21:35 CEST 2008


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 at liblime.com
p: 1-888-564-2457 x709
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha.org
http://lists.koha.org/mailman/listinfo/koha-devel



More information about the Koha-devel mailing list