Ceci est la traduction française d'une RFC rédigée originellement en anglais: System Groups.

Les fonctionnalités de Koha de gestion des succursales indépendantes permettent aux bibliothèques qui ont des succursales multiples ou aux consortium de bibliothèque d'obtenir un certain niveau de séparation entre les succursales. Par exemple, quand la gestion des succursales indépendantes est activée, un bibliothécaire ne peut faire des prêts que dans sa propre succursale ou bien ne voir que les commandes et les exemplaires de sa succursale.

Toutefois, la gestion des succursales indépendantes souffre de certaines limitations. D'un côté, la plupart des paramètres de la bibliothèque sont globaux : types de document, les modèles des avis, les règles de correspondance MARC, les préférences systèmes sont accessibles à toutes les succursales. Il serait intéressant que ces paramètres aient des valeurs différentes d'une succursale à l'autre. D'un autre côté, la gestion des succursales indépendantes peut restreindre de façon excessive la circulation entre succursales. Par exemple, si une bibliothèque partage Koha avec une autre bibliothèque, les deux bibliothèques peuvent très bien ne faire aucune circulation partagée de leurs ressources. Donc, ils activeront la gestion indépendante des succursales. Mais alors si la première bibliothèque a plus d'une succursale, elle ne pourra pas facilement faire de la circulation entre ses succursales sans représenter toutes ses succursales dans Koha en tant qu'une unique succursale Koha.

Afin d'améliorer le support par Koha de la séparation administrative entre plusieurs bibliothèques, LibLime propose d'implémenter quelque chose appeler “les groupes systèmes” (system groups). Les deux principaux concepts qui seraient ajoutés sont les suivants :

1. La possibilité de lier les paramètres à une succursale

Les paramètres peuvent être détenus par une succursale, c.-à-d. qu'ils auront des valeurs différentes dans chaque succursale. Les paramètres pouvant être détenus par une succursale sont les suivants :

• types de document
• catégories d'adhérent
• les paramètres d'acquisition comme les budgets et les monnaies
• une sélection de préférences systèmes
• les valeurs autorisées
• les modèles des avis (ceci est lié au RFC de Mason daté du 29 mai)
• les calendriers
• les règles de mise en correspondances des notices MARC

2. Relations parent-enfant entre succursales

Une succursale peut appartenir à une succursale parente et hériter ses paramètres de ses parents. Par exemple, supposons que deux bibliothèques indépendantes, la bibliothèque Dewey et la bibliothèque Ranganathan, partagent Koha. Supposons que la bibliothèque Dewey ait deux succursales : Melvyl et John. Les succursales John et Melvyl seraient les enfants de la bibliothèque Dewey. Les bibliothèques Dewey et Ranganathan seraient les enfants d'une supposée bibliothèque racine qui contiendra les paramètres globaux de toutes les succursales de la base de données.

Un calendrier de circulation peut être configurer pour la bibliothèque Dewey. La succursale John en hérite. Mais, si la succursale Melvyl est fermée le lundi et a besoin d'un calendrier différent, la succursale Melvyl peut détenir son propre calendrier qui re celui hérité de la bibliothèque Dewey.

Certains paramètres seront hérités mais non remplaçable. Par exemple, deux types de document sont définis pour Dewey et John peu en définir un troisième.

La paramètre “succursales indépendantes” tel qu'il fonctionne actuellement deviendrait un paramètre de niveau bibliothèque. Les bibliothèques Dewey et Ranganathan pourront avoir une circulation complètement indépendante, tandis que John et Melvyl autoriseront la circulation entre les deux succursales.

Les notices bibliographiques n'appartiendront pas à une succursale. Les bibliothèques Dewey et Ranganathan pourront partager les mêmes notices.

L'implémentation de ces fonctionnalités impliquent les changements suivants à la BD :

• une table pour suivre les relations parent-enfant entre les succursales
• l'ajout d'un succursale propriétaire à la plupart des tables qui contiennent des paramètres
• une table pour permettre à des membres du personnel d'avoir des privilèges sur plus d'une succursale

Les principaux changement à l'architecture du code de Koha comprennent :

• faire que partout où c'est nécessaire, Koha tienne compte de le succursale de l'opérateur ;
• réécriture du code si nécessaire afin de déplacer tous les accès aux paramètres dans la bibliothèque C4.

Les changements à l'interface :

• rendre les pages d'administration sensibles à la succursale de l'opérateur
• fare apparaitre à l'interface si un paramètre hérité de sa succursale parente est remplacé par celui d'un enfant

Afin que les groupes systèmes n'ajoutent pas une complexité inutile aux utilisateurs de Koha qui ont une seule bibliothèque, les garanties de compatibilité suivantes seront données :

• L'attribution de paramètres à une succursale sera optionnelle.
• Les relations parent-enfant entre succursales seront optionnelles.
• La nouvelle colonne d'attribution à une succursale aura la valeur NULL par défaut dans la base de données

