| 11:01 |
remingtron |
"Oh man! Who printed their reports on my chocolate paper?!" |
| 11:05 |
tsbere |
remingtron: Well, that would make it nicer when you decide someone needs to eat the report for security/privacy reasons. ;) |
| 11:22 |
|
nhilton joined #evergreen |
| 11:47 |
bshum |
berick++ # I'm testing https://bugs.launchpad.net/evergreen/+bug/1392759 to get a new build system setup today to roll releases. |
| 11:47 |
pinesol_green |
Launchpad bug 1392759 in Evergreen "Developer/Packager Makefile.install targets" (affected: 1, heat: 6) [Wishlist,New] |
| 11:49 |
bshum |
berick: As a side question, I can see that there's a distinction made between "developer" and "packager" in the Makefile |
| 11:49 |
bshum |
I assume I should also run the developer one so that when we go to build the release including the web client stuff, that it'll have the necessary deps in place |
| 11:54 |
bshum |
berick++ # sweet :) |
| 11:55 |
bshum |
And might I say, I love this super handy addition for future release setup. :D |
| 11:57 |
berick |
great, glad it's helping |
| 11:59 |
* bshum |
goes and rolls 2.7.2 to test and see if everything installed right in his new building environment. |
| 12:04 |
berick |
bshum: hm, are you building on a machine that does not have EG installed? |
| 12:04 |
berick |
just curious about the lack of libtemplate-perl and liblocale-maketext-lexicon-perl |
| 12:04 |
bshum |
berick: Yep, I already found a quirk. |
| 12:07 |
eeevil |
the "not for human eyes" scared me :) |
| 12:09 |
berick |
heh, yeah, well EDI rarely is, i guess |
| 12:09 |
eeevil |
that's fair |
| 12:09 |
Dyrcona |
berick eeevil: I might be able to scare up someone who would be willing to test it with a vendor, but probably not until after the New Year. |
| 12:09 |
berick |
bshum: if you come up w/ a list of prereqs for non-EG-installed machines, we can add them to the makefile target |
| 12:09 |
berick |
Dyrcona++ |
| 12:09 |
eeevil |
Dyrcona++ # indeed |
| 12:38 |
mmorgan |
The log is telling me: circulator: bailing out with events: COPY_NOT_AVAILABLE |
| 12:38 |
Dyrcona |
Does the self check circ user have COPY_NOT_AVAILABLE.override permission? |
| 12:39 |
Dyrcona |
Didn't look to see if COPY_NOT_AVAILABLE is overridable, btw. That just comes to mind, though. |
| 12:40 |
mmorgan |
Yes, the user has that permission. |
| 12:48 |
mmorgan |
I swear the selfcheck/status thing worked when I originally tested, but it's not working now :-( |
| 12:49 |
Dyrcona |
Well, the log messages suggest that either the user doesn't have the permission or the override check is not being done for that event. |
| 12:52 |
mmorgan |
Here are a few more lines from the log. |
| 12:52 |
mmorgan |
[2014-12-17 12:22:11] open-ils.circ [INFO:38527:Circulate.pm:1170:14185563064613121] circulator: permit_patron script returned events: HASH(0x2ea13a8) |
| 13:04 |
RoganH |
#info Rogan Hamby, SCLENDS |
| 13:05 |
gmcharlt |
thanks |
| 13:05 |
RoganH |
And I'll be in and out of paying attention as I have something else going on at the same time (a reference materials meeting). |
| 13:05 |
gmcharlt |
I will need to keep this meeting short today, so let's just focus on highlights, please |
| 13:05 |
gmcharlt |
#topic Action items from previous meetings |
| 13:06 |
gmcharlt |
I've had very little time, what with crossing the continent, so first... |
| 13:06 |
gmcharlt |
#action (carry-over) gmcharlt will coordinate/assist with dbs to move the planet |
| 13:07 |
gmcharlt |
#action (carry-over) gmcharlt with work with DIG to get a test VM for doc-building set up |
| 13:07 |
gmcharlt |
#action gmcharlt will follow up with ericar re libraries roster and LP instructions page |
| 13:07 |
gmcharlt |
#action gmcharlt will tweak the “learn more” buttons shortly |
| 13:07 |
gmcharlt |
#action (carry-over) gmcharlt will coordinate with the EOB regarding the trademark policy page |
| 13:08 |
gmcharlt |
kmlussier: could you talk about your action items as well as the current status of the conference registration & events plugin? |
| 13:08 |
kmlussier |
I'll get the easy one out of the way first. |
| 13:09 |
kmlussier |
#info kmlussier has applied updates to the Getting Started page. The page now contains sections for testing code and funding projects. |
| 13:09 |
kmlussier |
I haven't worked on the action item to bring over previous conference materials, because I have been focusing on getting an event registration solution for this year's conference. |
| 13:10 |
kmlussier |
Mainly because it looks like we won't be able to get continued sponsorship to get Eventbrite fees, but also because I think it would be good if we didn't have to send our info to a third party. |
| 13:11 |
kmlussier |
I looked at a couple of plug-ins. The one that looks like it would work best for our conference is the Pro version of events manager. |
| 13:11 |
kmlussier |
#link http://wp-events-plugin.com/ |
| 13:12 |
kmlussier |
At this point, there are 2 things that could delay the conference registration. 1) we still are waiting for the venue contract to be signed. |
| 13:12 |
kmlussier |
And the SFC has concers about this plug-in because it isn't fully licensed as GPL. |
| 13:13 |
kmlussier |
I'm still waiting to hear back from them on those concerns. |
| 13:14 |
kmlussier |
My preference is to use it because I think it's a better solution to using Eventbrite. |
| 13:14 |
gmcharlt |
thanks for the update |
| 13:14 |
|
nhilton joined #evergreen |
| 13:15 |
gmcharlt |
I believe that phasefx has completed the update the FAQs page |
| 00:51 |
|
dkyle joined #evergreen |
| 00:52 |
|
_bott_ joined #evergreen |
| 01:17 |
|
nhilton joined #evergreen |
| 05:13 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:35 |
|
BigRig joined #evergreen |
| 07:10 |
|
mmorgan joined #evergreen |
| 07:10 |
|
artunit_ joined #evergreen |
| 12:22 |
mrpeters |
I made note of it on the upgrade spreadsheet. |
| 12:28 |
|
jihpringle joined #evergreen |
| 12:29 |
|
nhilton joined #evergreen |
| 12:31 |
kmlussier |
bshum or anyone else: do you know if we already have a page with guidance on testing bugs/using Launchpad? |
| 12:31 |
bshum |
kmlussier: Last I recalled, I thought ericar was working on a page for that. |
| 12:32 |
kmlussier |
I was thinking it would be useful to put http://wiki.evergreen-ils.org/doku.php?id=dev:bug_squashing:2014-11-10#testing_bugs on a page that is more permanant than a bug squashing day page, but I didn't want to create something new if there was something already out there. |
| 12:33 |
bshum |
kmlussier: Yeah, it was a carryover from a few web team meetings: http://wiki.evergreen-ils.org/doku.php?id=webteam:meetings:agenda:2014-10-15 |
| 12:34 |
bshum |
I imagine it's just gotten lost in the shuffles. |
| 12:36 |
kmlussier |
Well, maybe I can create the page with info on testing bugs, and then when somebody has time to do the larger "how to use Launchpad" page, they can incorporate it there? |
| 12:37 |
|
bmills joined #evergreen |
| 12:37 |
kmlussier |
My initial goal was just to follow up on a web team action item, but I seem to be straying a bit. |
| 12:53 |
|
julialima_ joined #evergreen |
| 13:40 |
|
RoganH joined #evergreen |
| 14:03 |
jcamins |
@later tell rfrasur I just got an e-mail saying my foldscope is in the mail! :D :D :D |
| 14:29 |
bshum |
Just so that we cover the bases. |
| 14:29 |
bshum |
I forward ported things so that the chain is better now though. |
| 14:33 |
pinesol_green |
[evergreen|Dan Scott] LP#1400100 - Avoid extra </div> when OpenURL is enabled - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=85ccb0c> |
| 14:36 |
paxed |
i mentioned this yesterday, but i'll repeat: anyone want to test this (marc_warnings.pl) on EG install & bib data: http://github.com/paxed/marc21-fi-mangle |
| 14:40 |
bshum |
paxed: I saw it, but haven't had a chance to play with anything. |
| 14:41 |
bshum |
I can't remember if adding a new dependency might break egbuilder, but let's see how it goes.. |
| 14:41 |
pinesol_green |
[evergreen|Jason Stephenson] LP#1401271: Add missing dependency for Date::Manip perl module - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=da51e17> |
| 15:32 |
berick |
(merging / LP) |
| 15:36 |
dbs |
6-digit bugs, nice |
| 15:37 |
|
buzzy joined #evergreen |
| 15:38 |
bshum |
Only 5 pullrequest things left for 2.7.2 |
| 15:38 |
bshum |
Of those, 2 are related to action_trigger stuff, and I'm still deciding what to do about them; how to handle the backporting basically. |
| 15:39 |
bshum |
Two are still waiting for further testing. |
| 15:39 |
bshum |
And one looks like it's still in a state of flux |
| 15:39 |
* bshum |
refers to berick/eeevil's https://bugs.launchpad.net/evergreen/+bug/1386347 |
| 15:39 |
pinesol_green |
Launchpad bug 1386347 in Evergreen 2.6 "Speed up hold copy map deletion for clear shelf process, etc." (affected: 1, heat: 6) [Undecided,New] |
| 15:39 |
pinesol_green |
[evergreen|Dan Scott] LP#1402905 Use stricter matching for UPC values - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cd9dfdf> |
| 15:43 |
bshum |
From the comments it looks like we're mostly settled, but maybe we should test more before we're ready to put that through. |
| 15:43 |
|
julialima_ left #evergreen |
| 15:43 |
eeevil |
bshum: I'll sign off on that branch |
| 15:43 |
bshum |
eeevil: That works too :) |
| 16:00 |
jboyer-isl |
mmorgan, I see you were poking at lp 1210541 |
| 16:00 |
jboyer-isl |
yesterday, is that looking good? I didn't want to put a pullrequest on it if there are still issues. |
| 16:00 |
pinesol_green |
Launchpad bug 1210541 in Evergreen "Copy locations table should have a 'deleted' flag" (affected: 9, heat: 52) [Wishlist,Confirmed] https://launchpad.net/bugs/1210541 - Assigned to Michele Morgan (mmorgan) |
| 16:03 |
mmorgan |
jboyer-isl: I did start poking, but didn't finish testing yet. |
| 16:04 |
mmorgan |
I did find that the deleted locations still show up in the interfaces where location groups and location order are configured. |
| 16:07 |
jboyer-isl |
How annoying of them. :/ I'm glad I didn't try to get it pushed in under the wire then, I'll keep plugging away. |
| 16:07 |
jboyer-isl |
Thanks mmorgan . |
| 16:09 |
mmorgan |
I was trying to decide if that was a showstopper. I think it would make those interfaces pretty confusing to use. :-( |
| 16:28 |
|
bmills joined #evergreen |
| 16:32 |
|
buzzy joined #evergreen |
| 16:32 |
|
bmills1 joined #evergreen |
| 16:56 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:56 |
|
artunit_ joined #evergreen |
| 17:00 |
|
jihpringle joined #evergreen |
| 17:07 |
|
mmorgan left #evergreen |
| 02:43 |
|
tsbere__ joined #evergreen |
| 04:58 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:10 |
|
TaraC joined #evergreen |
| 07:11 |
|
phasefx joined #evergreen |
| 07:56 |
|
jboyer-isl joined #evergreen |
| 09:58 |
Dyrcona |
So, funny: I have It's Only Rock'n'Roll (and I Like It) playing right now. |
| 09:59 |
Dyrcona |
Mick was at the chorus when I read krvmga's latest message. |
| 10:01 |
krvmga |
Dyrcona: :) |
| 10:01 |
kmlussier |
Dyrcona: No problem. I'm not sure when I'll have time to do testing anyway. |
| 10:01 |
* kmlussier |
just realized today that she only has a little more than a week of work left with a long to-do list before going on vacation. |
| 10:01 |
* Dyrcona |
watches his wifi indicator go up and down like a kid bouncing on a bed. |
| 10:02 |
Dyrcona |
kmlussier: There's always next year. |
| 10:02 |
|
BigRig joined #evergreen |
| 11:11 |
|
dreuther joined #evergreen |
| 11:12 |
|
chatley joined #evergreen |
| 11:23 |
|
dreuther_ joined #evergreen |
| 11:25 |
paxed |
anyone wanting to test this: https://github.com/paxed/marc21-fi-mangle (does marc_warnings.pl work on EG? i don't have an install or data i could test it against) |
| 11:32 |
|
collum joined #evergreen |
| 11:38 |
|
StephenGWills joined #evergreen |
| 11:48 |
|
mrpeters joined #evergreen |
| 11:49 |
* mmorgan |
was hoping that as well :-( |
| 11:54 |
eeevil |
julialima_: sorry I missed your response and question. csharp pointed you at some good resources, and I'm happy to chat any time. just prefix with "eeevil:" to get my attention :) |
| 12:09 |
julialima_ |
eeevil: no worries. Thank you anyways |
| 12:14 |
kmlussier |
mmorgan: Did you tell me you wanted to test something on a Sandbox? I can't remember what it was. |
| 12:16 |
mmorgan |
kmlussier: lp 1210541 |
| 12:16 |
pinesol_green |
Launchpad bug 1210541 in Evergreen "Copy locations table should have a 'deleted' flag" (affected: 9, heat: 52) [Wishlist,Confirmed] https://launchpad.net/bugs/1210541 |
| 12:17 |
kmlussier |
mmorgan: OK. I'll load it on mlnc2 now. |
| 09:03 |
|
rjackson-isl joined #evergreen |
| 09:10 |
|
RoganH joined #evergreen |
| 09:13 |
|
julialima joined #evergreen |
| 09:20 |
Dyrcona |
Heh. I just used NCIPServer to place a hold for pickup at a certain library that could only be filled by a certain library on my dev server in order to test something totally unrelated to NCIP. |
| 09:21 |
kmlussier |
Dyrcona: Nice! |
| 09:22 |
|
RoganH joined #evergreen |
| 09:22 |
mrpeters |
reciept template fun! Re: https://bugs.launchpad.net/evergreen/+bug/1396307 -- is there a way (I know some javascript could probably do it, but I don't know if it would be merged into master) to have the row for %noncat_count% only display when the item(s) in question are of the noncat type? |
| 09:25 |
mrpeters |
i would also say that it is a bug, not a wishlist, that the template doesn't properly account for the number of non-cat items checked out when the macro is already available |
| 09:25 |
jeff |
kmlussier: morning! |
| 09:27 |
kmlussier |
jeff: :) |
| 09:27 |
Dyrcona |
Yeah, it was the fastest way I could think of to place the hold: open a test script, edit two fields, and run it. |
| 09:27 |
Dyrcona |
Now, to experiment with suspending on shelf holds that have not been picked up.... |
| 09:29 |
|
yboston joined #evergreen |
| 09:31 |
|
julialima joined #evergreen |
| 10:00 |
mrpeters |
tsbere: are there other templates doing this? |
| 10:00 |
|
ericar joined #evergreen |
| 10:00 |
mrpeters |
(reading your article at http://masslnc.cwmars.org/node/2528 now) |
| 10:02 |
tsbere |
mrpeters: Er, I don't think stock templates do....but we have libraries that use it internally for some things. (note: I didn't test that code) |
| 10:02 |
mrpeters |
nah thats fine i understand it -- i just didn't know this functionality existed |
| 10:03 |
tsbere |
mrpeters: For example, making it so that a "short slip" prints out for specific shortnames is one of the primary reasons the "swap slip" exists - The entire main slip is discarded and an alternate used instead when the shortname matches |
| 10:03 |
mrpeters |
so, it looks at the value of the macro and decides whether or not to display the div? how is that happening? |
| 10:48 |
dbs |
by way of explanation, I hate marking older bugs as dupes because it feels like rewriting history. |
| 10:48 |
Bmagic |
csharp: you are using acq? |
| 10:48 |
|
sandbergja joined #evergreen |
| 10:48 |
csharp |
Bmagic: we're in a test period with a planned go-live on a couple of libraries in early spring |
| 10:48 |
DPearl |
eeevil: Thanks |
| 10:49 |
csharp |
but, yeah, I've learned way more about acq than I wanted to :-P |
| 10:49 |
Bmagic |
csharp: And you plan on registering the appropriate users to the system level? |
| 14:41 |
D0nB |
Just let me know how/if I can help |
| 14:41 |
kmlussier |
yboston: Maybe when the new cataloger is up to speed, they can help explain them. |
| 14:42 |
yboston |
that is what I hope to do |
| 14:42 |
kmlussier |
#info posted testing feedback for bug 1389403 and has signed off on it. |
| 14:42 |
pinesol_green |
Launchpad bug 1389403 in Evergreen "OPAC numeric search's call number search bug with LC call numbers " (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1389403 |
| 14:42 |
yboston |
kmlussier++ |
| 14:43 |
kmlussier |
OK, moving on to new business, I think we covered most updates during the action item updates. |
| 15:06 |
kmlussier |
A toggle to do what? |
| 15:06 |
yboston |
turn it on or off |
| 15:06 |
yboston |
or is there such a thing already and we only need better documentation? |
| 15:07 |
kmlussier |
I could be wrong, but I think you just need to give the right permission to patron to surface the volume/copy holds in the pac. |
| 15:07 |
* kmlussier |
hasn't tested it, though. |
| 15:07 |
dbs |
it's hard-coded right now as staff-only |
| 15:08 |
kmlussier |
dbs: OK, thanks for correcting me then. |
| 15:08 |
yboston |
dbs: thanks |
| 00:20 |
|
nhilton joined #evergreen |
| 00:32 |
jeff |
dbs++ |
| 04:54 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:31 |
|
chatley joined #evergreen |
| 07:25 |
|
wsmoak joined #evergreen |
| 07:42 |
|
TaraC joined #evergreen |
| 11:46 |
tsbere |
attr and value come from the left joined table |
| 11:46 |
eeevil |
sure they do |
| 11:47 |
eeevil |
so your problem stems from not having a coded_value_map-side value, at all, from those records. is that correct? |
| 11:48 |
tsbere |
The problem stems from "we are getting at least one null when the previous, pre-peformance-improvement code would never have spit a null out" regardless of *where* that null comes from. Removing the left joins brings the "faster" (I haven't tested that myself) code back into not outputting those nulls. |
| 11:49 |
eeevil |
you're seeing, what, a row for titlesort from uncontrolled, and a second row with nulls for both attr and value. is that right? |
| 11:49 |
Dyrcona |
They have mravl entries. |
| 11:50 |
Dyrcona |
And, what purpose does returning nulls serve, other than to cause a database error? |
| 11:50 |
eeevil |
Dyrcona: thanks. I'm guessing the int array has only negative values in them? |
| 11:50 |
tsbere |
eeevil: The ones I am seeing in my own tests have only *positive* values. |
| 11:51 |
* tsbere |
isn't going all that deep, mind you, just trying to find ones that output nulls |
| 11:51 |
eeevil |
tsbere: so they have no title or author fields? |
| 11:51 |
|
mllewellyn joined #evergreen |
| 11:52 |
eeevil |
Dyrcona: the left join was key to helping the planner with query optimization in my tests with large data sets |
| 11:52 |
eeevil |
when going through multiple views |
| 11:52 |
tsbere |
eeevil: Looks like at least one of them has a title. |
| 11:53 |
eeevil |
tsbere: then it should have a negative value in the int array -- or the title wasn't found by the attr |
| 11:53 |
eeevil |
attr def, that is |
| 11:55 |
tsbere |
eeevil: Given that this apparently happens with real world data either the record_attr_flat view needs to never spit out nulls (as it hadn't before) or the next view up the chain needs to not dump the output directly into hstore as keys. |
| 11:56 |
eeevil |
tsbere: see my comments on the bug |
| 12:00 |
tsbere |
eeevil: I will also point out I am not finding a significant difference in plans between the left join and normal join versions of the view when I run things through explain analyse. |
| 12:01 |
eeevil |
tsbere: what data set size are you testing with |
| 12:01 |
tsbere |
eeevil: I am poking around in a copy of our production system at the moment. |
| 12:03 |
tsbere |
eeevil: Really, the only difference I can see in the plans themselves are "Nested Loop" vs "Nested Loop Left Join" |
| 12:03 |
eeevil |
well, you can either believe that I'm not lying, or you can test all code that uses either of those views (and the rec_descriptor view), I guess |
| 12:05 |
tsbere |
eeevil: I will point out that I get *very* different plans from the old version of record_attr_flat. I just don't get any improvements when I remove the LEFT from the joins in the current one. |
| 12:06 |
tsbere |
eeevil: AKA, I see improvements in the current one, but I don't see the LEFT portion of the joins aiding those improvements. |
| 12:07 |
eeevil |
a left join opens up more options for plans depending on the field from the view that is joined in a larger query. that expanded set of plan options was necessary to make certain queries fast. it was months ago that I was working on this, so I don't recall (or have time to dig up) the details right now |
| 12:11 |
tsbere |
eeevil: Well, I am not seeing those differences as I go through iterations of queries I can find happening elsewhere as I walk up from one level to the next. Major improvements on not using full_attr_id_map, but nothing on left join vs regular join. |
| 12:15 |
eeevil |
tsbere: is the filter in the next view up really so offensive to you that you'd rather try to find and test every possible way the views in question could be used? |
| 12:17 |
mrpeters |
Fix for bug 1319964 pushed to http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mrpeters/lp1319964_fix_summaries_ampersand -- it's an old annoying bug that most people just fixed locally i think, but its been busted in master for a while |
| 12:17 |
tsbere |
eeevil: I am using your own "keep things outputting the same thing they did" gig - The version you replaced does not, in any of my tests, output null attr columns. Your replacement does, but is much faster in all my tests. My change to your replacement maintains the same performance boost, from what I can see, but without the null attr columns. |
| 12:17 |
pinesol_green |
Launchpad bug 1319964 in Evergreen "double-escaped entity in "Summaries & More" label" (affected: 3, heat: 18) [Low,New] https://launchpad.net/bugs/1319964 - Assigned to Athira S (athirasnamby) |
| 12:18 |
tsbere |
eeevil: As such, unless you can point at a good reason for the LEFT JOIN version to remain and spitting out null attrs I am against the view spitting out null attrs. |
| 12:21 |
|
phasefx joined #evergreen |
| 12:21 |
eeevil |
tsbere: here's my good reason: it was needed to get bshum's server to be able to search in a reasonable amount of time, because the plans became not-insane. do you believe that I am lying to you? does the solution i've suggested to your problem not work? |
| 12:23 |
eeevil |
and I would absolutely love to be able to not change the output of the view. but not at the cost of killing performance to the point of "broken for the user" |
| 12:24 |
bshum |
I haven't really tested either of the fixes (I'm not sure I can really test it without crummier bib records) but I think it'll be good to look at what has been suggested thus far. |
| 12:24 |
tsbere |
eeevil: I have no problem with changing the output of the view if you can provide information on where, exactly, things go wrong with the output remaining the same. The fact that I get massive performance boosts with the union version, with or without the left joins, says it works. I am arguing that the left join part does *not seem to matter* on that front. |
| 12:24 |
bshum |
At a cursory glance, I think eeevil's treatment for the check for not null attr columns looks sane to me. |
| 12:24 |
tsbere |
eeevil: If you can dig up evidence that I can't for the left join portion mattering I am willing to look at it. |
| 12:29 |
tsbere |
eeevil: And what *I* see is "the view outputs things differently when it doesn't need to" |
| 12:31 |
eeevil |
tsbere: you've looked at it for less than an hour |
| 12:32 |
tsbere |
eeevil: And you admit it has been a while since you looked at it. As such, from my POV my "less than an hour" is currently more relevant than your recollections from the past, unless you pull relevant data out that you collected in the past on this issue to show me. |
| 12:34 |
eeevil |
tsbere: look, you've broken search before with code that I warned would not work in situations beyond your test environment, and I had to revert and rewrite that. If I need to revert more of your code and replace it, I'll do so. you do whatever you feel you need to do for MVLC |
| 12:35 |
|
nhilton joined #evergreen |
| 12:35 |
bshum |
Alright guys, so in the interest of testing by third-parties, I'd like to request we get some sample bib records (that create the mess) that we can use to replicate the issue initially. |
| 12:35 |
bshum |
And then let's see how testing pans out for the solutions proposed. |
| 12:35 |
tsbere |
eeevil: And you also yell at people that change the output of existing *anything* in the database, because who knows what else is using it. Your changes change the output, my adjustment to your changes restores the previous output. |
| 12:37 |
tsbere |
eeevil: As I can't find a situation where the database plans differently between our two versions, but both versions are a vast (identical, as far as I can see) improvement over the version you replaced, the fact that the output is restored to what used to come out makes sense to me. |
| 12:52 |
|
mtcarlson joined #evergreen |
| 12:57 |
|
nhilton joined #evergreen |
| 13:05 |
|
sandbergja joined #evergreen |
| 13:21 |
* csharp |
would be happy to test this issue too, FWIW |
| 13:21 |
csharp |
especially since we're moving to 2.7 in about a month ;-) |
| 13:21 |
RoganH |
We're a little further than a month out but not much and I'm interested in testing for the same reason. |
| 13:22 |
csharp |
we're also bound to have a wide array of poorly cataloged records |
| 13:23 |
csharp |
and/or records mangled in multiple ILS migrations over the years, non-MARC-compliant ILSs, etc. |
| 13:23 |
RoganH |
csharp: I feel like we could have a contest to see who has imported more bad records into the consortium. :) |
| 04:59 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:42 |
|
artunit_ joined #evergreen |
| 06:50 |
|
kmlussier joined #evergreen |
| 06:56 |
|
wsmoak joined #evergreen |
| 10:44 |
|
sfortin joined #evergreen |
| 10:58 |
eeevil |
remingtron / kmlussier: I've got a few fixes from Bill that are not yet deployed on webby. would you like me to make that happen? it'll cause just a second of outage while apache is restarted |
| 10:58 |
kmlussier |
I'm okay with that. I think there are only a few of us working on it right now. |
| 10:59 |
remingtron |
eeevil: I'm not actively testing right now |
| 10:59 |
remingtron |
eeevil: thanks! |
| 10:59 |
kmlussier |
eeevil: Anything interesting with the fixes? |
| 10:59 |
pinesol_green |
[evergreen|Remington Steed] Docs: Web Client preview intro - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=14784b3> |
| 11:01 |
eeevil |
kmlussier: they're all right here: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/web-client-sprint1-bug-fixing-rebased-collab ... |
| 11:35 |
|
dreuther joined #evergreen |
| 11:41 |
mrpeters |
Fix for Bug #1154656 at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mrpeters/lp1154656_marc_expert_search_duplicate_rows if anyone has a break from documentation party today for a signoff/pullrequest! |
| 11:41 |
pinesol_green |
Launchpad bug 1154656 in Evergreen 2.4 "MARC Expert Search "Add Rows" adds duplicate row" (affected: 5, heat: 22) [Medium,Confirmed] https://launchpad.net/bugs/1154656 |
| 11:49 |
kmlussier |
If you exit the browser without first logging out, you stay logged into the web client. Is that right? |
| 11:49 |
kmlussier |
Do we know how long users stay logged in? |
| 11:51 |
|
sandbergja joined #evergreen |
| 11:51 |
* kmlussier |
can't test this without either completely exiting out of the browser with my Google Hangout session or the browser that is playing my music. :( |
| 11:51 |
|
sandbergja joined #evergreen |
| 11:51 |
jcamins |
kmlussier: time to download a new browser! |
| 11:51 |
remingtron |
kmlussier: don't you have seven different browsers installed just for testing purposes? :) |
| 11:52 |
jcamins |
kmlussier: fortunately, there are lots of options, even just with Firefox: https://www.mozilla.org/en-US/firefox/developer/ https://nightly.mozilla.org/ |
| 11:53 |
kmlussier |
No, but I have about 12 different xul staff clients installed. |
| 11:54 |
eeevil |
bshum: first, thank you for signing off the sip branch!!! unfortunately, you've got some merge issues remaining in your commit ... look at the bottom of http://git.evergreen-ils.org/?p=working/SIPServer.git;a=blobdiff;f=SIPServer.pm;h=beb6e001719b477bd7ae6d43167aafb64d96a3d2;hp=36f505de5cb99b10dd081c8586339c26f69168e3;hb=b0786d3ae13fedb87b13463c18e1bfb43df9c3b5;hpb=c8e2ac5fe68961219095ab1b42486b161ce68e48 |
| 11:54 |
kmlussier |
jcamins: I'll remember that next time. For this go-around, sacrificed the music. |
| 11:54 |
alynn26 |
I'm in the middle of staff day, had a break thought I would work on Hatch, Got to go back with the rest of the crowd, and I've logged into Webby, will close it out and come back later, and test it after a few hours. |
| 11:54 |
eeevil |
bshum: if you want, I can rebase the branch to master for a clean signoff |
| 11:55 |
bshum |
eeevil: Maybe you mean to be talking to Bmagic? |
| 11:55 |
kmlussier |
eeevil: I think that was Bmagic, wasn't it? |
| 11:58 |
Bmagic |
yeah, rebase |
| 11:59 |
Bmagic |
I thought it was odd that I only needed to change the includes...... silly rabbit |
| 12:04 |
|
sandbergja left #evergreen |
| 12:05 |
mrpeters |
bah, hold off on testing that -- i broke Advanced Search now -- ReferenceError: addSearchRow is not defined :( |
| 12:05 |
mrpeters |
fix one thing, break another ;P |
| 12:05 |
|
sandbergja__ joined #evergreen |
| 12:08 |
Dyrcona |
mrpeters++ |
| 12:08 |
* mrpeters |
loves a good game of whack-a-mole |
| 14:39 |
* kmlussier |
needs to take a break from documentation for a bit, but hopes to do a little more before the day is done. |
| 14:46 |
yboston |
kmlussier: thanks for the updates, I was going to ignore those features but I was curious if there were any ongoing plans for both |
| 14:50 |
|
akilsdonk joined #evergreen |
| 15:19 |
bshum |
eeevil: I updated the couple of bugs that were also pushed today for SIPServer. I was confused at first why there were so many new commits in SIPServer till I realized it were multiple bug tickets afoot. |
| 15:19 |
bshum |
New stuff looks cool :) |
| 15:22 |
bshum |
A question though |
| 15:22 |
bshum |
The changes for sipconfig.xml in the commit, that's a test config file of some kind right? |
| 15:23 |
bshum |
Do those need to be adapted towards oils_sip.xml config or whatever we point SIPServer to use? |
| 15:23 |
Bmagic |
I didnt look at that |
| 15:23 |
bshum |
I'm thinking on things like the <cache> area, and specifying a different memcache source for the Multiplex mode |
| 15:24 |
bshum |
And the keepalive params |
| 16:58 |
|
kmlussier joined #evergreen |
| 17:03 |
phasefx |
berick: jcamins: eeevil figured out a good solution for the focus issue, using promises: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=9730cb52064bce949a352e379759f9daec28550c |
| 17:04 |
jcamins |
phasefx: ooh, good call! |
| 17:09 |
berick |
++ to that. but I wonder why that worked and not $timeout(func-to-set-focus, some-huge-number-to-test) |
| 17:09 |
|
mdriscoll left #evergreen |
| 17:09 |
berick |
even tested an embedded $apply() |
| 17:09 |
berick |
anyway, eeevil's approach is superior to any time |
| 17:09 |
berick |
glad it works |
| 17:14 |
phasefx |
berick: we can actually get rid of the $timeout, but I didn't want to do that until we looked at all other uses of focusMe |
| 17:15 |
phasefx |
but I experimented with removing $timeout with .finally in play and it worked |
| 17:16 |
berick |
phasefx: hm, yeah, i'd be wary of removing the timout within the focusMe directive |
| 17:17 |
berick |
i mean, i'd be wary of the original zero timeout |
| 17:17 |
berick |
arg, i'd be wary of *removing* the original zero timeout |
| 17:17 |
phasefx |
berick: the some-huge-number-to-test not working thing, I'm not groking that. 1-second was working for you? |
| 17:17 |
berick |
sorry, that comment was unclear |
| 17:18 |
berick |
i tested adding a timeout within the checkout controller |
| 17:18 |
phasefx |
oh, right |
| 17:18 |
berick |
which would fire after initTab had completed (also promise-based) |
| 17:18 |
berick |
so, i was confused why one promise resolver worked, but not another |
| 14:08 |
remingtron |
you mean, finish it himself? or give it to someone else? |
| 14:09 |
yboston |
yes, himself |
| 14:09 |
remingtron |
ah, okay |
| 14:09 |
yboston |
just looked up our conversation. he still needs to test |
| 14:09 |
yboston |
that EG behaves as his docs describes |
| 14:09 |
yboston |
tis was back on November 26 |
| 14:09 |
remingtron |
I'd say yes, just follow up with him again, whenever seems best |
| 14:10 |
yboston |
OK |
| 14:10 |
yboston |
#action yboston will contact krvmga to check in on his 2.7 docs work |
| 14:15 |
sandbergja |
remingtron++ |
| 14:15 |
remingtron |
you're welcome. I'm not sure what comes next, though. |
| 14:16 |
kmlussier |
I think we need more people to sign up for tasks. I tried to flesh out the outline for what can be documented tomorrow. Maybe we need to send out one last reminder asking people to assign themselves? |
| 14:16 |
yboston |
of the top of my head, when was the test server built? I wonder what commits it contains, in case new features are in master that are not in the test server? |
| 14:16 |
kmlussier |
Actually, the opposite is true |
| 14:16 |
yboston |
I still need to assign myself a tasks |
| 14:17 |
kmlussier |
webby has bug fixes that have not been merged into master yet. |
| 16:07 |
kmlussier |
mrpeters++ |
| 16:28 |
|
nhilton_ joined #evergreen |
| 16:29 |
|
mtcarlson joined #evergreen |
| 16:37 |
pinesol_green |
[evergreen|Kathy Lussier] Web client section headings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=feae6dc> |
| 17:06 |
|
jihpringle joined #evergreen |
| 17:12 |
|
wsmoak joined #evergreen |
| 17:12 |
|
wsmoak joined #evergreen |
| 17:13 |
|
mmorgan left #evergreen |
| 17:17 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 18:20 |
|
mtj joined #evergreen |
| 20:21 |
|
nhilton joined #evergreen |
| 22:47 |
|
mtcarlson joined #evergreen |
| 11:16 |
tsbere |
csharp/mmorgan: Grab everything after "bib search:" and dump it into query_parser.pl as the -query="blah" param to possibly get the full core query - That won't help with the wrapper function, though. |
| 11:16 |
bshum |
mmorgan: And what's in "filter_group_entry(4)" |
| 11:17 |
bshum |
"history" seems like a fairly broad search |
| 11:17 |
tsbere |
csharp/mmorgan: Oh, query_parser.pl would be in Open-ILS/src/support-scripts/test-scripts |
| 11:18 |
|
cokesme joined #evergreen |
| 11:18 |
bshum |
Oooh, fancy, tsbere++ |
| 11:18 |
mmorgan |
"filter_group_entry(4)" is a format filter "Books(All)" - we are suspicious that might be part of it |
| 11:24 |
bshum |
But I know that bug was a huge stumbler for our performance when we moved up to 2.6 during the summer. |
| 11:24 |
bshum |
Along with tuning in our PG database, but that was the worst part. |
| 11:26 |
mmorgan |
bshum: I think we did, but will need to verify. |
| 11:28 |
bshum |
With the changes to formats in 2.6, I'd also be curious to know how your filter_group_entry pointed back |
| 11:28 |
bshum |
And maybe something isn't quite optimal there |
| 11:29 |
bshum |
We don't use that feature in our catalogs, so I've never tested it. |
| 11:31 |
bshum |
csharp: I'd say speed and performance considerations are always a critical element with every upgrade. :) |
| 11:32 |
* bshum |
generally loves the new icons and formats, but does think it has been an interesting road walked thus far. |
| 11:37 |
mmorgan |
So we have a few leads to follow now, thanks all! |
| 11:37 |
mmorgan |
berick++ csharp++ bshum++ tsbere++ |
| 11:38 |
* mmorgan |
needs to investigate system crankiness. |
| 15:54 |
jcamins |
I guess I know what I'm doing tonight. |
| 15:54 |
phasefx |
:D |
| 15:55 |
berick |
phasefx: see opensrf master README |
| 15:55 |
phasefx |
berick: gracias |
| 15:56 |
* phasefx |
bumped the node.js version in the qa tests, incidentally |
| 15:57 |
|
akilsdonk_ joined #evergreen |
| 16:09 |
bshum |
tsbere++ # helping me read the closed_dates.js bits |
| 16:26 |
|
arthurdent left #evergreen |
| 16:27 |
|
mike_pizza left #evergreen |
| 16:35 |
phasefx |
so close.. :) WebSocket connection to blah failed: WebSocket opening handshake was canceled Uncaught Error: WebSocket Error [object Event] : undefined socket.onerror closing websocket |
| 16:36 |
* phasefx |
goes poking at opensrf_ws.js, see if he can get a better error |
| 16:43 |
berick |
phasefx: testing in chrome? |
| 16:43 |
phasefx |
berick: yes, chrome and chromium |
| 16:44 |
phasefx |
happens in firefox as well |
| 16:44 |
berick |
what happens if you go to https://hostname:7682 |
| 16:59 |
eeevil |
we can squash/reorder/etc later, I figure |
| 17:01 |
jeff |
togetherness! |
| 17:01 |
* jeff |
grins |
| 17:02 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:07 |
|
mmorgan left #evergreen |
| 17:15 |
|
mrpeters left #evergreen |
| 17:44 |
|
nhilton joined #evergreen |
| 01:28 |
|
phasefx__ joined #evergreen |
| 01:28 |
|
Callender_ joined #evergreen |
| 01:40 |
|
dkyle joined #evergreen |
| 05:10 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:15 |
|
wsmoak joined #evergreen |
| 05:54 |
|
wsmoak joined #evergreen |
| 06:28 |
|
phasefx joined #evergreen |
| 10:14 |
bshum |
I think it's missing. |
| 10:17 |
Dyrcona |
Looks like it is missing, but I seem to recall something else possibly depending on it. |
| 10:18 |
Dyrcona |
I could be mistaken, but even if I'm not, it won't hurt to make sure it is installed. |
| 10:19 |
bshum |
You're probably right, I don't know how else I could have tested or used the new marc_export previously otherwise |
| 10:19 |
bshum |
Maybe something changed when we moved to the modularized makefiles per distro |
| 10:19 |
Dyrcona |
I wonder if it was in there and got axed by a jumbled/out of sync commit? |
| 10:20 |
bshum |
Hmm, maybe. |
| 10:20 |
Dyrcona |
Well, I recall something else being missed when that happened. |
| 10:41 |
jeff |
*nod* |
| 10:47 |
Dyrcona |
Looks like the dependency was just plain missed. |
| 10:48 |
Dyrcona |
I don't see it in my working branch. |
| 10:51 |
bshum |
Maybe it got lost when we changed working branches from Marque.pm |
| 10:51 |
bshum |
Oh well. |
| 10:52 |
bshum |
Dyrcona++ # I'll test it later this weekend |
| 14:41 |
dbs |
Dyrcona: dang. sounds like something we should fix; a web app that can't handle requests for web pages isn't very useful :/ |
| 14:41 |
* dbs |
wonders if it's the same "extremely broad searches cause a cascading database denial of service" issue that we faced a while back |
| 14:52 |
Dyrcona |
Dunno. We recently changed some O/S settings after a crash. |
| 14:53 |
Dyrcona |
Might be related, might not be. |
| 15:18 |
|
sandbergja joined #evergreen |
| 16:37 |
|
StephenGWills joined #evergreen |
| 16:52 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:09 |
jeff |
dbs: what are your thoughts on search engine indexing of searches in general (say, from external links to search results) and things like subject/facet/related searches? |
| 17:11 |
jeff |
dbs: with sitemaps being a path toward indexing of the records without searches, is it useful/important to index the search result pages themselves? |
| 18:53 |
|
StephenGWills left #evergreen |
| 01:32 |
* bshum |
sighs |
| 01:44 |
bshum |
@later tell dbs I put some thoughts on the bug in reply, but I think we should forward port 2.6.2-2.6.3 to rel_2_7. Master already has it, so the question is changing the assumption that you can upgrade at any point along the 2.6 to 2.7.0, but actually it needs to be 2.6.3-2.7.0 (exactly) |
| 01:44 |
pinesol_green |
bshum: The operation succeeded. |
| 01:45 |
bshum |
Not sure if that's better or worse actually.... version upgrades are such a mess. I'm sorry that I couldn't test it more thoroughly myself. Not being on any particular version is a downside to my own personal testing efforts of these scripts :( |
| 01:46 |
bshum |
dbs++ # actually getting 2.7 tested :) |
| 01:54 |
bshum |
I also updated bug status on bug 800478 (that's 0890) and bug 1189556 (that's 0891) |
| 01:54 |
pinesol_green |
Launchpad bug 800478 in Evergreen "Acquisitions - Funds transfer always transfers entire fund, not specified amount" (affected: 5, heat: 34) [Medium,Confirmed] https://launchpad.net/bugs/800478 |
| 01:54 |
pinesol_green |
Launchpad bug 1189556 in Evergreen "Typo: 'Allows a user to process and verify ULSs'" (affected: 1, heat: 6) [Low,Confirmed] https://launchpad.net/bugs/1189556 |
| 01:54 |
bshum |
We'll have to fix those as well to figure out how to incorporate those upgrade script fixes in the 2.7 series. |
| 01:55 |
bshum |
dbs++ # seriously bummed that 2.7.0's upgrade script is wonky :( |
| 01:55 |
bshum |
bshum-- |
| 01:55 |
bshum |
Oh well. Something to ponder more today while avoiding the snow... |
| 05:15 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:31 |
paxed |
dbs: i'm going to steal some parts of your intro-to-git - i got tasked to teach git at work ... |
| 05:47 |
|
wsmoak joined #evergreen |
| 06:28 |
|
eeevil joined #evergreen |
| 11:40 |
Dyrcona |
csharp: You got that file from OCLC, or you exported it from Evergreen? |
| 11:41 |
csharp |
exported from Evergreen |
| 11:41 |
Dyrcona |
Never seen those particular errors from an Evergreen export before. |
| 11:41 |
csharp |
and that particular file has already been processed - I was using it as a test case for my perl script |
| 11:41 |
* csharp |
tries another |
| 11:42 |
Dyrcona |
I often have charset conversion errors when they want MARC8 and records with empty fields because of it. |
| 11:42 |
Dyrcona |
I'd ask OCLC if they'd accept MARC21XML. :) |
| 11:43 |
csharp |
maybe I can try MARC::Charset->ignore_errors() |
| 11:43 |
csharp |
ok |
| 11:44 |
Dyrcona |
csharp: All the vendors do. Our tools work. Why should we change them? |
| 11:44 |
bshum |
eeevil++ # fun reading indeed :) |
| 11:44 |
csharp |
well, since my script is theoretically sound, and the files I'm testing with have known issues, I'll try a new export and test on it. |
| 11:44 |
csharp |
Dyrcona: thanks for being a sounding board |
| 11:45 |
csharp |
bshum: after the holiday, I'd love to compare notes with you on the Dell DBs |
| 11:45 |
Dyrcona |
csharp: You might have low ascii in some of your fields. |
| 11:45 |
bshum |
csharp: For sure! I think things have gone much better since we reformatted them (again) and made all the changes to the configs. |
| 11:46 |
Dyrcona |
It's not supposed to be there, but old data could have it. |
| 15:11 |
berick |
hm, right, user.js would need to live in the egCoreMod in that case (instead of egUserMod) |
| 15:27 |
|
artunit_ joined #evergreen |
| 15:51 |
|
Dyrcona joined #evergreen |
| 16:38 |
pinesol_green |
[evergreen|Lynn Floyd] Docs: Update to template receipt docs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3c40129> |
| 16:58 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:01 |
|
mmorgan left #evergreen |
| 17:39 |
|
artunit joined #evergreen |
| 18:52 |
|
dcook joined #evergreen |
| 05:00 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:51 |
|
wsmoak joined #evergreen |
| 05:51 |
|
wsmoak joined #evergreen |
| 06:31 |
|
mtate joined #evergreen |
| 10:43 |
jeff |
(because those do set physical_loc) |
| 10:43 |
Dyrcona |
jeff: Ok. I thought it might be to stop it loading in the library after I asked my question. |
| 10:43 |
|
krvmga joined #evergreen |
| 10:44 |
kmlussier |
eeevil: I was just testing out the code you added for https://bugs.launchpad.net/evergreen/+bug/1367926. |
| 10:44 |
pinesol_green |
Launchpad bug 1367926 in Evergreen "Add support for (nearly) direct access to the full unapi backend" (affected: 1, heat: 6) [Wishlist,New] |
| 10:44 |
kmlussier |
Using the example from your git branch, going to http://mlnc2.mvlcstaff.org/opac/extras/unapi?id=tag::U2@acp/CONC40000537{acn,bre,mra}/-/0/barcode&format=xml seems to work well. |
| 10:45 |
krvmga |
Under what circumstances might a staff client stay logged in, even if the PC is shut down? I had this question and I think the answer is "under no circumstances" but I want to be sure. |
| 13:41 |
dbs |
Ah, ye olde "ERROR: could not find trigger 5235330" at commit time. WUT? |
| 13:42 |
dbs |
https://bugs.launchpad.net/evergreen/+bug/1261355 |
| 13:42 |
pinesol_green |
Launchpad bug 1261355 in Evergreen 2.6 "2.4.3-2.5.0-upgrade-db.sql causing "could not find trigger" PostgreSQL error" (affected: 3, heat: 14) [Undecided,Fix released] |
| 13:47 |
csharp |
dbs: in my case, I had to comment out one of the sub-scripts that were apparently colliding and ran it separately - I didn't actually test the patch once I figured out my own hack |
| 13:47 |
csharp |
so csharp-- for not following up :-/ |
| 13:50 |
csharp |
so, I thought I would just throw this out there, to see if anyone is seeing a similar issue... |
| 13:50 |
csharp |
we're getting sporadic reports from libraries (some, but not all) where the staff client white screens when doing patron updates |
| 13:51 |
csharp |
and they get a Windows message that xulrunner has stopped responding |
| 13:51 |
dbs |
csharp: thanks; trying again to see what happens :0 |
| 13:51 |
dbs |
csharp: ugh. not a memory bloat thing? |
| 13:52 |
csharp |
dbs: apparently not. terran and I saw it happen and were able to see the Windows Task Manager at the time |
| 14:45 |
|
ericar joined #evergreen |
| 14:56 |
|
akilsdonk_ joined #evergreen |
| 15:03 |
|
krvmga joined #evergreen |
| 15:07 |
jboyer-isl |
A completely different question: Can anyone tell me when openils_dojo.js is created? I can see where it's defined (openils.profile.js) but not where it's built. |
| 15:07 |
jboyer-isl |
And of course, it doesn't exist on my test server. |
| 15:09 |
gsams |
question for the masses, supposing I'm not interrupting something, I'd like for fine alerts on renewals to only prompt once for the threshold. Is this possible? |
| 15:09 |
gsams |
currently the alert pops up for each item, and when you are talking about 50+ items it can really slow things down. |
| 15:10 |
|
dreuther_ joined #evergreen |
| 15:20 |
Dyrcona |
bshum: If it was minified away, I think the templates, etc. that refer to it should be updated, don't you? |
| 15:20 |
pinesol_green |
Launchpad bug 1076582 in Evergreen "Documentation explaining openils_dojo.js" (affected: 1, heat: 8) [Low,Confirmed] |
| 15:20 |
bshum |
"Secret sauce" |
| 15:20 |
kmlussier |
jihpringle: the patch for bug 1380709 is on mlnc3.mvlcstaff.org whenever you have time to test it. |
| 15:20 |
pinesol_green |
Launchpad bug 1380709 in Evergreen 2.6 "invoice print amounts-per-fund uses wrong value when item price varies" (affected: 1, heat: 8) [Undecided,New] https://launchpad.net/bugs/1380709 |
| 15:20 |
bshum |
It's used in building custom dojo builds |
| 15:20 |
bshum |
We reference it, but it's not built unless you follow those scratchpad notes |
| 15:28 |
bshum |
Good times... |
| 15:29 |
csharp |
jboyer-isl: thanks - sounds like we have the same issue |
| 15:29 |
bshum |
jboyer-isl++ |
| 15:36 |
jihpringle |
kmlussier: thanks, I'll test that patch later today :) |
| 15:49 |
jboyer-isl |
csharp, One more data point, I'm not certain what version PINES is on, but we've been seeing this on 2.5(.2) I can't remember if we were running into it on 2.2. |
| 15:58 |
csharp |
jboyer-isl: yep - we're on 2.5.1+ (which is probably pretty close to 2.5.2 |
| 15:58 |
csharp |
) |
| 16:06 |
dbwells |
If you install from a git checkout, you don't have it. |
| 16:06 |
dbwells |
It isn't actually tied into the install process. |
| 16:07 |
dbwells |
As you noticed it doesn't cause any errors if it isn't there, as Dojo just falls back to the separate file requests. |
| 16:07 |
jboyer-isl |
bshum, dbwells: sorry, I meant I think csharp's issue with the client hogging a core and dying is related to the last time we changed xulrunner. Since my test server builds out of git repos I understand why I don't have those dojo files now. :) |
| 16:08 |
bshum |
Ah, my bad too then. |
| 16:09 |
jboyer-isl |
(I'm working on building them as we speak, however, because I hate 404's and love speed. :) ) |
| 16:10 |
dbwells |
jboyer-isl: If you have any issues with the build, you can also just grab the one we throw in the releases from here: http://evergreen-ils.org/downloads/dojo.tgz |
