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

[Thomas Berezansky]

As much as I can tell you exactly where it was, the better bet is for  
you to learn to find it yourself.

To that end, I give you the following hints:

1 - grep is your friend. Recursive grep moreso.

2 - The staff client and opac (and possibly other parts of the system)  
commonly assign the full method names to constants or other variables  
for ease of use later. You may need to grep for these alternate names  
after the initial method name search to find the actual points they  
are used in.

3 - If you can't find the actual method, it may be built via code and  
variables. Searching for the beginning (such as openils.actor.) with a  
regex wildcard followed by another part, such as the end of the  
method, may reveal where it is being assembled from variables.

4 - Drop '.atomic' from any method you are looking for that has it at the end.

Thomas Berezansky
Merrimack Valley Library Consortium


Quoting John Craig <jc-mailinglist at alphagconsulting.com>:

       Mike Rylander wrote:

> 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.

  Thanks for your reply, Thomas. Mike nailed it. The issue was clearly
related to registering a workstation. (Yes, I was talking about the
Staff Client login and the version in question is 2.0.9.)

The error I was getting:

         TypeError: g.my_libs_tree is null

I ended up checking every table that includes column names like
'%depth%' and changed anything that was > 0 to 0. After that, I
restarted everything on the Evg server, but it wasn't until I'd exited
from the Staff Client and restarted it that I got a clean login (ready
to register my workstation).

I appreciate the suggestions (the immediate problem is solved), but
could you point me to the spot in the code where the login sequence
for the Staff Client is occurring so in case I need to try to
troubleshoot this again, I can work through the code and see what the
problem might be myself?

Thanks much!

John

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 6783 (20120110) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com