Evergreen ILS Website

IRC log for #evergreen, 2014-07-09

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
02:49 mtj_ joined #evergreen
02:54 riot joined #evergreen
03:43 RBecker joined #evergreen
05:26 dcook joined #evergreen
05:49 _eric__ joined #evergreen
05:53 _eric__ Hi. I have a question about MARCH batch edit. I would like to change indicator of a specific marc field. e.g. if it is "100 \1 $a", how would I make it "100 21 $a"?
06:11 _eric__ Also, when I want to create a bucket and run a query, the resulting list seems to be limited to 100 entries only.
07:07 Silva joined #evergreen
07:29 RBecker joined #evergreen
07:37 berickm joined #evergreen
07:59 Dyrcona joined #evergreen
08:07 rjackson-isl joined #evergreen
08:07 krvmga joined #evergreen
08:12 akilsdonk joined #evergreen
08:21 Dyrcona joined #evergreen
08:25 RoganH joined #evergreen
08:44 tspindler joined #evergreen
08:47 ericar joined #evergreen
08:52 kbeswick joined #evergreen
08:55 Shae joined #evergreen
08:56 krvmga where does the code for the staff client patron edit/registration screen live?
08:58 mmorgan joined #evergreen
08:58 tsbere krvmga: Given the split up nature of some of that perhaps an indication of your goal would be a better place to start
08:59 krvmga tsbere: i just want to try and understand how it works.
09:00 tsbere krvmga: Unless you have a specific goal in mind I wouldn't bother at this point in time. Going at that without one can create headaches. ;)
09:00 mrpeters joined #evergreen
09:03 krvmga tsbere: i only recently got to see the documentation on the first web-client-related code sprint. i saw in there that the patron edit/registration wasn't going to be touched at all but just included as is. Since this is a major pain point for staff in our consortium, webifying the client won't matter much to them if this doesn't get looked at. so i wanted to look.
09:03 tsbere krvmga: Given that the interface in question is technically a web page already with no XUL elements I am aware of I understand why it isn't being touched
09:06 krvmga tsbere: i just saw an email on the openils general list that improvement of the patron edit/registration interface will not improve and that this is currently not being addressed.
09:06 krvmga that sentence didn't come out right :)
09:06 csharp krvmga: what are the pain points for your staff?
09:06 krvmga csharp: slow performance
09:07 krvmga loads and saves slowly
09:08 csharp so when I go to Circulation -> Register Patron on our system, the page loads within a few seconds - is that not the case for your staff?
09:08 mmorgan krvmga: not sure how it all works, but two files seem like they should be related: user_edit.js and user_edit.xul in /openils/var/web/xul/server/patron
09:09 krvmga sec
09:09 tsbere mmorgan: No, I believe those are the old interface.
09:09 csharp mmorgan: I think those are legacy - the current interface is in dojo/JS
09:09 mmorgan ok, good to know!
09:09 csharp (I meant they are implemented in dojo/Javascript - that's not a file path ;-) )
09:10 krvmga csharp: takes 9 seconds to load
09:10 tsbere and the current interface is a combination of template toolkit, dojo, and javascript.
09:10 csharp krvmga: more like 3 seconds for me
09:10 tsbere krvmga: Do you have a lot of patron stat cats?
09:11 krvmga tsbere: i believe we do
09:11 tsbere krvmga: Loading *those* may be the slowdown. Especially if there are also lots of pre-defined entries for them.
09:11 csharp krvmga: can you rule out local network issues for that load time?  (I'm on a 20mb/s connection without any congestion)
09:12 krvmga csharp: yes, network issues ruled out
09:14 csharp when I create a patron and save, it's about 5 seconds turnaround between clicking save and when the new page is fully loaded
09:14 csharp we have 3 stat cats if that makes a difference
09:15 krvmga csharp: just been testing loading/reloading; the quickest i can get the page is 7 seconds
09:16 csharp krvmga: how many stat cats? and how many entries per stat cat?  I can create a few and see if that adds to load time
09:16 csharp rough estimate's fine
09:17 krvmga csharp: two dozen
09:17 csharp krvmga: do you think your staff is complaining about 7 - 8 seconds load time? or is it longer for them?
09:17 csharp yowza
09:18 tsbere csharp: I haven't looked at the code recently, but I suspect the entries on the stat cats are a factor as well.
09:18 krvmga csharp: i think that it's longer for some of them and, in some of their cases, their network may be exacerbating the problem
09:19 dbwells krvmga: the JavaScript engine in our version XULRunner is past its prime, so I wouldn't rule out seeing some modest improvements from simply loading the current code in, say, a modern version of Chrome.  That said, your speed is far enough out of the norm that a few ms here and there might not mean much.
09:19 csharp I can say for sure that our libraries complain about load time for that interface, but it appears to be purely network related in their cases
09:19 csharp and since most of our libraries are moving to high-bandwidth ISPs right now, I expect those situations to improve
09:20 dbwells krvmga: You can more or less try it out right now by browsing to https://[your server]/eg/actor/user/register
09:20 RoganH joined #evergreen
09:20 krvmga sec
09:21 csharp yeah - that's way faster in Firefox 30 (on Ubuntu) than in the staff client
09:21 csharp probably twice as fast in my case
09:22 csharp and nearly instantaneous in Chrome OMG
09:22 csharp web_client++
09:23 csharp krvmga: so you can tell your staff that the web client will be a huge improvement, even without code changes
09:24 csharp though the stat cat issue may have to be managed
09:24 csharp any idea why they need so many?
09:25 krvmga csharp: i've been showing them (at user group meetings) but, since i can't show the patron edit/registration part in the demo, they haven't seen that
09:25 yboston joined #evergreen
09:25 tsbere csharp/krvmga: I am curious about the results of this query for each of you with suitable library IDs filled in. http://pastebin.com/nY4qeEDQ
09:26 krvmga dbwells: thanks for that link. i tried it out. after logging in, each screen reload took about 12 seconds.
09:27 dbwells krvmga: thanks for the feedback.  I think the stat cat thread is your best bet to follow.
09:28 dbwells That could very easily be a DB indexing or volume of data transfer issue, and not really a client problem at all.
09:29 dbwells At least not directly.
09:29 RoganH joined #evergreen
09:30 csharp tsbere: in my case at the State Library, the results are 3 and 6
09:30 csharp I'm trying to see if there are libraries out there using more
09:30 jeff tsbere: 11 stat cats with 220 entries here.
09:31 csharp jeff: do you have long load times for the patron editor?
09:31 jeff mostly due to a home/work/school township designation.
09:31 * tsbere can get 8 or 9 with a couple thousand entries
09:31 krvmga i've asked tspindler to take a look and maybe chime in because he knows this area of our consortium better than i do.
09:31 jeff i am unhappy with the performance of the patron editor, and I have seen it take >10s to load. me being unhappy with the performance is perhaps not the best metric, though.
09:32 jeff that is to say, i feel that i sometimes have unrealistic performance expectations for software.
09:32 mmorgan jeff: if you are unhappy, your end users most certainly are too ;-)
09:32 krvmga sudo make me a sandwich
09:33 krvmga <xkcd refeence>
09:33 krvmga reference
09:34 krvmga http://xkcd.com/149/
09:34 Dyrcona jeff: Many users expect things to be nearly instantaneous. Google sets a high bar. ;)
09:35 krvmga Dyrcona: i think they also compare the staff client performance with other desktop application performance.
09:35 tspindler We have 21 stat cats spread on 18 org units with 138 total stat cat entries, the biggest one is 29 entries but on average they have 7 entries but the median would  less
09:35 Dyrcona On an unrelated note, I'm trying to figure out if there is some way I can determine the version of Evergreen run on another site.
09:35 krvmga Dyrcona: isn't there a magic spell for that?
09:35 Dyrcona krvmga: I'm sure that they do, but the staff client is really a web application, even now.
09:35 tsbere Dyrcona: You can tell numbered versions, but not if they install from master.
09:36 tsbere Or rather, if they install from master, not when/what commit they installed from
09:36 Dyrcona krvmga: I think there is, but I can't find it with introspect.
09:36 Dyrcona tsbere: Do tell. ;)
09:36 csharp Dyrcona: http://gapines.org/gateway?service=open-ils.acto​r&amp;method=opensrf.open-ils.system.ils_version
09:37 krvmga http://acq.open-ils.org/gateway?se​rvice=open-ils.actor&amp;method=op​ensrf.open-ils.system.ils_version
09:37 krvmga Dyrcona: is that it?
09:37 Dyrcona krvmga: Yes, I think that is.
09:37 collum joined #evergreen
09:38 Dyrcona krvmga++
09:38 Dyrcona And now, I'm going to run that on your server, krvmga! :)
09:39 krvmga lol
09:39 krvmga you'll get 2.5.x (something)
09:40 Dyrcona 2.5.5
09:40 RBecker joined #evergreen
09:40 krvmga yup
09:40 csharp we're 2.5.1 with some backported patches, which is how we roll
09:43 jeffdavi1 joined #evergreen
09:46 pmurray_away joined #evergreen
09:46 rangi` joined #evergreen
09:47 Dyrcona And my server just says "HEAD" :)
09:47 Dyrcona because git! ;)
09:50 jboyer-isl Can't that be changed with a makefile option?
09:51 csharp @karma netsplit
09:51 pinesol_green csharp: netsplit has neutral karma.
09:53 tspindler joined #evergreen
09:54 mmorgan joined #evergreen
09:54 board joined #evergreen
09:55 jboyer-isl csharp: Are you using a postgresql log analyzer down there? I think you've told me the name of one but it's slipped my mind.
09:56 eeevil joined #evergreen
09:58 paxed joined #evergreen
09:58 berick joined #evergreen
09:59 tspindler I just got rid of the uneeded stat cats from the instituition that is no longer a member and it took off 1 or 2 seconds on the load time.
10:00 krvmga it was a noticeable difference
10:00 csharp jboyer-isl: pgfouine - it's a php-based analyzer
10:00 csharp jboyer-isl: there's also perl-based pgbadger, but I've not used it
10:01 csharp jboyer-isl: check with mrpeters/awitter about our setup
10:01 tspindler However, from an end user standpoint.  It seems the impact on performance is significant for a relatively small number of stat cats.
10:01 jboyer-isl pgbadger is the one. I knew there was a 'b' in it but pgfouine was the only one I was finding. :) I'll check the both out, thanks for the reminder.
10:02 tsbere tspindler: We have a lot more stat cat entries but don't have nearly the performance impact.
10:02 jboyer-isl csharp++
10:02 csharp jboyer-isl: happy to help!
10:05 tspindler tsbere: that is interesting
10:05 tspindler tsbere: I don't know enough to indicate why there would be this difference
10:06 tspindler tsbere: do you have larger number of entries spread over fewer stat cats, are they only at MVLC level?
10:07 jeff iirc, there is a decent amount of time spent every time you load the patron editor checking the current staff user's group application permissions so that the permission profile drop-down can be populated. Thus, a large number of profiles defined may lead to longer load times.
10:07 tsbere tspindler: We have some library specific ones, 8 (I believe) global ones, and number of entries varies from library to library even on the global ones.
10:08 jeff so i'd be interested to know if this query shows a small number for those reporting faster performance in the user editor: select count(*) from permission.grp_tree;
10:08 jeff in our case, we have 64 profiles defined, and I've been looking to trim them up a bit.
10:08 bshum "small" being relative I suppose ;)
10:08 jeff (as many are leftovers)
10:08 tspindler jeff: does that include patron profiles?
10:09 jeff bshum: relative to those reporting different performance, of course. :-)
10:09 jeff tspindler: it's all user profiles -- staff and patrons.
10:09 tspindler we have 154
10:10 tsbere jeff: How about SELECT count(id), count(distinct application_perm) FROM permission.grp_tree;
10:10 tsbere MVLC has 24 groups, but only 13 application_perms
10:10 jeff 64/19 here
10:11 bshum 62 / 18 for us
10:12 * bshum is not used to being on the low end of something that could have been configured to the crazy end of the spectrum...
10:13 tspindler 154/16
10:15 pastebot joined #evergreen
10:16 mllewellyn joined #evergreen
10:17 jeff okay, and thankfully this isn't a situation where there's a request made for each application perm, so it's mostly the bulk of and server side processing for getting the permission group objects, then a batch permission check for all of the unique group application perms.
10:20 mmorgan 130/20 here
10:21 jeff 13s to load in Chrome
10:22 jeff stat cats request takes ~1.6s
10:23 jeff the 404 for register_custom.css took >6s. Huh.
10:24 jeff that could be a quirk of the chrome dev tools.
10:24 jeff there are 131 http requests to load the page.
10:26 Dyrcona Well, that sounds like a lot for something without 100 thumbnail graphics on it. :)
10:27 jeff well, there are at least 13 images loaded. :-)
10:27 jeff anyway, it is a prime candidate for further work. :-)
10:28 jeff the seven 404s don't help, either.
10:28 bshum I had no 404s, whee!
10:29 csharp those also result in useless log noise
10:29 csharp (one issue at a time though ;-))
10:29 jeff and they are non-cacheable at the client.
10:29 csharp bshum: so do you use register_custom.css?
10:29 bshum Mine is empty.
10:29 csharp or did you just touch an empty file
10:29 csharp ok
10:29 bshum But it exists I guess
10:30 csharp I wonder if that helps load time
10:30 bshum Probably just trying to avoid log noiseas you say
10:30 tsbere We have a register_custom.css that only loads in some circumstances. <_<
10:31 jeff i suspect register_custom.css's 404 taking >6s may be a measurement quirk. the bulk of the time shown is spent "Receiving", and its finish time seems to correspond with the "Load" marker on the timeline.
10:34 csharp hmm /js/dojo/openils/User/nls/en/User.js and js/dojo/openils/User/nls/en-us/User.js not only don't exist but neither do their directories :-/
10:35 bshum Common quirk
10:35 csharp s/quirk/bug/ ?
10:35 csharp I don't know enough about i18n to know whats required
10:38 bshum Well, since the client works in english by default, I don't think it's "required" per say.  But I think it's something strange that results from not specifying en-US directly in our building processes.
10:38 bshum But I'm super rusty in this area
10:38 bshum I get to relearn how to make a release tomorrow ;)
10:39 bshum I asked about it once during 1.6/2.0 era.  Before I moved onto other topics.
10:39 tsbere I know that if I create "en-US" translations they work. It is just that our default is already en-US so we don't normally build them.
10:42 Dyrcona en-US translations are one way to customize your strings, just if you haven't thought of doing it that way.
10:43 RoganH joined #evergreen
10:45 eeevil csharp: the way dojo does translations, it looks from most specific to least, using the first it finds. IOW, don't create an empty file for translations :)
10:45 kbutler joined #evergreen
10:46 eeevil though, you could symlink the "non-translated" string bundles for dojo into place, I suppose
10:48 mrpeters uh oh who said my name!
10:48 mrpeters oh, just csharp...whew ;)
10:50 csharp eeevil: thanks for the clarification
10:50 csharp mrpeters: just trying to keep you on your toes!
11:10 bmills joined #evergreen
11:13 ldw joined #evergreen
11:17 krvmga in the basic search screen, is the size/format of the dropdowns configurable by us or is that browser-based?
11:18 ldw joined #evergreen
11:18 ericar_ joined #evergreen
11:19 jboyer-isl krvmga: They're controlled by CSS. We removed the size restriction on the org_unit drop down here, for instance.
11:20 krvmga jboyer-isl: i should look for this in style.css.tt2, yes?
11:20 jboyer-isl yup.
11:20 jboyer-isl I believe some (most?) of them have ids you can look for.
11:21 krvmga jboyer-isl++
11:21 krvmga thx
11:33 jwoodard joined #evergreen
11:36 RBecker joined #evergreen
11:56 * gmcharlt tosses out a trivial pullrequest, bug 1339767 - request a quick merge to assist a documenter
11:56 pinesol_green Launchpad bug 1339767 in Evergreen 2.6 "add Thumbs.DB to .gitignore" (affected: 1, heat: 6) [Low,New] https://launchpad.net/bugs/1339767
11:58 bshum Aww
12:00 bshum There's something like that on Macs too
12:01 jcamins .DS_Store or something like that.
12:01 bshum Yeah, that's it
12:02 bshum Used to annoy the hell out of me :)
12:02 Dyrcona Before we were all Linux at home, I used to run find /storage -name .DS_Store -delete on our file server.
12:03 bshum Ack, updating the LP milestones now that the current round of releases is out
12:03 jeff arguably things like *.swp, Thumbs.DB, .DS_Store, etc should go in your client's global gitignore, and not the repo. I can see some desire for lowering barriers to contribution, though.
12:04 pinesol_green [evergreen|Galen Charlton] LP#1339767: add Thumbs.DB to .gitignore - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=1487181>
12:04 gmcharlt jeff: sadly, not all clients make it easy to get at it
12:05 jeff which git client / OS combo does that commit target?
12:05 gmcharlt Git GUI on Windows 8.1-b0rken
12:06 gmcharlt b0rken, in this case, because it doesn't include the local group policy editor that would make it possible to simply disable the creation of Thumbs.DB
12:07 jeff This is with a shared drive in the mix?
12:07 jeff (as in, a network share)
12:07 bshum Okay, added new milestones for 2.6.3 and 2.5.7 and shifted the milestone target on that bug to the correct milestones.  I left the others open till dbwells is ready to mark them closed.
12:08 gmcharlt jeff: nope, local
12:08 dbwells bshum: thank you
12:09 gmcharlt bshum++
12:09 bshum As a note, I'm also going to tinker and add a 2.7 series now.
12:09 bshum And setup my first milestone for alpha
12:10 jeff gmcharlt: interesting. my understanding is that Vista/7/8 did away with the Thumbs.db in each folder, moving them to a central location (except in the case of remote network shares).
12:10 jeff I wonder if something other than the OS is creating the Thumbs.db file -- especially with the odd case Thumbs.DB
12:11 jeff anyway, if that fixes it, there's probably not much point in figuring out where they're coming from.
12:13 gmcharlt *sigh*
12:13 gmcharlt yep, Thumbs.db (lowercase) is what I meant
12:13 bshum I was literally just thinking that
12:14 gmcharlt bshum: I've just pushed a follow-up, if I can impose on you to merge it
12:15 gmcharlt jeff: in any event, the Win8.1 box in quetstion was indeed creating it locally
12:15 bshum gmcharlt: Done.
12:16 gmcharlt jeff: thanks for the catch
12:17 jeff you're welcome! without a win8.1 box handy to test on, I can't say if it mattered or not. :-)
12:17 jeff (with windows being so spotty with regard to file case)
12:18 pinesol_green [evergreen|Galen Charlton] LP#1339767: follow-up: Thumbs.db, not Thumbs.DB - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=694d4fa>
12:20 Dyrcona heh.
12:24 jcamins jeff: I didn't know there was a global gitignore.
12:26 gmcharlt $HOME/.config/git/ignore
12:27 gmcharlt which is not global-global, of course, but applies across local clones
12:27 jcamins Github suggested core.excludefiles
12:27 gmcharlt TIMTOWTDI
12:29 b_bonner_ joined #evergreen
12:32 * jeff nods
12:33 jeff i have core.excludefiles pointed at a file that contains *.swp and .DS_Store
12:33 jeff keeping it simple. :P
12:40 jeffdavis joined #evergreen
12:53 vlewis joined #evergreen
13:24 mnsri joined #evergreen
13:25 mnsri left #evergreen
13:26 mnsri joined #evergreen
13:26 mnsri left #evergreen
13:27 kbeswick joined #evergreen
13:30 hbrennan joined #evergreen
13:30 jeff There is an old github organization called eghackfest with a single repo with some old (since brought into Evergreen master) added content work. I'm considering deleting the repo and the org. It doesn't seem like there's any great loss in doing so, but I'd be interested in anyone else's opinions on that. https://github.com/eghackfest/OpenILS-Evergreen
13:31 mnsri joined #evergreen
13:31 Dyrcona I didn't even know it existed.
13:32 bshum Indeed.
13:38 csharp no objections here
13:41 jeff It was used pretty much just at the hackfest, and pre-dates us using git.
13:41 bshum Hmm
13:42 bshum So for checkin_override in oils_sip.xml, I have an entry like <event>COPY_STATUS_MISSING</event>
13:42 bshum And yet, missing items are still not being checked in
13:42 bshum Do I have to grant the actual override to the SIP user in question?
13:42 tsbere bshum: Does the SIP user have the override permission?
13:42 dbs gmcharlt++ bshum++ # providing substantive doc reviews!
13:42 bshum tsbere: Aha, okay, maybe that's what I'll check
13:42 jeff the sip user will need the required override permission.
13:43 tsbere bshum: Treat the SIP users as staff client users for the most part. Thus any permission a staff user might need to accomplish something SIP will likely also need.
13:45 bshum tsbere++ jeff++ # thanks guys, we'll test and hopefully that'll be the end of that question
13:58 gmcharlt jeff: no objection either
14:30 ningalls joined #evergreen
15:00 csharp bshum: I created a signoff branch for my ubuntu 14.04 makefile updates -FYI
15:01 csharp see bug 1315531 for details
15:01 pinesol_green Launchpad bug 1315531 in Evergreen "Need Ubuntu 14.04 Trusty Makefile target for Evergreen" (affected: 1, heat: 6) [Wishlist,Confirmed] https://launchpad.net/bugs/1315531
15:01 bshum csharp: Oh excellent.  I'll take a look over that too
15:01 csharp thanks - I was just trying to update my test box to current master, but couldn't because those commits aren't in yet ;-)
15:05 ldw joined #evergreen
15:06 jboyer-isl some quick followup for any interested parties: I've fed the same production 1-hour pg log through pgbadger and pgfouine and there's no comparison. pgfouine took 14 minutes to parse it, missed over 2000 queries, and doesn't give nearly the information pgbadger can.
15:07 jboyer-isl It doesn't hurt that pgfouine is also hard to look at and pgbadger looks rather nice.
15:07 bshum jboyer-isl: Future Evergreen talk material there?  :D
15:07 jboyer-isl I forgot the comparison number there. pgb got through it and it only took 6 minutes.
15:08 csharp jboyer-isl: great to know!  I'll look into pgbadger as an alternative
15:09 jboyer-isl bshum: It might be worth it. It's certainly giving me some talking points re: performance. (We spend 1:25+ of time in that hour looking up suggestions for the dojo based autocomplete. I do not like that.)
15:10 jboyer-isl Though I'm not necessarily the best one to ask what to do with the output. (I'm currently hoping to present on Ansible in Portland. Maybe pgbadger could be a lightning talk.)
15:10 csharp we never did implement autocomplete - too many bad records/redundant entries
15:10 bshum Autosuggest needs work indeed.
15:10 csharp er.. yeah autosuggest
15:11 jboyer-isl I also don't think people understand WHAT it's completing. i.e. "here's a subject search for the words you're typing" when the search type drop down still says Keyword = patron confusion. :/
15:11 bshum jboyer-isl: That's one of the many reasons we never enabled ours too.
15:11 bshum jboyer-isl: You're aware of the accessibility bug right?
15:12 jboyer-isl I've heard mention of it, but I'm not up on the details.
15:12 bshum https://bugs.launchpad.net/evergreen/+bug/1187993 (it's one of those few "HIGH" bugs hanging around)
15:12 pinesol_green Launchpad bug 1187993 in Evergreen "Auto suggest causes significant accessibility issues for using basic search in some browsers" (affected: 5, heat: 26) [High,Confirmed]
15:13 bshum It's one of the reasons autosuggest ships disabled now in 2.6.  But sites have to choose to turn it off until we get the fix in works.
15:13 bshum (there is no fix in works presently as I know of anyways, someone tell me if I'm wrong)
15:19 jboyer-isl We also have the complication that even if it can be turned off, copy location search still has to work. I haven't looked deep enough into how the templates work, so the way I would do that is enable autosuggest and then chop that part out of the template.
15:20 jboyer-isl I'm assuming that wouldn't cause any issues, just a little unnecessary code loading.
15:21 * bshum refers to https://bugs.launchpad.net/evergreen/+bug/1314370 which may cover that particular problem
15:21 pinesol_green Launchpad bug 1314370 in Evergreen "Shelving Location field in Advanced Search only works if dojo loaded" (affected: 2, heat: 10) [Medium,Confirmed]
15:21 bshum My quick change there still needs signoff and push, but it basically moves us to always load dojo, because we need it for the location filter at minimum.
15:22 bshum There's probably more code changes we could do to make things cleaner, but that was the quick and dirty easy thing to change
15:23 bshum So if it was me, I would disable autosuggest, then tweak the template like I did in the file to re-enable dojo.
15:23 bshum At least till we get deeper with code cleanup / removal / rewriting
15:25 jboyer-isl bshum: ah, that does look more like it. If we end up turning off autosuggest I'll definitely be doing that.
15:25 bshum In our case, dojo is turned on because of other config choices we made
15:25 bshum Like using Google Books
15:25 bshum Or Novelist
15:26 bshum So I didn't catch that issue in my original testing when we wrote the patch to disable autosuggest by default.
15:46 kbeswick joined #evergreen
15:53 ldw joined #evergreen
16:02 dMiller_ joined #evergreen
16:36 tspindler left #evergreen
16:40 rangi joined #evergreen
16:55 Bmagic jeff: The error I was getting turned out to be due to the required SSL redirect when accessing /reporter. PP was configured to talk to the app servers on port 80 in the backend no matter what. They 301 redirected the clients to talk to port 443. PP answered, and talked to the app servers on 80 again. rinse and repeat
16:56 jeff redirect loop.
17:04 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
17:04 kbeswick joined #evergreen
17:06 mmorgan left #evergreen
17:41 pinesol_green [evergreen|Yamil Suarez] Documentation: added AsciiDoc version of old SIP docs from EG 1.6/2.0 docs - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=df806b4>
17:41 pinesol_green [evergreen|Yamil Suarez] Documentation: updated some SIP content - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=5f75319>
17:42 bshum yboston++ gmcharlt++
17:42 gmcharlt yboston++ bshum++
19:28 hbrennan joined #evergreen
20:33 ldw joined #evergreen
22:09 goooood joined #evergreen
22:14 pastebot joined #evergreen
22:53 zerick joined #evergreen
23:59 mnsri_ joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat