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

[Thomas Berezansky]

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.

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