De nombreux clients de Liblime (et d'autres fournisseurs) hébergeront dans une même base de données Koha plusieurs bibliothèques indépendantes les unes des autres. Pour mettre en œuvre ce type de configuration, ces clients ont besoin que des paramètres de l'application soient différents d'un groupe système à l'autre.

Dans ce document, un groupe système fait référence à une entité dont la configuration Koha et les paramètres peuvent être différents de ceux d'un autre groupe système.

Dans une base de données Koha dont la fonctionnalité de gestion des groupes systèmes est activée, il doit être possible d'avoir des valeurs distinctes d'un groupe système à l'autre pour les informations de configuration suivantes :

• les succursales, en ceci qu'une succursale ne peut appartenir qu'à un unique groupe système ;
• les fonds et les budgets ;
• les taux des monnaies et les taux de change. La liste de base des monnaies peut être partagée par la base entière, mais la liste active des monnaies et des taux de change doit être un attribut du groupe système ;
• les types de document. (Ceci suppose que les types de document de niveau exemplaire (item-level) sont activés.) ;
• les catégories d'adhérents ;
• les règles de circulation (la matrice des règles de prêt et d'amendes) :
• les valeurs autorisées, en particulier, au moins CCODE, LOC, Asort1, Asort2, Bsort1, Bsort2, STACK, SUGGEST, et éventuellement les statuts des exemplaires (LOST, DAMAGED, NOT_LOAN, WITHDRAWN) ;
• les sources de classification ;
• les règles de mise en correspondance des notices ;
• les imprimantes réseaux ;
• les hôtes Z39.50 ;
• divers préférences systèmes (voir le document paramètres globaux vs paramètres d'une bibliothèques) ;
• les modèles des étiquettes ;
• les calendriers ;
• les modèles des avis ;
• les déclencheurs d'avis.

Les types de données suivants doivent être spécifiques à un groupe :

• les exemplaires,
• les adhérents,
• les définitions des états guidés,
• guide report dictionary definitions,
• les nouvelles,
• les lots d'étiquettes,
• les lots de cartes de lecteur,
• les fils de modération des commentaires des adhérents (?),
• les lots d'importations MARC.

Les types de paramètres suivants doivent être globaux :

• les types de catégories d'emprunteur ;
• les frameworks des notices bibliographiques et autorités (on pourrait souhaiter que ceci soit un attribut de niveau groupe système mais pour le moment les notices bibliographiques et d'autorités n'auront aucune notion d'appartenance à un groupe) ;
• les mots vides ;
• des paramètres systèmes.

Pour le moment, il n'est pas clair si les paramètres suivants doivent être globaux ou de niveau groupe système :

• les villes des adhérents,
• les types de rue des adhérents.

• Il est admis que les notices bibliographiques sont partagées globalement et qu'il n'y aurait pas de sens à attribuer une notice bibliographique à un groupe système en particulier.
• Toutefois l'attribution à un groupe d'une notice bibliographique peut intéresser certains types de consortium.

Je propose d'étendre la notion de succursale de Koha afin d'implémenter les groupes systèmes. Une succursale peut maintenant avoir une succursale parent ou bien zéro ou plusieurs succursales enfant. En conséquence, la plupart des tables qui stockent des informations de configuration se verront ajouter une nouvelle colonne Succursale afin d'associer chaque paramètre à une succursale.

Une succursale appartiendra donc nécessairement à une hiérarchie et un groupe système consistera en une succursale en tous ses enfants. Il y aura une succursale implicite de plus haut niveau, ou racine, celle qui n'a aucun parent et qui contient toutes les succursales de la base de données Koha.

Par exemple, considérons le Consortium Présidentiel qui comprend les systèmes des bibliothèques Washington et Adams. Chaque bibliothèque a deux succursales (par ex. George, Martha, John et Abigail). La base de données Koha contiendra sept succursales :

1. Consortium Présidentiel (dont les enfants sont Washington et Adams)
2. Washington (dont les enfants sont George et Martha)
3. George (pas d'enfant)
4. Martha (pas d'enfant)
5. Adams (ses enfants sont John and Abigail)
6. John (pas d'enfant)
7. Abigail (sans enfant)

Settings associated with a branch can be inherited by its children. Settings will be classified as to whether they are aggregative or overridable. An aggregative setting, such as an item type list, is determined by starting with the current branch (e.g., John), then adding in values from its parent, its grandparent, and so on. An overridable setting can have only one value at a time (i.e., it does not consist of a list), and is determined by first seeing if the setting is explicitly defined for the branch of interest. If not, the parent is checked, and if the setting is not defined, the grandparent is checked, all the way up to the database-level branch.

Setting types will be classified as aggregative or overridable as follows:

• Funds and budgets - aggregative
• Currencies and exchange rates. The base list of currencies may be shared among the entire database, but the list of “active” currencies and exchange rates should be an attribute of the system group.
• Item types - aggregative
• Patron categories - aggregative
• Circulation rules - aggregative
• Authorized values - some aggregative, some overidable
• Classification sources - aggregative
• Record matching rules - aggregative
• Network printers - aggregative
• Z39.50 client targets - aggregative
• Various system preference - overridable

In most cases, the system group that is active for determining settings will be determined by using the branch that the operator is logged in as. However, for circulation rules, this needs more thought. Uniqueness of codes The following user-visible setting codes are currently unique values as enforced by database constraints:

• branches.branchcode
• itemtypes.itemtype
• aqbookfund.(bookfundid, branchcode)
• categories.categorycode
• class_sort_rules.class_sort_rule
• class_sources.cn_source
• currency.currency
• ethnicity.code
• letter.(module, code)

The following user-visible settings codes are currently non-unique

• authorised_values.authorised_value (nor is the combination of authorised_value and category a unique key)

Existing uniqueness constraints will be left as is. That means that there could be a situation where a system group administrator wants to use a particular code for a new item type but can't because another system group is already using it.