| 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.actor&method=opensrf.open-ils.system.ils_version |
| 09:37 |
krvmga |
http://acq.open-ils.org/gateway?service=open-ils.actor&method=opensrf.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 |
