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