[OPEN-ILS-DEV] Question about separation of shared database

[Don McMorris]

Just thinking of a potentially useful feature that would be nice if it
were there, but not necessary.  I have some ideas specifically for
patron security, but it'd be waaaay low on the priority list.

Thanks.
--Don

On 3/15/07, Mike Rylander <mrylander at gmail.com> wrote:
> 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
>