Time |
Nick |
Message |
04:44 |
pinesol |
News from qatests: Failed Installing OpenSRF pre-requisites <http://testing.evergreen-ils.org/~live//archive/2020-03/2020-03-26_04:00:03/test.7.html> |
06:47 |
|
rfrasur joined #evergreen |
07:28 |
|
rjackson_isl_hom joined #evergreen |
07:45 |
|
Dyrcona joined #evergreen |
08:08 |
|
alynn26 joined #evergreen |
08:13 |
|
dbwells joined #evergreen |
08:21 |
|
mantis1 joined #evergreen |
08:23 |
|
rfrasur joined #evergreen |
08:26 |
|
alynn26 joined #evergreen |
08:28 |
|
mmorgan joined #evergreen |
09:04 |
Dyrcona |
Anyone else ever notice that holds can have a cancel time set, but cancel cause is null? |
09:07 |
|
jvwoolf joined #evergreen |
09:12 |
|
jvwoolf joined #evergreen |
09:21 |
|
Stompro joined #evergreen |
09:23 |
|
sandbergja joined #evergreen |
09:24 |
|
dbwells joined #evergreen |
09:30 |
* Dyrcona |
is really stumped.... |
09:37 |
mmorgan |
Dyrcona: Because of the lack of cancel cause? |
09:37 |
Dyrcona |
No, bug 1813088 |
09:37 |
pinesol |
Launchpad bug 1813088 in Evergreen 3.4 "Notify by Email column on Hold Shelf not populating" [Undecided,Confirmed] https://launchpad.net/bugs/1813088 |
09:40 |
Dyrcona |
I suppose I could try reverting the wide holds commits and see what happens. |
09:46 |
Dyrcona |
Maybe, I'll start with commit 5d28b84c87d11cac205ec3b74f758e8824d77536 though I really doubt that's the problem. |
09:46 |
pinesol |
Dyrcona: [evergreen|Kathy Lussier] LP#1538691: Use items instead of copies - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5d28b84> |
09:50 |
|
jvwoolf1 joined #evergreen |
09:50 |
Dyrcona |
Whee! Reverting that commit leads to lots of conflict markers. |
09:51 |
Dyrcona |
Guess I'll have to revert the other commit from that branch, too. |
09:51 |
Dyrcona |
Conflicts there, too.... |
09:54 |
Dyrcona |
conflicts-- |
10:02 |
Dyrcona |
conflicts-- |
10:06 |
Dyrcona |
conflicts-- |
10:07 |
rfrasur |
Dyrcona++ |
10:14 |
Dyrcona |
All right. I'm getting somewhere. If I revert the wide holds commits from bug 1712854, I get Yes/No for the true/false fields on the holds shelf list. |
10:14 |
pinesol |
Launchpad bug 1712854 in Evergreen 3.1 "web client: Sorting for view record holds and holds shelf interfaces" [High,Confirmed] https://launchpad.net/bugs/1712854 |
10:14 |
Dyrcona |
Well, I reverted the whole branch, not just the wide holds commits. |
10:23 |
miker |
csharp: re template from yesterday, just to be clear, when building the template did you add a filter value and then use the "Change Filter Value" option to make it "empty" or did you use "Remove Filter Value"? |
10:27 |
csharp |
miker: the first time I used "Change Filter Value", then I clicked "Remove Filter Value" - hmm - maybe it's showing up blank because it's " |
10:27 |
csharp |
" |
10:28 |
csharp |
I'll try recreating it - it's a simple template to do |
10:30 |
|
alynn26 joined #evergreen |
10:30 |
miker |
csharp: that's my thought ... and thanks |
10:31 |
|
RBecker joined #evergreen |
10:31 |
csharp |
miker: this is my attempt just now - hard-coding the filter to "1" https://pastebin.com/cPn62jrs |
10:32 |
csharp |
in the UI it still comes up with a box with no value in it |
10:32 |
csharp |
I can create a screenshot if it's helpful |
10:32 |
|
mmorgan1 joined #evergreen |
10:33 |
csharp |
miker: just edited that paste to include the paths I'm taking to create the report |
10:33 |
csharp |
er... template, that is |
10:35 |
miker |
Dyrcona: so, I've traced the code. it's JS being JS. in egGridValueFilter, the switch() you previously identified, 1 !== "1" (Number() in the data, String() in the case) |
10:35 |
csharp |
@blame JS for being JS |
10:35 |
pinesol |
csharp: JS is probably integrated with systemd for being JS |
10:36 |
csharp |
@band add Destructo Dog |
10:36 |
pinesol |
csharp: Band 'Destructo Dog' added to list |
10:38 |
miker |
Dyrcona: so we could either force the value to be a string in the switch -- switch(''+value) -- or we could add more cases for 1 and 0 |
10:39 |
Dyrcona |
Hmmm... more cases versus type coercion..... |
10:39 |
Dyrcona |
Type coercion wins. |
10:39 |
miker |
https://www.w3schools.com/js/js_switch.asp (search down for comparison) |
10:41 |
Dyrcona |
miker: I've determined that the breakage happens with the first commit from the wide holds branch, so I'll make the type coercion change before unreverting the rest of the branch to see if that resolves it. |
10:42 |
|
khuckins joined #evergreen |
10:42 |
miker |
Dyrcona++ |
10:53 |
Dyrcona |
miker++ # Saved me another hour with the JS debugger. |
10:55 |
miker |
"save the time of the reader^Wdebugger" |
11:15 |
mmorgan |
Weird to see a library pull list with almost nothing on it in production. |
11:28 |
Dyrcona |
mmorgan: Disabled the placing of holds? |
11:31 |
mmorgan |
No, we're accepting holds, but libraries are closed and library settings are set to not target copies. |
11:35 |
|
khucki___ joined #evergreen |
11:35 |
rfrasur |
mmorgan - same in Indiana (Evergreen libraries, at least) |
11:36 |
Dyrcona |
We've done all kinds of things with holds, but on a library by library basis, so I'm not sure where we're at. Someone else does most of that here. |
11:40 |
mmorgan |
We really haven't done much to change holds, other than pushing ahead expiration dates. We've turned off notification triggers, and set emergency closings, but nothing else really. |
12:03 |
Dyrcona |
Pushing forward expiration dates on holds is where my question about cancel cause came from. It bit us and we uncanceled some holds that shouldn't have been. |
12:06 |
Dyrcona |
I was able to restore a backup from before the update and find the affected holds, so we can fix it tonight. |
12:08 |
mmorgan |
So the holds with the missing cancel cause should not have been un cancelled? |
12:10 |
Dyrcona |
Correct. |
12:10 |
Dyrcona |
They had cancel time set but null in cancel cause. |
12:11 |
Dyrcona |
We wanted to uncancel holds with cancel cause 1, so my logic (cancel_cause is null or cancel_case = 1) with no reference to cancel_time uncanceled some holds that it shouldn't have. |
12:11 |
Dyrcona |
Cancel cause 1 is expired untargeted hold expiration. |
12:21 |
Dyrcona |
So for the logs, and for next time, the logic should be ((cancel_time is null and cancel_casue is null) or cancel_cause = 1) |
12:21 |
Dyrcona |
Barring typos, of course. :) |
12:23 |
|
jihpringle joined #evergreen |
12:24 |
csharp |
backups++ |
12:25 |
csharp |
speaking of backups, my preferred method of batch changing kind of anything is to select * into a table somewhere, then make the change from the table - that way I have a readily accessible backup of whatever I've changed and what it looked like before |
12:26 |
csharp |
the only downside is remembering to delete that temp table later, which I'm kind of bad about |
12:27 |
Dyrcona |
csharp: I do that select * into a table sometimes, usually just when it's for something temporary. |
12:27 |
Dyrcona |
Yeahp. I just deleted one that had been hanging around since 207 or so. |
12:28 |
Dyrcona |
uh, 207 was supposed to be 2017. |
12:33 |
csharp |
truly_ancient_files++ |
12:34 |
Dyrcona |
:) |
12:34 |
csharp |
because after long enough, the old data becomes archives-worthy :-) |
12:34 |
Dyrcona |
We have a custom/local schema for this stuff, cwmars. |
12:34 |
Dyrcona |
Also have some functions for updates we do a lot. |
12:35 |
csharp |
https://www.youtube.com/watch?v=XW-szjN_MdA |
12:37 |
Dyrcona |
Priceless! :) |
12:41 |
|
mrisher joined #evergreen |
12:48 |
Dyrcona |
If we increase the limit for number of items out, do the current blocks disappear? The voice in my head says, "No." |
12:51 |
|
sandbergja joined #evergreen |
12:51 |
|
khuckins_ joined #evergreen |
12:53 |
Dyrcona |
jeff: Are you working on bug 1743611? |
12:53 |
pinesol |
Launchpad bug 1743611 in Evergreen "Web Client: Lost Circ History by Year Info" [High,Confirmed] https://launchpad.net/bugs/1743611 - Assigned to Jeff Godin (jgodin) |
13:11 |
|
jvwoolf joined #evergreen |
14:41 |
|
jvwoolf joined #evergreen |
14:44 |
|
alynn26_away joined #evergreen |
14:44 |
|
jihpringle joined #evergreen |
15:03 |
|
jihpringle joined #evergreen |
15:05 |
|
sandbergja joined #evergreen |
15:10 |
|
BAMkubasa joined #evergreen |
15:11 |
BAMkubasa |
Anyone know what database table data in the closed dates editor lives: /eg/staff/admin/local/actor/closed_dates |
15:12 |
mmorgan |
BAMkubasa: actor.org_unit_closed |
15:12 |
BAMkubasa |
mmorgan! |
15:12 |
* mmorgan |
has been looking at it a lot lately :) |
15:13 |
BAMkubasa |
tell me about it |
15:32 |
|
mantis1 left #evergreen |
15:43 |
|
rfrasur joined #evergreen |
15:57 |
|
Stompro joined #evergreen |
16:25 |
|
mikerisher joined #evergreen |
17:05 |
|
mmorgan left #evergreen |
17:34 |
|
jihpringle joined #evergreen |
18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:31 |
|
sandbergja_ joined #evergreen |
20:48 |
|
dbwells joined #evergreen |
20:49 |
|
devted joined #evergreen |
21:06 |
|
Stompro joined #evergreen |
21:06 |
|
yar joined #evergreen |
21:09 |
|
Stompro joined #evergreen |
22:40 |
|
sandbergja joined #evergreen |
23:33 |
|
mrisher joined #evergreen |