[OPEN-ILS-DEV] User permissions error

Robert glibrarysystem at gmail.com
Wed May 28 10:37:27 EDT 2008


Dan,

Here are the commands and the results:

evergreen=# update actor.org_unit set ou_type = 3 where parent_ou = 2;
UPDATE 11
evergreen=# select id, parent_ou, ou_type, shortname from actor.org_unit;
 id | parent_ou | ou_type | shortname
----+-----------+---------+-----------
  1 |           |       1 | CONS
  2 |         1 |       2 | SYS1
  8 |         4 |       3 | BKM
  4 |         2 |       3 | MAIN
  5 |         2 |       3 | XA
 18 |         2 |       3 | XW
 17 |         2 |       3 | XTR
 16 |         2 |       3 | XT
 15 |         2 |       3 | XS
 14 |         2 |       3 | XP
 13 |         2 |       3 | XM
 12 |         2 |       3 | XG
 11 |         2 |       3 | XFI
 10 |         2 |       3 | XB
(14 rows)

evergreen=# delete from actor.org_unit where id = 8;
ERROR:  update or delete on "org_unit" violates foreign key constraint
"copy_circ_lib_fkey" on "copy"
DETAIL:  Key (id)=(8) is still referenced from table "copy".

Also, that fixed the error that I was getting when I first went to the
register patron interface. Hooray! Thanks for all of the help and sorry
about all of the confusion. Guess I need to watch my DB entries a little
closer next time.

Jason,

  I too would rather find the problems and fix them rather than to just
reload a computer. If you fix them and understand why they happened you can
keep them from happening again. You can also help others that are having the
same problems and use that knowledge to figure other problems out.

On Wed, May 28, 2008 at 9:45 AM, Dan Scott <denials at gmail.com> wrote:

> Hi Robert:
>
> 2008/5/28 Robert <glibrarysystem at gmail.com>:
> > Here is the first output:
> >
> > evergreen=# select id, parent_ou, ou_type, shortname from actor.org_unit;
> >  id | parent_ou | ou_type | shortname
> > ----+-----------+---------+-----------
> >   1 |           |       1 | CONS
> >   2 |         1 |       2 | SYS1
> >   8 |         4 |       3 | BKM
> >  10 |         2 |       2 | XB
> >  11 |         2 |       2 | XFI
> >  12 |         2 |       2 | XG
> >  13 |         2 |       2 | XM
> >  14 |         2 |       2 | XP
> >  15 |         2 |       2 | XS
> >  16 |         2 |       2 | XT
> >  17 |         2 |       2 | XTR
> >  18 |         2 |       2 | XW
> >   5 |         2 |       2 | XA
> >   4 |         2 |       2 | MAIN
> > (14 rows)
>
> This is a problem.
>
> The children of node ID 2 (SYS1) have the same ou_type as their parent
> (ou_type = 2). But the ou_type is a pointer to the actor.org_unit_type
> table, and each of the entries in the actor.org_unit_type table has a
> specific depth in the hierarchy. So actor.org_unit.id 2 (SYS1) with an
> ou_type of 2 has an actor.org_unit_type.depth of 1, and
> actor.org_unit.id 10 (XB) with an ou_type of 2 also has an
> actor.org_unit_type.depth of 1, even though as a child of SYS1 it is
> at depth 2 in the hierarchy.
>
> If your actor.org_unit_type table is still the same as was delivered
> at install time, you probably want to update all rows in
> actor.org_unit that are children of node 2 to have an ou_type of 3.
> You could issue the following statement via psql:
>
> UPDATE actor.org_unit SET ou_type = 3 WHERE parent_ou = 2;
>
> Another problem is that the actor.org_unit.id 8 (BKM) entry has a
> parent_ou value of 4, even though there is no entry in the
> actor.org_unit table with an id of 4. You probably want to simply
> delete that entry:
>
> DELETE FROM actor.org_unit WHERE id = 8;
>
> --
> Dan Scott
> Laurentian University
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.georgialibraries.org/pipermail/open-ils-dev/attachments/20080528/a132358c/attachment-0001.html


More information about the Open-ils-dev mailing list