| Time |
Nick |
Message |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 04:34 |
|
abowling1 joined #evergreen |
| 05:31 |
|
jeff___ joined #evergreen |
| 05:31 |
|
dbs joined #evergreen |
| 05:31 |
|
bwicksall joined #evergreen |
| 05:33 |
|
jvwoolf joined #evergreen |
| 05:33 |
|
b_bonner joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:31 |
|
agoben joined #evergreen |
| 08:10 |
|
collum joined #evergreen |
| 08:46 |
|
bos20k joined #evergreen |
| 08:47 |
|
Dyrcona joined #evergreen |
| 08:54 |
|
mmorgan joined #evergreen |
| 09:00 |
|
_adb joined #evergreen |
| 09:03 |
* csharp |
tries to remember how to activate non-en-US locales :-/ |
| 09:06 |
Dyrcona |
I think they set the locale on the server using the environment variables and configuration files. |
| 09:07 |
Dyrcona |
man locale(1) locale(5) locale(7) |
| 09:08 |
Dyrcona |
I typically set mine to en-US.UTF8 |
| 09:21 |
bos20k |
Debian has a nice text interface that lets you change it when you do 'dpkg-reconfigure locales'. The same command in Ubuntu seems to just regenerate locale files. |
| 09:22 |
Dyrcona |
Yeap. You can also set it per user, which is what I typically do. |
| 09:23 |
* Dyrcona |
waits for gitlab-ce to update. |
| 09:23 |
bos20k |
Yeah, if you're testing something you might want to try setting environment variables. The locale files for the particular locale would need to exist on the system I would think though. |
| 09:24 |
Dyrcona |
yeah, that goes without saying. |
| 09:24 |
* Dyrcona |
considers setting his environment to Esperanto when going through customs. :) |
| 09:33 |
|
jvwoolf joined #evergreen |
| 09:34 |
csharp |
so our 2.12.2 testers are getting a perm error for UPDATE_MARC when clicking "Basic Search" (which, incidentally, goes to Advanced Search) |
| 09:34 |
|
terran joined #evergreen |
| 09:34 |
|
kmlussier joined #evergreen |
| 09:35 |
Dyrcona |
csharp: That rings a bell. I think there was a Lp bug. |
| 09:35 |
kmlussier |
csharp: I think that bug has been fixed |
| 09:35 |
csharp |
oh - awesome |
| 09:35 |
kmlussier |
bug 1693560 |
| 09:35 |
pinesol_green |
Launchpad bug 1693560 in Evergreen "UPDATE_MARC Permission Error in Search Catalog" [High,Fix released] https://launchpad.net/bugs/1693560 |
| 09:36 |
csharp |
kmlussier: rock on |
| 09:36 |
csharp |
@praise kmlussier for her LP skills |
| 09:36 |
* pinesol_green |
You don't want to get mixed up with someone like kmlussier. kmlussier is a loner, Dottie. A rebel. for her LP skills |
| 09:36 |
kmlussier |
:) |
| 09:37 |
mmorgan |
kmlussier++ |
| 09:37 |
csharp |
kmlussier: heh - your solution was going to be my next step to test |
| 09:37 |
mmorgan |
pinesol_green is in a bad mood this morning. |
| 09:37 |
pinesol_green |
mmorgan: Leave me alone, I'm busy right now. |
| 09:37 |
mmorgan |
see? |
| 09:37 |
Dyrcona |
:) |
| 09:38 |
* gmcharlt |
gives pinesol_green a cookie |
| 09:38 |
csharp |
pinesol_green: insult yourself |
| 09:38 |
pinesol_green |
yourself: You are nothing but a swag-bellied tongueful of goatish yoo-hoo. |
| 09:38 |
gmcharlt |
IT WAS NOT A GOATISH YOO-HOO COOKIE!!!1! |
| 09:39 |
csharp |
@band add Ah Well, Nevermind |
| 09:39 |
pinesol_green |
csharp: Band 'Ah Well, Nevermind' added to list |
| 09:40 |
Dyrcona |
@band add Goatish Yoo-hoo |
| 09:40 |
pinesol_green |
Dyrcona: Band 'Goatish Yoo-hoo' added to list |
| 09:40 |
Dyrcona |
@praise [band] |
| 09:40 |
* pinesol_green |
the upgrade came off brilliantly, and it's all because of National Donut Day |
| 09:40 |
csharp |
Dyrcona++ |
| 09:42 |
pinesol_green |
[evergreen|Cesar Velez] LP#1098685: Require OPAC patron holds w/ phone/SMS notification to enter that info - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2621af6> |
| 09:44 |
kmlussier |
Upgrades should always be performed on National Donut Day. |
| 09:45 |
Dyrcona |
True dat! |
| 09:46 |
csharp |
@praise [band] for [quote random] |
| 09:46 |
* pinesol_green |
Fit Fetch goes to eleven for Quote #103: "* mrpeters is now known as whatismyname" (added by gmcharlt at 03:08 PM, December 23, 2014) |
| 09:54 |
Dyrcona |
git tells me that tonight incremental backup is going to be larger than usual: Auto packing the repository in background for optimum performance. |
| 09:56 |
Dyrcona |
@dunno |
| 09:56 |
pinesol_green |
Dyrcona: Have you confirmed your ISBN SPIDs with your service provider? |
| 10:12 |
terran |
Bmagic++ for work on bug 1655158 - our staff have wanted this for years! |
| 10:12 |
pinesol_green |
Launchpad bug 1655158 in Evergreen "Patron Search by date of birth" [Wishlist,Confirmed] https://launchpad.net/bugs/1655158 |
| 10:13 |
remingtron |
Dyrcona: a SIP testing tool tells me my server "actively refused" the connection. I think I have opened port 6001 already. Advice? |
| 10:15 |
Dyrcona |
remingtron: Can you connect from the localhost? I'd try with both the name and 127.0.0.1 as well as ::1 if IP6 is configured. |
| 10:15 |
remingtron |
thanks, I'll give that a try |
| 10:15 |
Bmagic |
terran++ for checking it out |
| 10:15 |
Dyrcona |
I'd check for intervening firewalls, too. |
| 10:24 |
remingtron |
I'm able to telnet in on localhost, but when I send a login message (9300CN...), I get this error |
| 10:24 |
remingtron |
raw_transport: login error (timeout? ), exiting at SIPServer.pm line 590. |
| 10:24 |
remingtron |
Dyrcona: ---^ |
| 10:26 |
Dyrcona |
remingtron: I've never seen that, though I know others have, but I don't know what was done to resolve it. |
| 10:27 |
remingtron |
okay, I'll do some research. thanks. |
| 10:32 |
Dyrcona |
It maybe something in the client expecting a banner or something like that. |
| 10:32 |
Dyrcona |
Nah, probably not. |
| 10:39 |
remingtron |
Dyrcona: would you believe it? osrfsys.log just showed "Login failed" |
| 10:39 |
Dyrcona |
remingtron: Yes, i would. You created the accounts in Evergreen, yes? |
| 10:40 |
remingtron |
Yes. I edited the SIP user in the staff client again, said my org unit of CONS was invalid, changed to BR1, resaved the password just in case, and now it works. |
| 10:40 |
Dyrcona |
That'll do it. |
| 10:40 |
Dyrcona |
Glad you figured it out. |
| 10:40 |
remingtron |
so possibly the password was wrong, or the org unit. |
| 10:40 |
remingtron |
thanks for your thoughts along the way! |
| 10:41 |
Dyrcona |
remingtron: Probably the org. unit, I believe it needs to be able to have patrons for login to succeed. |
| 10:41 |
Dyrcona |
I could be wrong. |
| 10:41 |
remingtron |
I'd believe that |
| 10:42 |
Dyrcona |
password mismatch between the db and config file is also very easy to do. |
| 11:08 |
remingtron |
Dyrcona: FYI I also have to change "127.0.0.1:6001/tcp" to just "6001/tcp" in the SIP config, otherwise it was only listening on localhost |
| 11:09 |
Dyrcona |
remingtron: Yes, I've noticed that before, but it's pretty typical with servers. |
| 11:11 |
remingtron |
I feel like a young padawan |
| 11:13 |
Dyrcona |
Well, it should probably be documented somewhere, but SIPServer is pretty low on documentation. |
| 11:16 |
|
yboston joined #evergreen |
| 11:18 |
terran |
Can someone point me to where the code lives to process the webby print templates? I found the templates themselves but I' |
| 11:19 |
terran |
oops - I'm trying to figure out how to get the courier code to put on transit slips... 1708485 |
| 11:19 |
terran |
Or bug 1708485 even |
| 11:19 |
pinesol_green |
Launchpad bug 1708485 in Evergreen "Web Staff Client: Missing courier code on transit slip print templates" [Undecided,New] https://launchpad.net/bugs/1708485 |
| 11:34 |
|
DPearl joined #evergreen |
| 11:38 |
JBoyer |
terran, I'm assuming courier_code is a field on actor.org_unit, but is in defined in the IDL where you're testing? It also looks to me like it will have to be accessed as 'dest_location.courier_code' or similar. (I haven't looked at web client printing that much yet, but I think should work) |
| 11:38 |
csharp |
shortname is the same thing |
| 11:38 |
csharp |
wait - no it's not |
| 11:38 |
csharp |
@blame csharp |
| 11:38 |
pinesol_green |
csharp: csharp was monkeying around too much on the prod servers! |
| 11:39 |
csharp |
that's actually true |
| 11:39 |
tsbere |
Courier code is an org unit setting |
| 11:39 |
tsbere |
Not an org unit value |
| 11:39 |
tsbere |
(and thus can be inherited from higher org units, if set there) |
| 11:39 |
csharp |
tsbere: right |
| 11:39 |
csharp |
just remembered that |
| 11:40 |
JBoyer |
Oh, so rather different then. Then I have run out of ideas at this point. :) |
| 11:40 |
terran |
Heh, yeah, already tried that too |
| 11:43 |
tsbere |
One fun thought: Are the permissions on the org unit setting type correct for the method being used to read it? |
| 11:43 |
tsbere |
(assuming a method is being used and failing) |
| 12:01 |
csharp |
yeah, bug 1708485 is definitely a PINES showstopper |
| 12:01 |
pinesol_green |
Launchpad bug 1708485 in Evergreen "Web Staff Client: Missing courier code on transit slip print templates" [High,New] https://launchpad.net/bugs/1708485 |
| 12:01 |
csharp |
even for 2.12 |
| 12:03 |
* csharp |
tried to untangle the js, got hung up on what "evt" and "data" are/contain |
| 12:03 |
csharp |
but that's lack of JS-fu |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:04 |
* csharp |
is probably one of the few programmer-ish people out there who understands perl better than javascript |
| 12:11 |
|
khuckins joined #evergreen |
| 12:17 |
terran |
If you put {{transit}} in the print template it'll spit out all of the transit-related data that you can use, but the courier code isn't included. Back tracking through circ.js to try to see where that data comes from. |
| 12:21 |
terran |
Aaaaand, I've reached my limits |
| 12:21 |
|
rlefaive_ joined #evergreen |
| 12:21 |
berick |
terran: is courier code an org unit setting? |
| 12:22 |
mmorgan |
terran: Looks like the xul client gets it here: http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/xul/staff_client/server/circ/util.js#l3384 |
| 12:23 |
mmorgan |
berick: it is an ou setting |
| 12:24 |
berick |
i would start w/ confirming the ou setting is loaded by the webstaff |
| 12:25 |
berick |
by grep'ing for the setting name in the js |
| 12:29 |
csharp |
lib.courier_code is the setting name, and it is not in there |
| 12:29 |
csharp |
used 'ack' from Open-ILS/web/js/ui/default |
| 12:32 |
csharp |
berick: should I be looking at egCore.org.settings in staff/circ/services/circ.js? |
| 12:32 |
berick |
suggest adding it to the list of org settings fetched in circ/services/circ.js (near the top) then adding the value to the print context near the top of route_dialog |
| 12:32 |
berick |
csharp: yes :) |
| 12:32 |
csharp |
great |
| 12:33 |
berick |
well wait the courier code has to be fetched per org unit, though, right? |
| 12:34 |
terran |
Yes |
| 12:34 |
berick |
so change that, csharp. it will have to be fetched on-demand in service.route_dialog |
| 12:35 |
berick |
depending on the destination branch |
| 12:35 |
berick |
data.transit.dest() |
| 12:36 |
berick |
and that will have to be promise/async call that happens (and concludes) before print_transit is called |
| 12:37 |
berick |
so really it needs to live in collect_route_data(), added to the list of promises in there |
| 12:40 |
terran |
berick++ |
| 12:46 |
csharp |
hmm - I'm not seeing another example of how a setting gets checked/retrieved, so I'm at a loss as to how this should be coded :-/ |
| 12:48 |
csharp |
I'm assuming it's something like "if there's an org, and the setting is not null, get the value of the setting and push it into promises", but I don't know how to say that in Angular/JS |
| 12:49 |
JBoyer |
csharp, staff/circ/patron/app.js uses the egCore.org.settings call to load some OUS, it would be set up in a similar way. |
| 12:49 |
csharp |
JBoyer: thanks - I'll take a look |
| 12:49 |
jeffdavis |
I also see examples like egCore.env.aous['some-setting'] |
| 12:51 |
berick |
csharp: untested but something along the lines of https://gist.github.com/berick/293da412cca677791b6e7709557137b1 |
| 12:51 |
JBoyer |
jeffdavis, I believe egCore.env is more local (like a cache) but I haven't explored that much. |
| 12:58 |
csharp |
berick: does your patch presume that lib.courier_code is added to the settings at the top? or does it stand on its own? |
| 12:59 |
|
collum joined #evergreen |
| 12:59 |
* csharp |
assumes so, but thought he should ask |
| 13:00 |
berick |
csharp: stands on its own. it fetches the org setting per transit destination at run time |
| 13:00 |
csharp |
great :-) |
| 13:03 |
berick |
csharp: oh and you'll need to add inside route_dialog(): print_context.dest_courier_code = data.dest_courier_code; |
| 13:03 |
berick |
along with the other if (data.transit) stuff |
| 13:05 |
csharp |
gotcha |
| 13:22 |
csharp |
berick: we're not seeing any data come through - we're wondering about data.dest_courier_code = s['lib.courier_code']; and where "s" is defined/what is is |
| 13:23 |
Dyrcona |
csharp: is lib.courier_code pulled into s[]? |
| 13:24 |
csharp |
I don't see any references to s[] anywhere else in the file |
| 13:25 |
Dyrcona |
probably filled in elsewhere through the magic of .... magic. :) |
| 13:25 |
JBoyer |
It's from line 19 of berick's gist. |
| 13:26 |
csharp |
duh - we see it now :-) |
| 13:26 |
csharp |
JBoyer: thanks |
| 13:26 |
|
jvwoolf joined #evergreen |
| 13:26 |
Dyrcona |
csharp: NP. It's one of those days for me, too. :) |
| 13:26 |
JBoyer |
The way then() works is that you give it a function to call and it will pass the results of the previous function to it. The fact that these are usually anonymous functions makes it a real mess unless your editor highlights matching braces. |
| 13:28 |
csharp |
when we change s['lib.courier_code'] to "FRANK", "FRANK" appears on the receipt, so we know we're close |
| 13:36 |
JBoyer |
It looks like I need to hit some JS docs pretty hard re: promises. I can basically follow the flow, but when and why to use things like when(), defer(), and so on are a mystery. I managed to get stuck in a similar place messing with user settings for bug 1691269 |
| 13:36 |
pinesol_green |
Launchpad bug 1691269 in Evergreen "web client: copy templates created on XUL not displayed" [Undecided,New] https://launchpad.net/bugs/1691269 |
| 13:38 |
csharp |
in the line // egCore.org.settings('lib.courier_code', trans.dest()) |
| 13:39 |
csharp |
(without the //), trans.dest() is not resulting in a value |
| 13:39 |
csharp |
when we put in a known lib ID, it prints the courier code correctly |
| 13:43 |
tsbere |
That sounds like trans isn't being filled in properly, at least to me. With almost no actual looking at it. |
| 13:44 |
tsbere |
csharp: berick mentioned data.transit.dest() earlier, should that be swapped in instead of trans.dest()? |
| 13:48 |
csharp |
nope :-( |
| 13:52 |
* Dyrcona |
smacks his forehead. |
| 13:52 |
Dyrcona |
I totally misinterpreted my "should never happen" problem. |
| 13:52 |
JBoyer |
\me hears the sound of one head clapping |
| 13:52 |
JBoyer |
Bah. |
| 13:52 |
Dyrcona |
This is a case of a json query fails but we immediately do ->[0].... |
| 13:53 |
tsbere |
That sounds less impossible. |
| 13:53 |
csharp |
@quote add < JBoyer> \me hears the sound of one head clapping |
| 13:53 |
pinesol_green |
csharp: The operation succeeded. Quote #171 added. |
| 13:57 |
Dyrcona |
At one point, I wanted to fix all of those, saw how many there were, and decided to forget about it. |
| 14:01 |
csharp |
we're walking away from it for now - back to it later/tomorrow |
| 14:01 |
terran |
it's very close |
| 14:05 |
berick |
Dyrcona: I always do json_qery->[0] because if the json_query explodes from a bad query it's a problem that has to be fixed regardless. |
| 14:05 |
berick |
may as well die loudly |
| 14:06 |
berick |
hm, wonder how trans.dest() doesn't have a value. |
| 14:07 |
Dyrcona |
berick: I find most of the time, it's a db timeout and the user gets a network or server failure message. |
| 14:08 |
csharp |
berick: we walked through the code over and over and don't know :-/ |
| 14:08 |
berick |
csharp: maybe log js2JSON(trans) to see if it looks sane? |
| 14:10 |
berick |
transit_copy.dest is non-NULL field, if it's empty something is fishy |
| 14:12 |
berick |
Dyrcona: is there a scenario where that happens but the ML code should continue is if everything is OK? |
| 14:13 |
Dyrcona |
berick: No, but there are better failure modes than throw an unknown error in the user's face. |
| 14:14 |
berick |
oh, totally. no argument there. |
| 14:14 |
csharp |
berick: tried console.log(js2JSON(trans)); but nothing's showing when I check in |
| 14:15 |
csharp |
as in, the log message isn't coming through |
| 14:18 |
csharp |
ah - cache |
| 14:19 |
csharp |
berick: https://pastebin.com/dnzCTSUj |
| 14:20 |
berick |
oh it's fleshed |
| 14:21 |
berick |
so you'd need trans.dest().id() |
| 14:21 |
csharp |
ah - okay |
| 14:21 |
csharp |
we had that idea, but not the syntax :-) |
| 14:26 |
csharp |
berick: that works! |
| 14:26 |
berick |
woohoo |
| 14:26 |
csharp |
berick: do you want to put together a branch, or should I (you did 95% here, obvs) |
| 14:28 |
berick |
csharp: no, you go for it. |
| 14:28 |
csharp |
berick: will do |
| 14:30 |
Dyrcona |
berick: In this particular case, a record merge blows up because we end up with duplicate parts. It would be good to tell the user that, so they might be able to fix it. |
| 14:34 |
berick |
Dyrcona: +1 to context-sensitive error messages. i thought you were suggesting something else. |
| 14:34 |
csharp |
berick++ |
| 14:39 |
kmlussier |
berick++ |
| 14:40 |
berick |
csharp++ # it's fun making code you don't have to test :) |
| 14:53 |
|
Jillianne joined #evergreen |
| 15:07 |
|
Dyrcona joined #evergreen |
| 15:28 |
* Dyrcona |
decides to look at something for feedback fest.... |
| 15:33 |
gmcharlt |
Dyrcona++ |
| 15:34 |
Dyrcona |
Lp 1411422 since it bit us today. :) |
| 15:34 |
pinesol_green |
Launchpad bug 1411422 in Evergreen 2.12 "Copy details repeated in search results when item/volume moved with parts attached" [Medium,Confirmed] https://launchpad.net/bugs/1411422 |
| 15:34 |
Dyrcona |
Looks like it mainly needs a test and maybe a little additional code. |
| 15:36 |
miker |
grabbing 1051 for great justice |
| 15:38 |
pinesol_green |
[evergreen|Bill Erickson] LP#1695007 All-circulations slim DB VIEW - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4a24441> |
| 15:38 |
pinesol_green |
[evergreen|Bill Erickson] LP#1695007 Webstafff circ group summary display fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4105f8d> |
| 15:38 |
pinesol_green |
[evergreen|Mike Rylander] Stamping upgrade script for slim all-circs view - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fc2dcda> |
| 15:40 |
berick |
miker++ |
| 15:50 |
pinesol_green |
[evergreen|Jeff Davis] LP#1691563: Prevent "Use of freed value in iteration" error during adjust to zero - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d8eacd2> |
| 16:00 |
JBoyer |
FYI: I've added the info from agoben's Hack-a-way email to the wiki and put a barebones signup / schedule page up also. I was reminded today that the wiki was lacki in this regard. |
| 16:03 |
JBoyer |
Super condensed for IRC logs: November 7-9 2017 with an EOB day on Nov 6. Ft Benjamin Harrison St Park again, Harrison House is available for working after hours / playing Resistance, Unexploded Cow, Exploding Kittens, etc. |
| 16:03 |
JBoyer |
Further infos and links on the site: https://wiki.evergreen-ils.org/doku.php?id=hack-a-way-2017 |
| 16:03 |
berick |
JBoyer++ |
| 16:06 |
Dyrcona |
JBoyer++ agoben++ |
| 16:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:04 |
|
mmorgan left #evergreen |
| 17:08 |
kmlussier |
berick++ bug 1709476 |
| 17:08 |
pinesol_green |
Launchpad bug 1709476 in Evergreen "web client: item status recent circ history tab does not correctly display aged circulations" [Medium,Confirmed] https://launchpad.net/bugs/1709476 |
| 17:09 |
|
jvwoolf left #evergreen |
| 17:20 |
pinesol_green |
[evergreen|Bill Erickson] LP#1709476 Copy summary aged circ display repair - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=dcf52ca> |
| 17:55 |
csharp |
JBoyer++ agoben++ |
| 18:25 |
|
Jillianne joined #evergreen |
| 23:12 |
|
gmcharlt joined #evergreen |
