| Time |
Nick |
Message |
| 02:27 |
|
gsams__ joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:39 |
|
rlefaive joined #evergreen |
| 07:43 |
|
collum joined #evergreen |
| 08:03 |
|
krvmga joined #evergreen |
| 08:04 |
krvmga |
we're getting a 500 error when a certain patron tries to display her holds history. in the database, she has 799. does anyone know if there's a limit to the number of items in a holds history? |
| 08:05 |
|
JBoyer joined #evergreen |
| 08:24 |
csharp |
krvmga: yeah - there's a bug on that that I can't find at the moment - there's not a known number of items that triggers the problem, but I wouldn't expect a list that long to work |
| 08:25 |
csharp |
krvmga: we just create report templates so staff can provide those by request - not ideal, obviously, since privacy is involved :-/ |
| 08:25 |
csharp |
actually, no we don't - those aren't exposed to the reporter |
| 08:25 |
krvmga |
csharp++ |
| 08:26 |
csharp |
but I've created custom SQL to get them as needed |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:59 |
|
Dyrcona joined #evergreen |
| 09:00 |
|
mllewellyn joined #evergreen |
| 09:01 |
Dyrcona |
Related to the prior discussion this morning: I don't understand saving holds history as much as circulation history, but whatever. :) |
| 09:07 |
|
jvwoolf joined #evergreen |
| 09:09 |
|
kmlussier joined #evergreen |
| 09:11 |
kmlussier |
Dyrcona: Maybe a situation where a patron remembers placing a hold, it never arrives, and they want to check the history to see what happened to it? |
| 09:12 |
Dyrcona |
I'm not judging, just sayin' I'd keep my circ history but probably not my hold history. |
| 09:12 |
Dyrcona |
So, it seems that 799 is too much for our current hardware. :) |
| 09:23 |
|
yboston joined #evergreen |
| 09:44 |
|
lsach joined #evergreen |
| 10:03 |
|
mmorgan1 joined #evergreen |
| 10:12 |
|
Christineb joined #evergreen |
| 10:18 |
Dyrcona |
Don't you love it when the man page says: cURL can do SFTP, but it doesn't when you use packages or the typical installation procedure? |
| 10:18 |
Dyrcona |
You want SFTP in cURL, you typically have to install it from source. |
| 10:34 |
jeff |
I tend to use sftp for sftp. |
| 10:37 |
Dyrcona |
jeff: I do, too, but thought I'd automate it wit cURL this time. |
| 10:38 |
Dyrcona |
Since it worked so well for regular FTP. |
| 10:41 |
|
mmorgan joined #evergreen |
| 10:44 |
|
jvwoolf joined #evergreen |
| 11:00 |
|
bdljohn joined #evergreen |
| 11:25 |
jeff |
I think I usually use sftp for automating sftp, and lftp for automating ftp. |
| 11:27 |
Dyrcona |
I've been using curl for a while for ftp. |
| 11:29 |
Dyrcona |
How do you deal with the password with sftp? |
| 11:31 |
|
cesardv_ joined #evergreen |
| 11:34 |
|
cesardv_ joined #evergreen |
| 11:45 |
jeff |
Dyrcona: by not using passwords. key auth only. |
| 11:46 |
Dyrcona |
jeff: I thought that would be the answer. I don't control the destination server and probably can't upload a key. |
| 11:46 |
|
yboston joined #evergreen |
| 11:47 |
|
jihpringle joined #evergreen |
| 11:47 |
Dyrcona |
Anyway, I probably won't be regularly uploading to this server, anyway. |
| 11:47 |
Dyrcona |
Anyway... :) |
| 12:12 |
|
khuckins joined #evergreen |
| 12:25 |
|
yboston joined #evergreen |
| 12:37 |
|
rlefaive joined #evergreen |
| 12:56 |
|
khuckins_ joined #evergreen |
| 13:04 |
Dyrcona |
kmlussier++ # For explaining how to reproduce a bug when the OP didn't. |
| 13:09 |
Dyrcona |
@karma |
| 13:09 |
pinesol_green |
Dyrcona: Highest karma: "csharp" (6), "gsams" (6), "bshum" (3), "evergreen" (2), and "phasefx" (2). Lowest karma: "comcast" (-9), "launchpad" (-1), "old_dojo" (-1), "meetings" (-1), and "miker" (1). You (Dyrcona) are ranked 7 out of 21. |
| 13:19 |
JBoyer |
@karma |
| 13:19 |
pinesol_green |
JBoyer: Highest karma: "csharp" (6), "gsams" (6), "bshum" (3), "evergreen" (2), and "phasefx" (2). Lowest karma: "comcast" (-9), "launchpad" (-1), "old_dojo" (-1), "meetings" (-1), and "miker" (1). You (JBoyer) are ranked 7 out of 21. |
| 13:19 |
JBoyer |
karma |
| 13:19 |
JBoyer |
karma |
| 13:19 |
JBoyer |
chameleon |
| 13:20 |
mmorgan |
Oh no! Earworm! |
| 13:27 |
csharp |
boy_george++ |
| 13:27 |
|
cesardv__ joined #evergreen |
| 13:52 |
|
khuckins__ joined #evergreen |
| 14:20 |
miker |
glanced over, misread "by_george++" and thought, yes, that's a phrase I would also inc |
| 14:27 |
jeffdavis |
miker: I'm looking at bug 1770478. We have some libraries missing from the offline working location dropdown, but not all of them have org id < parent id. |
| 14:28 |
pinesol_green |
Launchpad bug 1770478 in Evergreen "Web Client: Offline Issue Affects System where child orgs have lower ID number than parent" [High,Confirmed] https://launchpad.net/bugs/1770478 |
| 14:28 |
jeffdavis |
And some are present in the dropdown even though org id > parent id. |
| 14:29 |
miker |
jeffdavis: can you recreate the issue on a local workstation? |
| 14:31 |
jeffdavis |
Sorry, recreate which aspect exactly? |
| 14:34 |
miker |
I mean, does that happen everywhere, or just on some workstations that attempt to use offline? |
| 14:35 |
miker |
IOW, could it be bad IndexedDB data in some browser instances? |
| 14:38 |
jeffdavis |
Myself and at least two other folks here are seeing it on separate workstations (all using Chrome on Windows or Ubuntu, connecting to the same test server). Clearing cache and local data doesn't help, the same org units are consistently missing from that one dropdown. |
| 14:41 |
jeffdavis |
I added some console logging to the reconstituteTree function in lovefield.js. Seems like the missing org units are in the list when it is initially retrieved by getListFromOfflineCache, but they are missing after the list is processed. |
| 14:41 |
jeffdavis |
I'll share a patch to show what I mean, one sec |
| 14:45 |
pastebot |
"jeffdavis" at 64.57.241.14 pasted "lovefield.js reconstituteTree logging" (22 lines) at http://paste.evergreen-ils.org/4436 |
| 14:50 |
jeffdavis |
the first log entry there, "log: %o", shows missing org units which do not appear in the second log entry, "tree: %o" |
| 15:03 |
|
abowling joined #evergreen |
| 15:22 |
|
kmlussier joined #evergreen |
| 15:24 |
* Dyrcona |
fixes a long-standing issue in our local schema. |
| 15:25 |
Dyrcona |
For some reason, our actor.usr fkeys on mailing and billing address were not deferred/deferrable, so the stock purge data function wouldn't work. |
| 15:33 |
miker |
jeffdavis: yep, that's the code I've been staring at, and can't figure out why some orgs lose their kids. the order just shouldn't matter, because we build a "parent->[kids] map inside the hash var, and go out of our way to access hash via string-ish keys |
| 15:47 |
pastebot |
"jeffdavis" at 64.57.241.14 pasted "LP#1770478 console logging 2" (20 lines) at http://paste.evergreen-ils.org/4445 |
| 15:48 |
jeffdavis |
miker: ^ that might narrow it down - the root org unit contains all org units in the first log line, but in the second log line, some children are missing from the root org unit |
| 15:49 |
jeffdavis |
the second log line does contain the missing org units as individual later elements in the array but the dropdown appears to be built from whichever is the root org, the rest of the array is ignored |
| 15:49 |
jeffdavis |
(if I understand correctly) |
| 15:51 |
|
rlefaive joined #evergreen |
| 15:52 |
jeffdavis |
in other words, the map function at the end of getListFromOfflineCache appears to be where the children disappear |
| 16:01 |
Dyrcona |
Oh, nice. I can't get the staff client to load at all in Firefox 60. |
| 16:03 |
Dyrcona |
If I go to the normal login screen, nothing happens. |
| 16:03 |
Dyrcona |
If I try the hostname with the 7682 port, I'm told 404 Not Found.... |
| 16:08 |
JBoyer |
And Chrome logs in as usual, or you're still looking into issues? Because if FF 60 is the cutoff for those of us not yet using a frontend proxy, uh... |
| 16:11 |
Dyrcona |
JBoyer: what does "FF 60 is the cutoff for those of us not yet using a frontend proxy" mean? |
| 16:12 |
Dyrcona |
Yes, I'm looking. Yes, Chromium just works. And, what I get in the console is a LOGIN_FAILED, which shouldn't be since I'm copying and pasting the password. |
| 16:13 |
JBoyer |
I was basically asking if you're finding that somethings up with your installation (not looking likely) or if Firefox just doesn't like speaking https to that port (which would force any of us that aren't using something like nginix to start) |
| 16:14 |
Dyrcona |
Well, my password has lots of punctuation and was recently changed, so FF may not be handling it correctly, but I have no idea really. |
| 16:16 |
JBoyer |
I think the FF Quantum install I was using for Hatch was basically 62 or higher, so hopefully it's something like that. (though restrictions on password characters is not great either.) |
| 16:16 |
JBoyer |
that is to say, I was able to login fine with that dev edition of FF. |
| 16:16 |
Dyrcona |
Well, my thought was there's a bug where it isn't properly entityizing. |
| 16:22 |
Dyrcona |
It's not a certificate issue. I'm using our domain's wildcard cert, and I have dnsmasq set up so this domain looks legit to my laptop. |
| 16:33 |
Dyrcona |
Could be that this db has the actor.usr table locked. |
| 16:36 |
|
yboston joined #evergreen |
| 16:36 |
* Dyrcona |
sees 742 locks, but didnt join enough to see what, exactly, was locked. |
| 16:37 |
Dyrcona |
OK, false alarm. Chromium isn't logging in right now, either. :P |
| 16:42 |
Dyrcona |
Must be the update going on. |
| 16:43 |
Dyrcona |
And, time to go. |
| 16:43 |
Dyrcona |
Catch you all later! |
| 17:01 |
pinesol_green |
[evergreen|Katie G. Martin] Docs: Updated Long Overdue items section for web client - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8ff2e09> |
| 17:02 |
|
mmorgan left #evergreen |
| 17:02 |
|
jvwoolf left #evergreen |
| 17:18 |
miker |
jeffdavis: sorry, was AFK. the /intent/ is to rebuild the tree in-memory. we find the top org for later, and then look at each in turn to populate the children() slot via filter. in the end, the top variable should contain the only org without a parent_ou, and the children() of each should be an array of pointers to the objects that belong to it, using Array.prototype.filter() over the full list. we clear out children[] in the second loop, which |
| 17:18 |
miker |
should be perfectly safe because we only look at each item in list once there, including top |
| 17:19 |
miker |
it's acting like either "hash" isn't full of what we expect, or the body of the filter() function is wrong in some way |
| 17:45 |
Bmagic |
It's probably to late in the day but I'll ask anyway. I see that the view acq.fund_spent_total needs the fund_debit.encumbrance to be false in order to count towards total spent. I am looking a several rows in fund_debit that have invoice_entry and amounts but encumbrance= true |
| 17:45 |
Bmagic |
What is it that changes that boolean to false? |
| 17:47 |
berick |
Bmagic: closing (completing) the invoice moves the fund debits from encumbrance to paid |
| 17:47 |
Bmagic |
sub handle_invoice_state_change { |
| 17:49 |
Bmagic |
I see, ok. So how do I complete an invoice? From the PO interface, I can see "view invoices" and that pops a new tab with hardcoded search critera to the linitem id but the results are not clickable |
| 17:49 |
Bmagic |
I suppose I need to click on "View Invoices" at the top of the interface |
| 17:51 |
Bmagic |
berick++ |
| 18:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:43 |
|
abowling left #evergreen |
| 19:50 |
|
rlefaive joined #evergreen |
| 20:41 |
jeffdavis |
I almost understand the issue with bug 1770478 but trying to put it into words is not easy |
| 20:41 |
pinesol_green |
Launchpad bug 1770478 in Evergreen "Web Client: Offline Issue Affects System where child orgs have lower ID number than parent" [High,Confirmed] https://launchpad.net/bugs/1770478 |
| 20:41 |
jeffdavis |
the filter() call is indeed the source of our problem |
| 20:41 |
jeffdavis |
we iterate through the list of org units; for each entry in the list we call filter() on the full list |
| 20:42 |
jeffdavis |
filter() in turn iterates through the full list in order |
| 20:43 |
jeffdavis |
let's say item.id = 20 |
| 20:44 |
jeffdavis |
as filter() works through the list, it does this test on each org unit: kid[parent_field]() == item[pkey]() |
| 20:44 |
jeffdavis |
for org units where id < 20, that test will always return false |
| 20:45 |
jeffdavis |
because, roughly speaking, kid[parent_field]() is a function and item[pkey]() is not |
| 20:46 |
jeffdavis |
but where id >=20, kid[parent_field]() is an actual value rather than a function, so it will return the correct value (true if the parent_ou is 20, false otherwise) |
| 20:48 |
pastebot |
"jeffdavis" at 64.57.241.14 pasted "LP#1770478 console logging 3 - filter check" (13 lines) at http://paste.evergreen-ils.org/4478 |
| 20:49 |
pastebot |
"jeffdavis" at 64.57.241.14 pasted "LP#1770478 console logging 3 - filter check (output)" (8 lines) at http://paste.evergreen-ils.org/4479 |
| 20:50 |
jeffdavis |
I'm sure I'm not explaining the test failure quite right but the above console log output hopefully shows what I mean |
| 20:51 |
jeffdavis |
the extra catch is that the org unit list is string-sorted, not numeric-sorted |
| 20:52 |
jeffdavis |
so it would be more accurate to say that the filter test always returns false if id::text < '20'::text (199 is always false, 3 is the correct value depending on its parent_ou) |
| 20:54 |
jeffdavis |
anyway, that's the best I can do for today |
| 20:54 |
jeffdavis |
@monologue |
| 20:54 |
pinesol_green |
jeffdavis: Your current monologue is at least 5 lines long. |
| 20:54 |
* jeffdavis |
shakes fist at pastebot |
| 21:45 |
|
beanjammin joined #evergreen |
| 22:05 |
|
beanjammin joined #evergreen |
| 22:21 |
|
gsams joined #evergreen |
| 23:24 |
Bmagic |
jeffdavis++ |
