Time |
Nick |
Message |
01:20 |
|
mrisher_ joined #evergreen |
06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:56 |
|
collum joined #evergreen |
08:00 |
|
rjackson_isl_hom joined #evergreen |
08:06 |
|
mantis1 joined #evergreen |
08:07 |
|
AlexZgS joined #evergreen |
08:07 |
AlexZgS |
/!\ this channel has moved to ##hamradio /!\ |
08:10 |
|
justyns joined #evergreen |
08:10 |
justyns |
/!\ this channel has moved to #nyymit /!\ |
08:12 |
|
apollo13EL joined #evergreen |
08:12 |
apollo13EL |
/!\ this channel has moved to #nyymit /!\ |
08:12 |
|
bathtub_shark joined #evergreen |
08:12 |
bathtub_shark |
/!\ this channel has moved to #nyymit /!\ |
08:12 |
|
bairdmichxf joined #evergreen |
08:13 |
|
robinknL joined #evergreen |
08:13 |
robinknL |
/!\ this channel has moved to #nyymit /!\ |
08:14 |
|
fireworksFf joined #evergreen |
08:14 |
fireworksFf |
/!\ this channel has moved to #nyymit /!\ |
08:15 |
|
OlipromZ joined #evergreen |
08:15 |
OlipromZ |
/!\ this channel has moved to #nyymit /!\ |
08:35 |
|
mmorgan joined #evergreen |
08:44 |
|
terranm joined #evergreen |
08:54 |
|
rfrasur joined #evergreen |
09:15 |
|
Dyrcona joined #evergreen |
09:19 |
Dyrcona |
csharp: Since you pushed the branches to remove Python yesterday, I thought that I might suggest you look at the Java branches if time permits: https://bugs.launchpad.net/evergreen/+bug/1827051/comments/3 |
09:19 |
|
terranm joined #evergreen |
09:19 |
pinesol |
Launchpad bug 1827051 in OpenSRF "Removal of OpenSRF and Evergreen Java Libraries" [Low,New] |
09:20 |
Dyrcona |
Otherwise, I may just push them myself. :) |
09:23 |
|
jvwoolf joined #evergreen |
09:49 |
csharp |
Dyrcona: sure, I'll take a look when I get a moment |
09:54 |
Dyrcona |
csharp++ |
09:55 |
|
jvwoolf left #evergreen |
10:01 |
|
stephengwills joined #evergreen |
10:04 |
Dyrcona |
I've noticed that even with the fix for the proxy logging configuration in apache that the remote ip with websockets is always listed a 127.0.0.1. I suppose I should check the websocketd options/documentation/code to see if there's an option to specify a remote ip header. |
10:13 |
|
jvwoolf joined #evergreen |
10:25 |
JBoyer |
Dyrcona, I gave that a half-hearted effort at one point and I don't think there is yet. |
10:26 |
JBoyer |
but would love to be wrong about that. |
10:35 |
* Dyrcona |
has too many irons in the fire, as usual: So, why does update asset.copy set location = X where location = Y say it updates Z rows, but when I do select to verify after, the rows are unchanged? |
10:41 |
miker |
Dyrcona: tsbere's "push to closest same-labeled location" trigger, I bet |
10:44 |
Dyrcona |
tsbere strikes again! :) |
10:53 |
|
sandbergja joined #evergreen |
10:55 |
Dyrcona |
miker++ |
10:56 |
Dyrcona |
Yes, it is that trigger. We're trying to "move" copies from a branch locations to system locations with the same names. |
10:57 |
miker |
yep, gets me every time, too :) |
11:00 |
Dyrcona |
Do I remember correctly, or am I making this up, that you can disable a trigger inside of a transaction and that has no effect outside of the transaction? |
11:02 |
terranm |
mmorgan: which server were you testing when you tested this one? https://bugs.launchpad.net/evergreen/+bug/564026 |
11:02 |
pinesol |
Launchpad bug 564026 in Evergreen "Wishlist: add error msg when searching by ID" [Low,Confirmed] |
11:03 |
|
Cocopuff2018 joined #evergreen |
11:04 |
Dyrcona |
I think I'm making that up. |
11:04 |
mmorgan |
terranm: I was looking at that on our 3.6.1 production and training servers. This is when retrieving a bib by id via the cataloging menu, right? |
11:06 |
terranm |
mmorgan: yes, it's working fine on current master (see terran-testbox) so maybe it was a more recent change |
11:07 |
terranm |
checking our 3.6.1 production server... |
11:07 |
terranm |
Hmm, no, I'm getting a nice "Record not found" error message on our production server as well |
11:08 |
mmorgan |
terranm: Checking my master test server, I see Record not found. |
11:09 |
mmorgan |
Hmm. So this was fixed somewhere along the line? Maybe some local customization is breaking it. |
11:10 |
terranm |
That's what I'm guessing - I'm going to go ahead and close that lp bug unless you object |
11:10 |
mmorgan |
No objection here! |
11:10 |
terranm |
thx! |
11:11 |
mmorgan |
terranm++ |
11:17 |
|
nfBurton joined #evergreen |
11:39 |
|
khuckins joined #evergreen |
12:03 |
csharp |
Dyrcona: Java-removal branches for OpenSRF/Evergreen installed without incident on csharp-master.gapines.org (if you or anyone else wants a peek) |
12:04 |
csharp |
nothing to see, really, since it's removal of unused code |
12:05 |
csharp |
looks good to me - I'mma sign off on it |
12:06 |
csharp |
oops - I missed the signoff on the OpenSRF commit |
12:07 |
pinesol |
[evergreen|Bill Erickson] LP1910409 MARC Batch Edit Allows CSV Column 0 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6c0061d> |
12:07 |
pinesol |
[opensrf|Jason Stephenson] LP 1827051: Remove Java Code, etc. - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=6ffa04d> |
12:09 |
pinesol |
[evergreen|Jason Stephenson] LP 1827051: Remove Java Code - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=04c8f1f> |
12:11 |
csharp |
not sure if someone with rootly powers on git could amend my commit to add a signoff or if that's worth doing at all |
12:12 |
csharp |
also, since I've been using gitlab and github more often for other things, I want to move EG to one of those (self-hosted gitlab or otherwise), but that is not this day |
12:15 |
|
jihpringle joined #evergreen |
12:25 |
JBoyer |
csharp, I'm going to assume that it's ok that a signoff was missed so long as it was tested. Wouldn't be the first time, won't be the last. :) |
12:26 |
JBoyer |
csharp++ Dyrcona++ # yay code cleanup |
12:34 |
Dyrcona |
charp++ |
12:34 |
mmorgan |
@karma charp |
12:34 |
pinesol |
mmorgan: Karma for "charp" has been increased 1 time and decreased 0 times for a total karma of 1. |
12:35 |
mmorgan |
csharp++ |
12:42 |
Bmagic |
on my isue with acq matching invoices to old PO's - I wonder if this would happen when the san assigned to actor.org_unit is on the branch and not the system where all the PO's are? |
12:42 |
Bmagic |
actor.org_address rather |
12:42 |
csharp |
JBoyer: thanks |
12:44 |
Bmagic |
my theory is that the EDI.pm code found a matching san on a branch. Then later tries to lookup PO candidates from that org, found none, and attached the invoices to the "first" PO that came out of a PG query? |
12:46 |
|
jihpringle joined #evergreen |
12:47 |
|
BAMkubasa joined #evergreen |
12:52 |
|
terranm joined #evergreen |
13:00 |
|
mrisher joined #evergreen |
13:00 |
csharp |
Bmagic: that might explain why we don't see it in PINES, since we're all system-oriented for acq (no per-branch setups) |
13:01 |
Bmagic |
same here, but the san is incorrectly assigned at the branch level in actor.org_address, which, hopefully is* the issue |
13:01 |
csharp |
oh - hmm |
13:02 |
Bmagic |
according EDIReader.pm, the purchase order number is included in the INVOIC EDI message and the PO number is assigned directly from the reference in the message. Confirmed by looking at the EDI message in question |
13:03 |
Bmagic |
some how some way, Evergreen is connecting invoice_entry to lineitem's associated with a PO from 2013 |
13:04 |
Dyrcona |
mmorgan++ |
13:04 |
Dyrcona |
mmorgan: I did something like that yesterday, too. |
13:04 |
mmorgan |
typos-- :) |
13:05 |
berick |
Bmagic: it can also pull the PO ID from the lineitems in the invoice message |
13:06 |
Bmagic |
berick: yes! I was just reading that code.... looking |
13:17 |
terranm |
Bmagic: I've lost track of what time you last rebuilt your test server - do you recall if Bill's most recent commit on this one is on there? https://bugs.launchpad.net/evergreen/+bug/1888723 |
13:17 |
pinesol |
Launchpad bug 1888723 in Evergreen "Holdings and Item Attributes Editors (VolCopy) Angular Port" [Wishlist,New] |
13:20 |
Bmagic |
terranm, his branch was merged at this time Feb 9 16:06:35 |
13:20 |
terranm |
Bmagic++ |
13:21 |
Bmagic |
I took a look at the source, and the last commit onto that branch DID NOT make it into the test machine |
13:22 |
Bmagic |
neither did this one https://git.evergreen-ils.org/?p=working/Evergreen.git;a=blobdiff;f=Open-ILS/src/eg2/src/app/staff/cat/volcopy/volcopy.service.ts;h=46d9b39dc7aa1bc8f40b96f90dffd7ac10958de9;hp=1396a8d346c8692e6f5103bc4aaee8665246f714;hb=9413ae89f1f71a3ea720532289849baf0c566a41;hpb=99ef208257f7578449c4ae71410e9dc43c71f217 |
13:23 |
Bmagic |
looking back through the branch, there are quite a few commits that are not on the test server |
13:26 |
Bmagic |
I used this command: git merge working/user/berick/lp1888723-angular-volcopy-v8 and it was successful. Now that you've got me looking at the git log, I' |
13:27 |
Bmagic |
I'm not seeing his commit messages. Maybe I don't understand what git merge does to my branch. Should it make the same number of commits as his branch? |
13:27 |
Dyrcona |
I was rereading bug 608308 just now, and it made me think: Has anyone started a branch to remove XUL? |
13:27 |
pinesol |
Launchpad bug 608308 in Evergreen "receipt template macros should have access to address, phone numbers" [Wishlist,Confirmed] https://launchpad.net/bugs/608308 - Assigned to Terran McCanna (tmccanna) |
13:35 |
Dyrcona |
JBoyer: I took the liberty of creating https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2021-03-09 |
13:36 |
JBoyer |
Dyrcona++ |
13:37 |
JBoyer |
I meant to when I moved the 2/2 meeting around and got distracted |
13:38 |
Dyrcona |
Well, I added scheduling the removal of XUl to new business. |
13:39 |
JBoyer |
+1 |
13:41 |
terranm |
Bmagic: Thanks for checking - I do not have any experience with git merge yet, so I have no feedback on that! |
13:50 |
|
jvwoolf joined #evergreen |
13:51 |
|
jvwoolf1 joined #evergreen |
14:00 |
Dyrcona |
Bmagic: Merge reorders commits by date. I'd recommend the following: |
14:01 |
Dyrcona |
git checkout -b <branchname> working/user/berick/lp1888723-angular-volcopy-v8 ; git rebase origin/master |
14:02 |
Dyrcona |
Where <branchname> is what ever you want to call your testing branch. |
14:03 |
Dyrcona |
If the rebase has conflicts, don't bother trying to resolve them, just comment on the bug that it needs a rebase on master, and move on to another bug. |
14:03 |
Dyrcona |
You can clean up a failed rebase with git rebase --abort |
14:11 |
|
terranm joined #evergreen |
14:20 |
rjackson_isl_hom |
csharp++ just because!!! (thanks csharp) |
14:20 |
Bmagic |
berick: Dyrcona: here we go. A theory is starting to formulate. Take a look at this regex /^RFF\+LI:(?:[^\/]+\/)?(\d+)/ |
14:21 |
Bmagic |
and take a look at this EDI message fragment |
14:21 |
Bmagic |
RFF+ON:199189'RFF+LI:199189EasyHoliday/7370'ALC+A++++DI'PCD+3:0'LIN+3++9780310769064 |
14:22 |
Bmagic |
It appears that the edi_li->id is getting assigned "7370" |
14:22 |
Bmagic |
which matches acq.lineitem.id from 2013 |
14:22 |
berick |
Bmagic: Open-ILS/src/support-scripts/test-scripts/edi_reader.pl can be used to see what EDIReader produces, BTW |
14:23 |
Bmagic |
ah! right! I'll double check the theory |
14:25 |
Bmagic |
berick++ # confirmed: 'id' => '7370', |
14:26 |
Bmagic |
so the big question is: do we have a bug? |
14:29 |
Bmagic |
going back to the order that was sent - we setup those LI's to have that identifier "RFF+LI:199189EasyHoliday/737022" |
14:29 |
Bmagic |
and now the picture is becoming clear. It looks like to me, the vendor truncated that identifier!!! |
14:31 |
Bmagic |
The smoking gun is right there. "RFF+LI:199189EasyHoliday/737022" != "RFF+LI:199189EasyHoliday/7370" |
14:31 |
Bmagic |
whoohoo! What a nightmare |
14:32 |
Bmagic |
I couldn't sleep very well these last few days.. being defeated like this, now, I bet I sleep like a baby |
14:33 |
jeffdavis |
Bmagic++ |
14:33 |
terranm |
Bmagic++ |
14:34 |
Bmagic |
I'm laughing, what a relief |
14:34 |
berick |
Bmagic++ |
14:34 |
Dyrcona |
Bmagic: Can I say I told you so? " the vendor truncated that identifier" :) Bmagic++ |
14:35 |
Bmagic |
Dyrcona: holy smokes, if you said that, I owe you an apology for not understanding exactly what you meant. I guess I had to get there on my own. Am I late to this party? Does this happen to everyone else? |
14:41 |
berick |
Bmagic: they truncate other things. never seen this case in particular, though |
14:41 |
Dyrcona |
Bmagic: As I mentioned on Friday, some vendors have stupidly small limits on identifiers, like 12 characters or so. It's best to keep those things short. |
14:42 |
Bmagic |
in theory, our ID numbers can outgrow their limit even if we didn't name the PO anything other than the default ID number. <POname>/<lineitem.id> > 22 characters in the future |
14:42 |
Dyrcona |
Not just in theory, but in practice, too. |
14:45 |
jeffdavis |
I'm remembering the bit in Jurassic Park (the book) where they didn't realize the dinosaurs were breeding because the program only counted them up to their expected number, rather than showing the actual total. |
14:45 |
jeffdavis |
That part always felt particularly realistic to me. |
14:46 |
Bmagic |
jeffdavis++ |
14:47 |
berick |
ah, the old Too Many Dinosaurs bug |
14:47 |
* berick |
adds lp tag |
14:47 |
jeffdavis |
:) |
14:48 |
csharp |
jeffdavis++ |
14:49 |
Dyrcona |
It could be that this vendor expects the line item number to be unique per order/invoice, and 9999 items is enough for any given order. |
14:50 |
Dyrcona |
Re Jurassic Park: What always bugged me is these biologists seem totally unaware that parthenogenesis is common among saurian species, and they only made females.... |
14:53 |
Dyrcona |
Not having read the novel, I'll blame Michael Crichton. :P |
14:54 |
Bmagic |
Dyrcona: I was thinking along those lines as well - where we could create a new internal column just for the purposes of connecting the LI's back |
14:55 |
Bmagic |
I think it's reasonable to say that Evergreen should do some kind of sanity check when connecting these LI's - at least that the acq.lineitem.purchase_order = PO reference in the message |
14:55 |
Bmagic |
I'm not sure "how" or what it should do when they are not equal |
14:56 |
Dyrcona |
I'm not really sure how to fix it, and I'm just guessing/making assumptions about the reason for the problem on the vendor's end. |
15:01 |
|
dbwells joined #evergreen |
15:03 |
|
dbwells_ joined #evergreen |
15:05 |
Dyrcona |
Does anyone else have the hamburger menu clip off screen when using the Angular staff client? |
15:06 |
Dyrcona |
Also the cursor changes to the I beam and not the finger/click on a link pointer. |
15:08 |
berick |
Dyrcona: yes |
15:11 |
Dyrcona |
berick: Should I open a Lp? Is there on already? I just made a screenshot. |
15:11 |
berick |
Dyrcona: i don't believe there is an LP yet, so a new one would be appreciated |
15:12 |
Dyrcona |
OK. I'll do that. |
15:14 |
csharp |
re: Jurassic Park: it's a UNIX system - I know this |
15:15 |
pinesol |
[evergreen|Jason Stephenson] Lp 1913219: Use window.open for staff catalog edit link - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6a4a3a7> |
15:15 |
pinesol |
[evergreen|Jane Sandberg] Lp 1913219: Use window.open for staff catalog edit link; angular version - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b8ae9f0> |
15:21 |
Dyrcona |
Hmm. Maybe I should have looked at 3.5 a bit harder before pushing that. Oh well, life goes on. |
15:30 |
pinesol |
[evergreen|Bill Erickson] LP1907115 MARC editor correctly absorbs breaker changes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=10339d1> |
15:30 |
pinesol |
[evergreen|Bill Erickson] LP1907115 MARC editor avoid ID collisions - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2dbb92d> |
15:32 |
Dyrcona |
berick: bug 1915323 |
15:32 |
pinesol |
Launchpad bug 1915323 in Evergreen "Angular Staff Client Hamburger Menu Clipped off screen" [Undecided,New] https://launchpad.net/bugs/1915323 |
15:32 |
|
mantis1 left #evergreen |
15:33 |
berick |
Dyrcona++ |
15:41 |
JBoyer |
berick, not urgent, but I figure you have a good chance of knowing a simple for bug 1915326 |
15:41 |
pinesol |
Launchpad bug 1915326 in Evergreen "AngularJS egOrg tests fail" [Low,New] https://launchpad.net/bugs/1915326 |
15:42 |
JBoyer |
Basically, referencing lf (for lf.isOffline) breaks the tests since lf isn't defined at that point. |
15:45 |
* berick |
calls 1245 |
15:50 |
JBoyer |
Though if there's no better fix than if ( (lf && lf.isOffline) ... I can throw that branch together |
16:00 |
pinesol |
[evergreen|Galen Charlton] LP#1474029: teach Evergreen how to prevent expired staff from logging in - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=18f5404> |
16:00 |
pinesol |
[evergreen|Bill Erickson] LP1474029 Stamping DB upgrade: expired staff no-login - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c118b74> |
16:08 |
|
malexander joined #evergreen |
16:16 |
|
dbwells joined #evergreen |
16:22 |
|
terranm joined #evergreen |
16:23 |
|
jihpringle joined #evergreen |
16:24 |
Dyrcona |
I have successfully tested the backport of sandbergja's Angular fix on bug 1913219 to rel_3_5. Should I just push it or does anyone else want to have a look on 3.5? |
16:24 |
pinesol |
Launchpad bug 1913219 in Evergreen 3.5 "Edit from OPAC View doesnt' close on Save & Exit" [Medium,Confirmed] https://launchpad.net/bugs/1913219 - Assigned to Jason Stephenson (jstephenson) |
16:29 |
csharp |
Dyrcona: got for it |
16:29 |
csharp |
er... *go* for it |
16:32 |
Dyrcona |
Well, I just updated the bug saying that I'd wait a day or two. |
16:41 |
|
sandbergja joined #evergreen |
17:13 |
|
mmorgan left #evergreen |
17:14 |
|
sandbergja joined #evergreen |
17:15 |
sandbergja |
conference_team++ # I love that the hackfest doesn't conflict with the pre-conferences |
17:15 |
terranm |
Ooh, nice |
17:19 |
berick |
yeah, that's great |
17:25 |
|
malexander joined #evergreen |
17:56 |
|
dbwells joined #evergreen |
17:58 |
|
dbwells joined #evergreen |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:11 |
|
dbwells joined #evergreen |
18:16 |
|
sandbergja_ joined #evergreen |
20:09 |
|
sandbergja_ joined #evergreen |
20:32 |
|
mrisher joined #evergreen |
20:40 |
|
sandbergja_ joined #evergreen |
20:44 |
|
sandbergja_ joined #evergreen |