On Tue, Jan 10, 2012 at 8:39 AM, Thomas Berezansky <[email protected]> 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 <[email protected]>: > > 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: [email protected] | web: http://www.esilibrary.com
