| Time |
Nick |
Message |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:20 |
|
rjackson_isl_hom joined #evergreen |
| 07:24 |
|
yar joined #evergreen |
| 07:34 |
|
yar joined #evergreen |
| 07:49 |
|
Dyrcona joined #evergreen |
| 08:23 |
|
rfrasur joined #evergreen |
| 08:26 |
|
collum joined #evergreen |
| 08:28 |
|
alynn26 joined #evergreen |
| 08:29 |
|
mmorgan joined #evergreen |
| 08:59 |
csharp |
miker++ # I missed your update to bug 1893463 - thanks for the catch |
| 08:59 |
pinesol |
Launchpad bug 1893463 in Evergreen "Interrupting and re-running recurring reports can cause duplicated schedule entries" [Medium,Incomplete] https://launchpad.net/bugs/1893463 |
| 09:01 |
|
Stompro joined #evergreen |
| 09:43 |
miker |
csharp: np, but I don't think it was included in .0 so we'll have to rework it to be a real upgrade script of its own |
| 09:45 |
csharp |
yeah |
| 09:51 |
JBoyer |
re: 3.6.0 it was not included, so it can be ready to go for 3.6.1 without having to worry about anything potentially pre-existing. |
| 09:52 |
gmcharlt |
yeah, only folks living on the bleeding edge would be affected if the upgrade script gets changed underneath |
| 09:52 |
JBoyer |
Also, csharp++ and miker++ for getting it in shape. |
| 09:54 |
miker |
oh, wait, the whole thing was not included? sorry, I thought csharp's last version /was/ included |
| 09:55 |
miker |
sorry for the confusion, then. in that case, no new upgrade script needed! |
| 10:28 |
csharp |
awesome |
| 10:38 |
|
mantis1 joined #evergreen |
| 11:02 |
|
jvwoolf joined #evergreen |
| 11:18 |
|
jihpringle joined #evergreen |
| 12:20 |
Dyrcona |
Following up on something JBoyer and I briefly discussed yesterday, the requests are happening again today, but there are no holds being placed nor renewals happening for that library, and it is currently closed. |
| 12:24 |
Dyrcona |
And, if I check the osrf logs, I don't see any requests for closed dates using this location's id, but it's there in the database queries. |
| 12:25 |
Dyrcona |
I wonder if it is the hold tageter? |
| 12:25 |
Dyrcona |
targeter, even. |
| 12:26 |
Dyrcona |
I see lines like this in the logs: 2020-10-20 12:23:43 bd2-bh5 open-ils.hold-targeter: [INFO:12368:HoldTargeter.pm:202:16031895032519351] closed org unit IDs: |
| 12:26 |
Dyrcona |
Note the absence of any actual ids. |
| 12:27 |
Dyrcona |
I also see lots of checks for closed date overlap, but none of them have this org unit's id in the request. |
| 12:35 |
csharp |
@band add Hold Targaryen |
| 12:35 |
pinesol |
csharp: Band 'Hold Targaryen' added to list |
| 12:38 |
Dyrcona |
I've dumped a related trace from the logs to see what it looks like, but it looks like someone placed a batch hold. Think I'll go for a walk for lunch and have a look after. |
| 13:36 |
Dyrcona |
Well, it doesn't look like the hold targeter is running these queries. It does do a search for closed dates, but nothing that uses a specific org_unit's id. |
| 13:42 |
Bmagic |
what does it mean when in this folder: Open-ILS/src/eg2/ and running "npm install" - getting " no such file or directory, open 'Open-ILS/src/eg2/node_modules/.staging/core-js-d0e02ba0/modules/web.url.js'" and final error "npm ERR! code ERR_INVALID_OPT_VALUE" |
| 13:43 |
Bmagic |
npm 6.12.0 |
| 13:46 |
Dyrcona |
Bmagic: 6.12.0? Are you sure? |
| 13:46 |
Bmagic |
that's what npm --version said |
| 13:47 |
Bmagic |
on this 16.04 LTS - it's a machine that's "been around awhile" so it wouldn't surprise me if it needs OS stuffs |
| 13:48 |
Dyrcona |
Uh-huh, but I have npm 5.6.0 on Ubuntu 18.04. |
| 13:48 |
Dyrcona |
Node version 8.11.4. |
| 13:48 |
Bmagic |
I'd say that's the problem... |
| 13:48 |
Bmagic |
node is 12.13.0 |
| 13:49 |
Dyrcona |
What Evergreen release? 12 is probably correct. |
| 13:49 |
Bmagic |
EG 3.5.1 |
| 13:49 |
Dyrcona |
Have you tried deleting node_modules and doing it all again? |
| 13:49 |
Bmagic |
I did delete the local node_modules but not the global ones |
| 13:50 |
Dyrcona |
Bmagic: Node 12.13.0 is correct for 3.5. |
| 13:51 |
Dyrcona |
Did you upgrade this from an earlier release? IF so, then you may have to delete the node installaton under /usr/local and install it again. |
| 13:51 |
Bmagic |
oh good, on the right track then. I'll try deleting the global node_modules from /usr/share/npm/ |
| 13:51 |
Bmagic |
yep, machine previously had older EG install |
| 13:51 |
Dyrcona |
Did you install node from an Ubuntu pacakge? |
| 13:51 |
Dyrcona |
package.... |
| 13:51 |
Bmagic |
node was installed via make in EG repo |
| 13:51 |
Dyrcona |
pancake.... |
| 13:51 |
Bmagic |
:) |
| 13:52 |
Dyrcona |
OK. That's how it should be. |
| 13:52 |
Dyrcona |
Yeah, I'd try cleaning that out and starting over with the -developer target. |
| 13:52 |
Bmagic |
Dyrcona++ # going for it |
| 13:53 |
Dyrcona |
Upgrades are fun! |
| 13:54 |
Bmagic |
and boom |
| 13:54 |
Bmagic |
ty |
| 13:58 |
Dyrcona |
I don't know what an Ubuntu Pancake is, but now, I want one. :) |
| 14:00 |
Dyrcona |
And, I'm not getting anywhere in my search for the mystery queries. |
| 14:01 |
Dyrcona |
It looks like something related to updating a hold is looking up closed dates based on the request_time of the hold, possibly. |
| 14:03 |
Dyrcona |
But, I don't find any code that explicitly does that in the Perl. |
| 14:16 |
Dyrcona |
Nope. Can't find anything that looks like it would be doing that. |
| 14:34 |
|
jvwoolf joined #evergreen |
| 14:37 |
Dyrcona |
This is a real mystery. I can't find the code that is the source of these queries. |
| 14:43 |
Bmagic |
hmmm |
| 14:45 |
csharp |
$logger->info("closed org unit IDs: @closed_orgs") |
| 14:46 |
csharp |
line 202 from the log message |
| 14:46 |
csharp |
HoldTargeter.pm - or are you seeing something else? |
| 15:00 |
Dyrcona |
I'm dozens of queries like this in the database: SELECT * FROM actor.org_unit_closed WHERE '2018-06-19T23:59:00-04:00' between close_start and close_end AND org_unit = '207' ORDER BY close_start ASC, close_end DESC LIMIT 1 |
| 15:00 |
Dyrcona |
I suppose I should look more closely in the storage publisher code. |
| 15:11 |
Dyrcona |
The date on those queries changes and when I search the logs for the dates, I either find something on a different brick head, that looks irrelevant, or I find nothing. |
| 15:22 |
Dyrcona |
I can find lots of these in the logs, open-ils.storage.actor.org_unit.closed_date.overlap, but none for org_unit 207. |
| 15:31 |
csharp |
this sounds familiar - I remember chasing my tail on a similar issue a couple of months ago |
| 15:31 |
csharp |
I don't remember how it was resolved |
| 15:31 |
mmorgan |
Could it be related to emergency closure processing? |
| 15:32 |
csharp |
that sounds right, based on my hazy memory of it |
| 15:32 |
csharp |
too bad I exorcise such things from my brain as soon as they're done and am bad at documentation |
| 15:33 |
csharp |
might be something in the helpdesk though |
| 15:39 |
mmorgan |
Dyrcona: The date 2018-06-19 is curious. |
| 15:40 |
Dyrcona |
mmorgan: It's just 1 example. The dates seem random, all in the past. |
| 15:43 |
Dyrcona |
I'm off the clock, now. I'll have another look tomorrow. Thanks for the suggestions, mmorgan and csharp! |
| 15:47 |
|
mantis1 left #evergreen |
| 16:02 |
|
Stompro joined #evergreen |
| 16:42 |
miker |
berick: in the tpac we leave the cover image aspect ratio alone by only pinning the max width of the image (using the width attr on the <img> tag) but in the angular catalog we use CSS to set max width /and/ height, and then also set the height to 100%. It looks like if we /only/ set the max-width we'd be able to retain the aspect ratio and scale the images automatically. are there reasons we should not do that? (NOTE: I have not looked at the |
| 16:42 |
miker |
BOOPAC, but I suspect it's working like the tpac) |
| 16:48 |
miker |
berick: I'm developing my theory that we don't want/need to pin height by unchecking those calculated css values in the dev tools ... of course, those might be magically calculated by Ang or BS, in which case maybe we can't do what I want. |
| 16:52 |
|
jihpringle joined #evergreen |
| 16:56 |
berick |
miker: agreed we should only pin one, height or width. i guess whichever results in the most consistent display, i.e. vertical shuffling vs. horizontal shuffling |
| 16:57 |
berick |
if fixed width works well in tpac, then i'm sure that's fine |
| 17:00 |
mmorgan |
+1 to fixed width |
| 17:02 |
Stompro |
Has anyone worked on a curbside reminder notice yet? I'm thinking it could be close to the confirmation notice, just filtered/delayed on the slot timestamp? But rescheduled pickups might be missed? |
| 17:02 |
miker |
width works better, yeah. the height is usually dominated by other content |
| 17:05 |
miker |
Stompro: I have not, but I agree, it should be doable. not sure if there's a perfect solution for rescheduled appointments that are very near the original, but then, that's kinda like hold-shelf expiration. (though I grant more likely for curbside.) I imagine with some restrictions (have to reschedule at least 24h later or something) you could use max-delay to hide previous notices |
| 17:06 |
miker |
or (new dev) we could cause a reschedule to emit a new event |
| 17:08 |
Stompro |
miker, thanks for the thoughts. |
| 17:14 |
|
mmorgan left #evergreen |
| 17:20 |
|
dbwells joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:17 |
|
jihpringle joined #evergreen |
| 18:27 |
|
dbwells joined #evergreen |
| 20:42 |
|
Stompro joined #evergreen |
| 20:48 |
|
Stompro joined #evergreen |
| 22:32 |
|
sandbergja joined #evergreen |
| 22:50 |
|
sandbergja joined #evergreen |
| 23:18 |
|
sandbergja joined #evergreen |
| 23:51 |
|
sandbergja joined #evergreen |
