[OPEN-ILS-DEV] Question about separation of shared database
Mike Rylander
mrylander at gmail.com
Thu Mar 15 22:35:01 EDT 2007
On 3/15/07, Don McMorris <don.mcmorris at gmail.com> wrote:
> This is something going through my mind... I can think of a few
> scenarios where an "umbrella" library might exist sharing an ILS, but
> some data will need to be separated. For example, all participants in
> the umbrella could see all bib and item records, but it would be
> undesirable for patron information to be shared systemwide.
>
Right. There are other considerations, such as the requirement for a
unique barcode for items and patron cards. There are ways to deal
with this, but all of them are sub-optimal on some level.
> Here's an example... A library management company decides to build and
> host an ILS for libraries that outsource to them. They will ILL
> through each other, so all libraries' can see all bib/item records.
> However, user databases will be regional (or even library-specific).
>
> Another example... Another library management company decides to build
> and host an ILS for libraries that outsource to them. Everyone will
> see every bib record (but perhaps the PAC can be configured to not
> show bibs without any viewable items attached). Libraries in a
> specific region can see each others' item records for ILL purposes,
> but will not view item records for libraries outside that region.
> Patron databases are library-specific, though.
>
Permissions exist to restrict who can view patron records, and where.
Given a sufficiently deep hierarchy, yes, this can be restricted with
no problems (barring minor code adjustments).
> Is Evergreen configured so that (at the minimum) patrons' can be
> locked to certain libraries and not accessible by other libraries?
>
Now, there are certain interfaces that currently don't take this into
account (the patron search interface, for instance), but (and I'm just
blue-skying here -- Bill, don't shoot me) it should be an essentially
transparent change to restrict those interfaces.
The "big" problem would be giving the system the ability to use a
portion of the tree separate from the rest. There are certain places
that look for the root of the OU tree by finding a node with no
parent. This can be worked around by building an extra-OU institution
list that specifies the effective root, but that introduces issues for
extra-institution searching. ... it's a thorny problem, and we've
thought about it, but we don't have /all/ the answers yet.
> Thanks!
> --Don
>
--
Mike Rylander
mrylander at gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org
More information about the Open-ils-dev
mailing list