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

[Mike Rylander]

On Tue, Jan 10, 2012 at 12:39 PM, Thomas Berezansky <tsbere at mvlc.org> wrote:
> 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.
>

Related to the last two, there's also (if you choose to install it)
OpenSRF's docgen.xsl.  Here's an example (not even evergreen!):

http://fulfillment2.esilibrary.com/opac/extras/docgen.xsl

--miker

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



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