| Time |
Nick |
Message |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:06 |
|
rjackson_isl joined #evergreen |
| 07:19 |
pinesol_green |
[evergreen|Galen Charlton] LP#1716486: fix hotkeys - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bb85fcd> |
| 07:32 |
csharp |
@quote add * miker shakes fist at the heavens, "U T F EEEEEEIIIIIGGGGGHHHHTTTTT!" |
| 07:32 |
pinesol_green |
csharp: The operation succeeded. Quote #175 added. |
| 07:46 |
csharp |
@later tell RyanM see https://bugs.launchpad.net/evergreen/+bug/1541801 - should be fixed in the web client for 2.12 and newer (but not the XUL staff client) |
| 07:46 |
pinesol_green |
csharp: The operation succeeded. |
| 07:46 |
pinesol_green |
Launchpad bug 1541801 in Evergreen "search fields in z39.50 sort in random order" [Medium,Fix released] |
| 07:51 |
pinesol_green |
[evergreen|Cesar Velez] LP#1697716 - Webstaff adds ability to display actor.usr.photo_url if present - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=484acd7> |
| 08:05 |
csharp |
seeing a reference to a new(?) perm in the web client, UPDATE_ORG_UNIT_SETTING.prog, which I can't find any references to in the code: http://picpaste.com/web-client-perm-kXoHhPyd.jpg |
| 08:17 |
|
abowling1 joined #evergreen |
| 08:33 |
|
kmlussier joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 08:44 |
|
mdriscoll joined #evergreen |
| 08:45 |
|
Dyrcona joined #evergreen |
| 08:47 |
Dyrcona |
miker: I didn't try building a new staff client. However gmcharlt's patch for OpenSRF fixed things for me last night without requiring any reinstall of Evergreen. |
| 08:47 |
Dyrcona |
I can try today with a newly built client, since I'm planning to build a fresh vm anyway. |
| 08:51 |
miker |
Dyrcona: nah, further inspection makes that seem unnecessary |
| 08:54 |
csharp |
do y'all expect the code to change much more? there was talk of reverting a commit yesterday |
| 08:54 |
|
_adb joined #evergreen |
| 08:54 |
* csharp |
needs the fix, just wants to be sure we're on sure footing before experimenting too much |
| 08:57 |
Dyrcona |
csharp: I'm confident that gmcharlt's patch that I pushed last night fixes the problem. |
| 08:57 |
Dyrcona |
I'm going to build a new vm today to do some more testing. |
| 08:58 |
Dyrcona |
This is mainly 2.10.7 -> 2.12.5 upgrade testing, but this code will get another workout. |
| 08:59 |
Dyrcona |
I've got another machine that I'm supposed to install 3.0-beta onto, but I may just go with master. |
| 08:59 |
Dyrcona |
Until rel_3_0 is branched, that is. |
| 09:01 |
Dyrcona |
heh. It helps not to typo the db user name, huh? :) |
| 09:02 |
Dyrcona |
FATAL: password authentication failed for user "evergren" |
| 09:03 |
csharp |
Dyrcona: thanks ;-) |
| 09:04 |
Dyrcona |
Anyway, I think it is safe to apply the patch from last nigh if you've already installed OpenSRF 2.5.1. |
| 09:05 |
Dyrcona |
Oh, I can see it's going to be one of those typo kind of days. |
| 09:05 |
Dyrcona |
This is where testing with production data comes in handy. |
| 09:08 |
gmcharlt |
I am inclined to cut 2.5.2 now; the other changes can wait |
| 09:08 |
gmcharlt |
thoughts? |
| 09:09 |
|
bos20k joined #evergreen |
| 09:14 |
Bmagic |
the public needs the latest fix for openSRF to pair with Evergreen, so, if 2.5.2 is the way to do that, then yes |
| 09:14 |
csharp |
gmcharlt: makes sense to me |
| 09:18 |
miker |
gmcharlt: I'm for reverting the encode patch, but if you want to cut it right now, I agree it can wait |
| 09:28 |
|
yboston joined #evergreen |
| 09:29 |
gmcharlt |
OK, I'll proceed |
| 09:33 |
jeff |
csharp: do you have a permission with code UPDATE_ORG_UNIT_SETTING.prog defined in permission.perm_list? |
| 09:34 |
jeff |
csharp: and if so, is that permission's numeric id present in the update_perm or view_perm of any rows in config.org_unit_setting_type? |
| 09:34 |
|
jvwoolf joined #evergreen |
| 09:37 |
Dyrcona |
miker: Why do you want to revert the encode patch? It seems like the right thing to do. |
| 09:38 |
miker |
Dyrcona: it's not necessary. we don't actually put 2+ byte chars in json strings we publish. we always \u-escape them. so bytes == chars for json we publish |
| 09:38 |
jeff |
csharp: Actually, that's probably not going to help. There is a group of org unit settings called 'prog', and that permission prompt is probably because your user lacks the UPDATE_ORG_UNIT_SETTING_ALL permission at the relevant context ou / depth, and it's trying to look for UPDATE_ORG_UNIT_SETTING.prog (where prog is the name of the group of settings that you're editing, as defined in config.org_unit_setting_type). |
| 09:38 |
miker |
so, it's not only unnecessary, but it's confusing for future us'es |
| 09:39 |
Dyrcona |
miker: Ah. OK. I didn't realize that. JSON is often UTF-8 in other contexts. |
| 09:39 |
miker |
I went through a 15-min code hunt last night because I though "oh know, could we be cutting chars in half in the C code?" but we're safe because of that -^ |
| 09:39 |
miker |
oh,sure |
| 09:39 |
miker |
we can read regular utf8 data just fine |
| 09:40 |
miker |
so if some other json producer sends us wide chars, we're fine |
| 09:40 |
miker |
but this is all about what we publish |
| 09:40 |
Dyrcona |
Right. |
| 09:40 |
Dyrcona |
Well, I'm OK with reverting the patch. |
| 09:40 |
jeff |
csharp: I'm not certain that the "perm for a group of org unit settings" is automatic, though... so you might find it's defined explicitly locally, and "prog" was just a useful name. |
| 09:41 |
miker |
so the main thing I want to do is replace the enode patch with a comment that explains why bytes==chars there, so I don't repeat myself in 2 years ;) |
| 09:42 |
Dyrcona |
:) |
| 09:42 |
csharp |
jeff++ # found it |
| 09:43 |
csharp |
there's one coust entry with that perm - I've got it from here - thanks for the pointers |
| 09:44 |
|
stephengwills joined #evergreen |
| 09:44 |
jeff |
csharp: you're welcome! per usual, it's a good excuse to learn/refresh for me. :-) |
| 09:45 |
miker |
s/know/no/ Dyrcona, your typos are becoming contagious |
| 09:45 |
Dyrcona |
hah |
| 09:49 |
gmcharlt |
if Dyrcona's typos are now contagious... I am utterly doomed |
| 09:51 |
rhamby_ |
I have enough of my own typos without adding Dyrcona's to it ..... |
| 09:54 |
Dyrcona |
@blame Dyrcona's typos |
| 09:54 |
pinesol_green |
Dyrcona: Dyrcona's typos stole Dyrcona's ice cream! |
| 09:54 |
gmcharlt |
apropos of yesterday: https://gitlab.com/snippets/1675203 |
| 09:54 |
* csharp |
sprays keyboard with typo-b-gone anti-error spray |
| 09:55 |
dbwells |
miker: Here you go: http://git.evergreen-ils.org/?p=working/OpenSRF.git;a=shortlog;h=refs/heads/collab/dbwells/revert_perl_encode_byte_counting |
| 09:55 |
gmcharlt |
@quote add csharp sprays keyboard with typo-b-gone anti-error spray |
| 09:55 |
pinesol_green |
gmcharlt: The operation succeeded. Quote #176 added. |
| 09:55 |
|
stephengwills joined #evergreen |
| 09:59 |
* mmorgan |
wonders if there's also a thinko-be-gone anti-error spray. Could use some of that ;-) |
| 10:03 |
dbwells |
miker: and https://bugs.launchpad.net/opensrf/+bug/1717526 |
| 10:03 |
pinesol_green |
Launchpad bug 1717526 in OpenSRF "Revert unnecessary encode for byte counting" [Undecided,New] |
| 10:09 |
gmcharlt |
https://evergreen-ils.org/opensrf-2-5-2-released/ |
| 10:13 |
csharp |
gmcharlt++ |
| 10:16 |
kmlussier |
gmcharlt++ |
| 10:20 |
|
rlefaive joined #evergreen |
| 10:25 |
miker |
gmcharlt++ |
| 10:26 |
bos20k |
Hello. Is my assumption correct that going from OpenSRF 2.5.1 to 2.5.2 does not require an Evergreen recompile to eliminate the bug? |
| 10:26 |
gmcharlt |
bos20k: correct |
| 10:26 |
bos20k |
gmcharlt++ |
| 10:26 |
miker |
dbwells++ # we may, however, want to store and use $num_bytes ... should be faster than calling length repeatedly |
| 10:26 |
miker |
dbwells: I'll add a commit for that, and also add a comment to the C code |
| 10:30 |
miker |
well, or just use $raw_length |
| 10:54 |
csharp |
so piggybacking on bos20k's question - no other recompilation is required to go from 2.5.0 to 2.5.2, yes? |
| 10:55 |
csharp |
I didn't see my acq problem fixed after installing in place on an Evergreen app (utility) server |
| 10:55 |
csharp |
so trying to rule out bonehead reasons |
| 10:56 |
miker |
csharp: no recompiling EG, but possibly a ldconfig, and definitely a full opensrf and apache restart |
| 10:57 |
csharp |
k - thanks |
| 11:10 |
Bmagic |
We have been using EDI for years. We just added a new provider and we are getting errors when processing thier invoice EDI. "Unable to determine buyer (org unit)" |
| 11:13 |
miker |
csharp: an autogen wouldn't hurt (partly for the data it collects and writes, and partly to get a new eg_hash key) |
| 11:14 |
Bmagic |
Looking at the EDI message, I find that the syntax is the same as the EDI invoices from other vendors. specifically the NAD+BY clause matches the EDI Account "Account" setting and "Vendor Account Number" |
| 11:17 |
berick |
Bmagic: matches the "account" or "vendacct" ? |
| 11:18 |
Bmagic |
both acctually |
| 11:18 |
berick |
k |
| 11:18 |
Bmagic |
I might have found something though |
| 11:20 |
Bmagic |
berick: for some reason, it looks like Evergreen is using the "username" field and matching NAD+BY with it? Is that right? |
| 11:21 |
Bmagic |
The username for the FTP account |
| 11:22 |
berick |
no, ftp username is not used by EDI for anything (apart from connecting) |
| 11:23 |
berick |
well, arg |
| 11:23 |
Bmagic |
that makes me have to wonder how in the world the older provider messages are working at all then |
| 11:23 |
berick |
it does use the connection info as a way to prevent duplicate file processing |
| 11:23 |
Bmagic |
it wouldn't expect to find the FTP username embedded in the EDI message? |
| 11:23 |
berick |
no |
| 11:24 |
Bmagic |
for example the 31B+ clause in a successful message contains a string of numbers that is equal to our FTP username |
| 11:24 |
Bmagic |
And is found no where else in Evergreen's config |
| 11:25 |
berick |
31B should be the SAN value |
| 11:25 |
Bmagic |
in addition, the NAD+BY+ clause contains that very same string of numbers followed by a space and the Vendor Account number: {FTP Username}\s{vendor account number} |
| 11:25 |
Bmagic |
Who's SAN? |
| 11:25 |
Dyrcona |
I'm not SAN are you SAN? |
| 11:26 |
Bmagic |
whose |
| 11:26 |
Bmagic |
lol |
| 11:26 |
berick |
NAD+BY 31B should match one of your actor.org_address.san values |
| 11:26 |
Dyrcona |
It's the SAN from the account setup. I forget exactly where it .... |
| 11:26 |
berick |
NAD+SU 31B should match the vendor SAN |
| 11:26 |
Bmagic |
this is where it gets funny, because we don't have any values in the actor.org_address.san |
| 11:27 |
Bmagic |
which might be why the new vendor EDI messages are failing, but how in the world did 2 years worth of invoice EDI messages work just fine without that value set in actor.org_address |
| 11:28 |
berick |
Bmagic: some vendors don't strictly require it, presumably because they know who you are based on where you are delivering your EDI files. |
| 11:29 |
berick |
and for inbound messages, a vendcode / vendacct can act as a surrogate to a SAN value |
| 11:30 |
Bmagic |
berick: in the context of invoicing (Vendor -> Evergreen), Evergreen deciphers the NAD+BY clause to match an edi_account row? |
| 11:31 |
berick |
Bmagic: yes |
| 11:32 |
Bmagic |
man that is strange |
| 11:32 |
berick |
it starts by pulling everything it can from all active accounts, then tries to find better matches to edi_account rows based on the content of the NAD+BY values |
| 11:32 |
csharp |
is anyone else on 2.12/2.5.X seeing broken A/T on PO JEDI? |
| 11:32 |
Bmagic |
with the data I am seeing in that clause, it shouldn't have been able to match a row UNLESS it's looking at the FTP username |
| 11:33 |
berick |
Bmagic: the first step in the process is to connect an FTP site and pull files. it does that for every edi account. without any other data to go on (i.e. nad+by) it uses the edi_account that was the source of the ftp information to begin with. make sense? |
| 11:33 |
Bmagic |
maybe the NAD+BY clause is split on the space character, and it's strictly look at the second section and only matching on vendor account number? |
| 11:34 |
Bmagic |
oh, that does make sense |
| 11:34 |
berick |
nad+by is used to improve matching where possible |
| 11:35 |
Bmagic |
alright, well, I am going to fill in the value for actor.org_address.san and see if it can make the org unit match |
| 11:36 |
Dyrcona |
Bmagic: Line 520 in OpenILS::Application::Acq::EDI gets the buyer SAN and vendor code from an incoming message. |
| 11:36 |
Dyrcona |
Sorry, line 529... |
| 11:36 |
Bmagic |
right on |
| 11:36 |
Bmagic |
berick++ |
| 11:36 |
Bmagic |
Dyrcona++ |
| 11:36 |
Dyrcona |
I don't see anywhere that a SAN i put into an outgoing message. |
| 11:37 |
Dyrcona |
And yeah, right after that it looks up the address by SAN. ;) |
| 11:39 |
Dyrcona |
csharp: I haven't test a/t on 2.12. I probably should after making sure email goes nowhere. |
| 11:54 |
|
jvwoolf1 joined #evergreen |
| 11:57 |
|
sandbergja joined #evergreen |
| 11:58 |
csharp |
Dyrcona: A/T generally works - email notices are working fine - just the PO JEDI event with the undef variables that I'm trying to suss out |
| 11:59 |
Dyrcona |
You're also using Ubuntu 16.04, yes? |
| 11:59 |
Dyrcona |
I'll see if I can take a look at that specifically if you don't figure it out in the mean time. |
| 11:59 |
Dyrcona |
That will affect us, too, I'm sure. |
| 12:00 |
csharp |
we reverted to 14.04 to not change too many things at once |
| 12:00 |
csharp |
moving to 16.04 with 3.0 |
| 12:03 |
Bmagic |
csharp: 2.12.x is still ruby? 3.0 is not? |
| 12:04 |
csharp |
Bmagic: right |
| 12:04 |
csharp |
but this breaks before the pusher gets into the picture |
| 12:04 |
Dyrcona |
csharp: You installed the latest patch for chunking? |
| 12:05 |
csharp |
Dyrcona: yep - installed OpenSRF 2.5.2 (via our deb-building process) |
| 12:05 |
csharp |
if I can't get it working, I'll start with a manual build somewhere to rule those auxilliary issues out |
| 12:06 |
csharp |
but our debs are pretty solid - I'd be surprised if that ends up being the problem |
| 12:06 |
Dyrcona |
I still have to straighten out my branches, so it might be Monday before I can really have a look. |
| 12:16 |
csharp |
yeah, still crapping out |
| 12:17 |
csharp |
2017-09-15 12:16:24 next-utility01 open-ils.trigger: [ERR :29036:Event.pm:526:] Can't call method "class_name" on an undefined value at /usr/local/share/perl/5.18.2/OpenILS/Application/Trigger/Event.pm line 594. |
| 12:17 |
csharp |
always twice |
| 12:17 |
csharp |
which matches this: https://pastebin.com/raw/CHpP91fn |
| 12:19 |
|
khuckins joined #evergreen |
| 12:28 |
|
jihpringle joined #evergreen |
| 12:47 |
csharp |
you know, I think this has to be related to the template (or the data underlying it) |
| 12:48 |
csharp |
bshum put that idea in my head |
| 12:48 |
csharp |
the template hasn't changed between 2.11 and 2.12 |
| 12:54 |
Dyrcona |
That paste looks familiar. :) |
| 13:10 |
Dyrcona |
csharp: You have not Lp'd this acquisitions issue, yet, right? |
| 13:16 |
csharp |
correct |
| 13:16 |
csharp |
I'd like some confirmation from the field that it's not just us, but I can LP it |
| 13:19 |
Dyrcona |
I'm going to see if I can reproduce it on training. I've got some old events there that are still pending. |
| 13:19 |
Dyrcona |
Training has 2.5.0 and 2.12.4. |
| 13:19 |
Dyrcona |
Looks like I have 10 events from July. |
| 13:21 |
csharp |
https://bugs.launchpad.net/evergreen/+bug/1717563 |
| 13:21 |
pinesol_green |
Launchpad bug 1717563 in Evergreen "PO JEDI event broken on EG 2.12/OpenSRF 2.5" [Undecided,New] |
| 13:21 |
Dyrcona |
Looks like I just run pending. |
| 13:21 |
csharp |
I may put in the stock PO JEDI template to see if it works |
| 13:23 |
berick |
csharp: if you do, use the the stock environment too. could be the env fetching that's causing problems. |
| 13:24 |
Dyrcona |
Whee! tail -f /openils/var/log/osrfsys.log goes by too fast to follow. |
| 13:25 |
csharp |
berick: will do |
| 13:25 |
* berick |
always has to read "Fix for Web Client Copy Editor Fix" twice |
| 13:25 |
csharp |
I did verify that the template/environment/params have not changed between versions |
| 13:26 |
csharp |
but I haven't tested against stock yet |
| 13:26 |
Dyrcona |
csharp: You added lines to log the context, yeah? |
| 13:26 |
csharp |
yes |
| 13:27 |
kmlussier |
miker: mmorgan and I already verified the search slowness is still a problem on 2.5.1. Do you think 2.5.2 will make a difference? |
| 13:27 |
Dyrcona |
my events all went to invalid, but it could be because they are so old. |
| 13:28 |
miker |
kmlussier: that's what I want to test, yes. 2.5.1 has a bad bug, so an upgrade to the brand new 2.5.2 is indicated in any case |
| 13:28 |
Dyrcona |
I don't know enough about acq to setup an invoice to have a fresh one. |
| 13:28 |
csharp |
invalid probably means they aren't EDI vendors |
| 13:28 |
mmorgan |
miker: kmlussier: We slipped in the 2.5.2 fix this morning on our training server and still saw the issue. |
| 13:29 |
* csharp |
makes a sad face at mmorgan's last :-( |
| 13:29 |
csharp |
we're getting slow/timeout on searching too |
| 13:29 |
kmlussier |
Sure, I'll also update the OpenSRF on the test system I've been using just to be sure. |
| 13:29 |
* mmorgan |
forgot to supply same :-( |
| 13:30 |
* csharp |
was hoping the latest fixes would Just Work™ |
| 13:31 |
miker |
mmorgan: thanks, that's the confirmation I wanted. I just wanted to take something off the table to look at |
| 13:33 |
berick |
Dyrcona: to test the ACQ A/T stuff, i think all you need to do is activate a PO whose provider has an edi_default value |
| 13:33 |
berick |
the edi_account itself can be all dummy data |
| 13:33 |
csharp |
yeah |
| 13:34 |
Dyrcona |
berick: 1) I have no idea how to actually use acq. 2) I have 3-month old data that I can test with at the moment. |
| 13:34 |
Dyrcona |
I just make the dog food. I don't eat it. :) |
| 13:34 |
berick |
heh |
| 13:34 |
berick |
but it's delicious! |
| 13:34 |
berick |
i'll try on concerto real fast |
| 13:35 |
csharp |
in related news, our new Acq person is coming to the Hack-A-Way so we'll have a process expert in-house like we did at NOBLE |
| 13:35 |
berick |
TFW you remember you don't have to launch the XUL client |
| 13:35 |
csharp |
berick: did that earlier |
| 13:35 |
csharp |
"wait, why did I bother opening this?" |
| 13:36 |
berick |
:) gonna take some getting used to |
| 13:41 |
berick |
csharp: tested on master/master w/ stock data. had no problem generating JEDI. |
| 13:41 |
berick |
order had 1 LI and 25 copies, so not huge |
| 13:43 |
* berick |
is also using the large max_stanza_size, in case it's relevant |
| 13:49 |
csharp |
yeah our max_stanza_size is at 2000000 |
| 13:53 |
Dyrcona |
mine is the default 65536 |
| 13:53 |
Dyrcona |
Of course, my events failed to validate, so that's no helpful at this point. |
| 13:58 |
berick |
reminder to set an edi_default value on the provider after creating the edi_account. |
| 13:58 |
* berick |
got stuck on that |
| 14:03 |
* csharp |
just busted his test server by inserting the stock PO JEDI template into ALL THE EVENT DEFS |
| 14:04 |
csharp |
I was about to blow it away to start testing 3.0 anyway |
| 14:04 |
csharp |
and I did preserve the old defs, but I don't want to worry about spending the required time fixing it |
| 14:04 |
berick |
YOU GET EDI, AND YOU GET EDI |
| 14:04 |
berick |
noooooo |
| 14:05 |
csharp |
@oprah EDI |
| 14:05 |
pinesol_green |
csharp: Yeah, well, you know, that's just, like, your opinion, man. |
| 14:05 |
csharp |
we need zoia in here |
| 14:05 |
csharp |
@blame EDI for ALL THE THINGS |
| 14:05 |
pinesol_green |
csharp: EDI is the SPY! for ALL THE THINGS |
| 14:13 |
jeffdavis |
csharp: the PO JEDI event def is generating events successfully for us. I know our template for that a/t is somewhat customized. |
| 14:15 |
csharp |
jeffdavis: berick: thank you both for confirmations |
| 14:17 |
Dyrcona |
@praise 15 bshum |
| 14:17 |
* pinesol_green |
The bshum abides. |
| 14:25 |
|
bos20k joined #evergreen |
| 14:25 |
|
jvwoolf joined #evergreen |
| 14:27 |
jeffdavis |
miker: re bug 1704396 - I don't think the smarter-chunk-length fixes from 1709710 is a factor since we don't have those on our system (we have a very large max_stanza_size for some reason: 4194304). I'll be upgrading to 2.5.2 in a few days anyway though, so we'll see if it helps. |
| 14:27 |
pinesol_green |
Launchpad bug 1704396 in Evergreen "Slowness for metarecord and one-hit searches in 2.12" [High,New] https://launchpad.net/bugs/1704396 |
| 14:28 |
jeffdavis |
I need to add some more logging to try and narrow that issue down. |
| 14:29 |
miker |
jeffdavis: well, the stanza size isn't really a factor in that. opensrf will chunk anything bigger than 50k in 2.5+ regardless, but the stanza size will protect you from the escaping bloat if you're using 2.5.0. 2.5.1, though, (and, possibly, 2.5.0 -- but I don't know that that's been positively confirmed) can drop characters altogether and break messages |
| 14:30 |
miker |
however, I think mmorgan provided enough confirmation that chunking does not seem to be at issue in this problem -- they're on 2.5.2 now and still seeing it |
| 14:31 |
jeffdavis |
Ah, I missed that update. Oh well. :( |
| 14:39 |
|
JBoyer joined #evergreen |
| 14:41 |
JBoyer |
kmlussier: could I trouble you for a login (and the rest of the address) on the mlnc3 tester that you and abneiman have been looking at for bug 1714390? |
| 14:41 |
pinesol_green |
Launchpad bug 1714390 in Evergreen "Fix for Web Client Copy Editor Fix" [Undecided,New] https://launchpad.net/bugs/1714390 |
| 14:42 |
kmlussier |
JBoyer: https://mlnc3.noblenet.org admin / evergreen123 |
| 14:42 |
JBoyer |
kmlussier++ |
| 14:43 |
abneiman |
I swear I'm not trying to ruin your weekend, JBoyer ;-) |
| 14:57 |
|
bwicksall joined #evergreen |
| 14:57 |
kmlussier |
JBoyer: Yes she is. ;) |
| 14:59 |
kmlussier |
Actually, it will make JBoyer more fully appreciate the weekend. |
| 14:59 |
JBoyer |
I'm starting to wonder if mlnc3 might be. ;p I've never seen the client do that before. |
| 15:00 |
JBoyer |
And since my weekend will largely be spent wedging cataloging template changes into things I'm not 100% sure it will. :) |
| 15:00 |
kmlussier |
Yeah, there are better ways to spend a weekend. |
| 15:04 |
kmlussier |
JBoyer: You said you're using it in production? On 2.12? Is it possible there's been a change since 2.12 that is messing with things? |
| 15:05 |
|
acautley joined #evergreen |
| 15:08 |
JBoyer |
I suppose it's possible, but that is such a simple function I can hardly believe it's that. I've got 3.0beta-ish on a dev server that I'll check on, it should also have that patch applied since it's got all of our local stuff on it. |
| 15:26 |
kmlussier |
abneiman / JBoyer: I just loaded the patch on another VM, also with master, and it works fine there. :/ |
| 15:27 |
abneiman |
kmlussier: server gremlins, clearly |
| 15:31 |
JBoyer |
It beats me going slowly insane, yelling "Why U no Decimal?!" at a machine several hundred miles away. |
| 15:31 |
gmcharlt |
JBoyer: too new-fangled |
| 15:31 |
gmcharlt |
MCMXVII is where it's at! |
| 15:31 |
JBoyer |
Any other not-yet-in-master patches on that machine? |
| 15:33 |
gmcharlt |
webby is now at the latest and greatest, by the way |
| 15:33 |
JBoyer |
gmcharlt: One way to cure all of our money-related woes: Every field that's currently a money field is changed to an interger, and we only accept cash-register entry (i.e. fixed, 2 decimal.) |
| 15:34 |
JBoyer |
Library clerks would join the ranks of retail workers in hating the period key on their keyboard and would form a bond that lasts the ages. |
| 15:34 |
gmcharlt |
:) |
| 15:34 |
Dyrcona |
JBoyer: Store and operate on integers, stored as pennies, i.e. 1/100th of the currency unit. Display it as decimal. |
| 15:35 |
Dyrcona |
Of course, that means you can't use currencies that go beyond 1/100. |
| 15:35 |
JBoyer |
Clumsy explanation of a clumsy joke. Entering numbers into a cash reg is like an ATM, you have to enter every digit including the cents, and if the cash reg has a period key it isn't valid to use. |
| 15:35 |
bshum |
So my bars of gold-pressed latinum are worthless after all :( |
| 15:35 |
kmlussier |
JBoyer: Yes, each of those machines has a different set of patches. But I listed the ones that are on the machine where it's broken on the general list. Let me find it... |
| 15:36 |
gmcharlt |
bshum: I distrust any currency that one can drink |
| 15:36 |
kmlussier |
http://markmail.org/message/ngtd4fsvybh2xfrh |
| 15:36 |
JBoyer |
kmlussier++I'm not in the office today and so haven't been keeping up with email as regularly as usual. Until abneiman tried to rain on my parade. ;) |
| 15:37 |
Dyrcona |
JBoyer: IOW, it accepts integer input in pennies. :) |
| 15:37 |
bshum |
gmcharlt: Haha, that is an interesting point I had not considered |
| 15:37 |
kmlussier |
JBoyer: Well, I didn't expect you to remember every email I sent to the list. It was just a nice and handy way for me to find out what was on there. |
| 15:38 |
kmlussier |
There is another patch that touches the copy editor. I'm going to load that one on my other VM right now. |
| 15:38 |
JBoyer |
Dyrcona: yes, to further drive home how badly I delivered a throwaway joke. :) |
| 15:38 |
Dyrcona |
haha! |
| 15:39 |
JBoyer |
I don't remember them all, no, but I do read them all and might have taken note of my bug being squashed. |
| 15:41 |
kmlussier |
It might help if I clear my cache. |
| 15:42 |
Dyrcona |
I think that's my problem. I cleared my cache and I can't find anything. |
| 15:43 |
kmlussier |
hmmmm |
| 15:54 |
kmlussier |
Found it! |
| 15:54 |
kmlussier |
bug 1712646 doesn't play nicely with JBoyer's patch. It's broken on two of my VMs now. |
| 15:55 |
pinesol_green |
Launchpad bug 1712646 in Evergreen "Web Client: Adding bill without billing type fails silently" [Low,Confirmed] https://launchpad.net/bugs/1712646 |
| 15:55 |
kmlussier |
But I don't know why. |
| 16:05 |
JBoyer |
I know why: return parseInt(val, 10); |
| 16:05 |
kmlussier |
Yay! |
| 16:06 |
JBoyer |
defining a stringToNumber directive as part of the ui service apparently overrides mine. But, since parseFloat doesn't force decimal places, it could likely be used. |
| 16:07 |
JBoyer |
If there needs to be control over teh presence or number of decimal places, that directive will need some more attention. |
| 16:08 |
JBoyer |
Using parseInt vs. parseFloat depending on whether you want decimals is fine, for instance, but when you care about the number of decimals something fancier is required than what I come up with initially. |
| 16:09 |
JBoyer |
Or, we come up with stringToInt and stringToFloat and use them accordingly. |
| 16:12 |
Dyrcona |
I think the latter would be better. |
| 16:12 |
Dyrcona |
stringToNumber is a bit vague. |
| 16:13 |
Dyrcona |
stringToInteger and stringToDecimal |
| 16:13 |
Dyrcona |
That's my suggestion if you're looking for any. If not, then don't mind me. |
| 16:18 |
JBoyer |
Probably won't make it into 3.0 but I think I'm going to try to move things that way before 3.0.1 or so. |
| 16:26 |
* Dyrcona |
belatedly declares it to be Naitonal Typo Day. ;) |
| 16:33 |
kmlussier |
Dyrcona: You're nine days early. https://whatnationaldayisit.com/day/typo/ |
| 16:36 |
kmlussier |
JBoyer: So is cesardv's code okay to go in as is or does the adjustment need to be made in his branch? |
| 16:41 |
|
jvwoolf left #evergreen |
| 16:46 |
JBoyer |
His branch either needs to change the directive name, switch over to the parseFloat function, or move that directive into the app controller that it's used in. (billing?) Not having looked into it more specifically I can't say which is the most appropriate change. |
| 16:47 |
JBoyer |
If he wants to make the move to having both stringToInt and stringToFloat in services/ui.js that's great, but that's the most work as it would involve changing his branch and mine. |
| 16:47 |
JBoyer |
(That might be a better 3.0.1 change) |
| 16:48 |
Dyrcona |
Do it right, now, or pay for it later. |
| 16:48 |
Dyrcona |
Again, just a suggestion... :) |
| 17:00 |
miker |
parseFloat+printf (yes, we have a printf implementation stashed away somewhere in the code base) |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
|
mmorgan left #evergreen |
| 17:22 |
|
acautley joined #evergreen |
| 17:36 |
|
tlittle joined #evergreen |
| 17:42 |
pinesol_green |
[evergreen|Galen Charlton] LP#1708951: fix tabbing in webstaff catalog app for Firefox - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c43bc5b> |
| 18:00 |
|
kmlussier joined #evergreen |
| 19:17 |
|
Jillianne joined #evergreen |
| 20:29 |
|
tsbere joined #evergreen |
| 21:48 |
|
tlittle left #evergreen |
