[OPEN-ILS-DEV] Where's the call to get org_unit descendants?

[Mike Rylander]

On Tue, Jan 10, 2012 at 8:39 AM, Thomas Berezansky <tsbere at mvlc.org> wrote:
> I am running on the assumption that the login sequence in question is via
> the staff client, as I don't think the OPAC ever makes that call during
> login.
>
> I think the call in question is likely when your workstation needs to be
> registered, which is looking for every location you have
> 'REGISTER_WORKSTATION' at.
>

Good call, Thomas.  I think this is the key, but what follows after is
not (I believe) relevant.  I strongly suspect that you have group
permission entries (and possibly user permission entries) with a depth
of 2, which is invalid in your hierarchy.  If you 'UPDATE
permission.grp_perm_map SET depth = 1 WHERE depth = 2;' (possibly
needing a service restart due to caching effects, but maybe not) I bet
all will be well.

> The call you are reporting problems with is made based on the types of the
> OUs returned where you have that permission. Thus, my assumption is that you
> have a bad entry in your OU type table, or that you have a bad OU entry. I
> am not sure which.
>
> I don't think having not run autogen.sh would cause that error.
>
> Without more information, like dumps of your OU and OU Type tables and the
> actual returned error message (if any), I can't say much more about why you
> would be getting an error on that call.
>
> Thomas Berezansky
> Merrimack Valley Library Consortium
>
>
>
> Quoting John Craig <jc-mailinglist at alphagconsulting.com>:
>
>     Hi Folks,
>
> In trying to troubleshoot some issues that appear to be related to an
> org unit hierarchy that's one I've never tried before, I can see that
> the login sequence is going wrong when it calls
> open-ils.actor.org_tree.descendants.retrieve (implemented in Actor.pm
> as sub get_org_descendants)--it's getting passed an apparently
> nonsensical value to the depth parameter (the hierarchy only has two
> levels 0 & 1 and it's getting called with 2--presumably should be
> zero; nothing has a depth of 2...).
>
> What I haven't been able to figure out is where this method is being
> called *from* (so I can see if I can figure out what about the data in
> org_unit is being misinterpreted or what's wrong with my data).
>
> Could some kind, in-the-know person point me to where that call
> originates?
>
> Based on a Pg log, it calls a select on org_unit joined with
> org_unit_type--and should be getting the depth values I expect:
>
> SELECT "aout".can_have_users, "aout".can_have_vols, "aout".depth,
> "aout".id
>     , oils_i18n_xlate('actor.org_unit_type', 'aout', 'name', 'id',
> "aout".id::TEXT, 'en-US') AS "name"
>     , oils_i18n_xlate('actor.org_unit_type', 'aout', 'opac_label',
> 'id', "aout".id::TEXT, 'en-US') AS "opac_label"
>     , "aout".parent
>  FROM actor.org_unit_type AS "aout"
>  WHERE "aout".id IS NOT NULL;
>
> This apparently returns the expected values for depth (0, 1). And that
> seems to be the only spot in the login sequence where it's reading the
> depth.
>
> If I could see what it's doing with the values it gets back, maybe I
> could figure out why it's inventing the 2....
>
> John
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 6780 (20120109) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>



-- 
Mike Rylander
 | Director of Research and Development
 | Equinox Software, Inc. / Your Library's Guide to Open Source
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com