| Time |
Nick |
Message |
| 02:47 |
|
eby joined #evergreen |
| 02:47 |
|
sard joined #evergreen |
| 02:47 |
|
ejk joined #evergreen |
| 04:51 |
|
jamesrf joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:45 |
|
agoben joined #evergreen |
| 07:17 |
|
rjackson_isl joined #evergreen |
| 07:47 |
|
collum joined #evergreen |
| 08:38 |
|
bos20k joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 08:44 |
|
terran joined #evergreen |
| 08:50 |
terran |
Good morning bug squashers / feedback fest folks (feedback festers sounded bad)! |
| 08:50 |
terran |
This week's tracking sheet is here: https://docs.google.com/spreadsheets/d/1oxM5dA2FqPhUD81IIhnsoTuVkbfB2VoYTBKfhGMPwjk/edit#gid=0 |
| 08:51 |
terran |
Bmagic++ for setting up a testing sandbox! Info here: https://docs.google.com/spreadsheets/d/1CLnGL1lzD3EVc3ppbjClR373U_0D3GZZ9vwRBzcRqII/edit#gid=1522803439 |
| 08:51 |
mmorgan |
Good morning! |
| 08:51 |
mmorgan |
@coffee Bug Squashers |
| 08:51 |
* pinesol |
brews and pours a cup of Hamma Cooperative Yirgacheffe, Fair-Trade Organic, and sends it sliding down the bar to Bug Squashers |
| 08:55 |
remingtron |
terran: the tracking sheet says "You need permission" |
| 08:59 |
terran |
remingtron: It should be set to view... |
| 08:59 |
terran |
remingtron: please try again now |
| 09:00 |
remingtron |
working, thanks! |
| 09:08 |
terran |
remingtron++ |
| 09:26 |
|
Dyrcona joined #evergreen |
| 09:32 |
|
jamesrf joined #evergreen |
| 09:34 |
|
yboston joined #evergreen |
| 09:55 |
|
khaun joined #evergreen |
| 09:57 |
|
bos20k joined #evergreen |
| 10:03 |
|
mmorgan1 joined #evergreen |
| 10:49 |
Bmagic |
I've got a strange situation. An item was borrowed and circed at library B (owned by library A) - once returned it was checked in at library B. Standard stuff. But the kicker is that the system didn't put the item back into transit to go back to Library A. It stayed at Library B. |
| 10:49 |
Bmagic |
The item is not setup as floating |
| 10:49 |
jeff |
"suppress holds and transits"? |
| 10:49 |
Bmagic |
what's that? A checkin modifier? |
| 10:49 |
jeff |
yes. |
| 10:50 |
Bmagic |
oh geez. That sounds like it |
| 10:51 |
Bmagic |
jeff++ |
| 10:52 |
Bmagic |
I learn something new everyday |
| 10:57 |
|
mmorgan joined #evergreen |
| 10:59 |
|
yboston joined #evergreen |
| 11:01 |
|
littlet joined #evergreen |
| 11:12 |
Dyrcona |
Evergreen needs a patron export program, like marc_export for patrons. |
| 11:15 |
rhamby |
Dyronca: seems reasonable |
| 11:16 |
jeff |
Dyrcona: use case? |
| 11:17 |
Dyrcona |
A member library is leaving and they asked for a dump of their patrons to take with them. |
| 11:17 |
Dyrcona |
The EOLI migration-tools have export_evergreen_library, but that's overkill. |
| 11:18 |
Dyrcona |
Unfortunately, no one told me until today, that they wanted a dump of their patrons, so I may just have to say too bad. |
| 11:19 |
terran |
Boo-hiss to anyone leaving Evergreen! |
| 11:19 |
terran |
(But also +1 to a patron-export tool) |
| 11:19 |
Dyrcona |
terran: If it is any consolation, they're a community college and they're moving to a Koha consortium. |
| 11:20 |
Dyrcona |
The academics are a minority in our consortium, so some jumped ship last year with a couple of other libraries to form a new consortium, just of themselves. |
| 11:21 |
Dyrcona |
Looks like we may be getting a new public library member, anyway. |
| 11:22 |
terran |
Dyrcona: at least they're sticking with open source |
| 11:22 |
|
khuckins joined #evergreen |
| 11:23 |
Dyrcona |
terran: Yeah, hence the "consolation." Plus, I hear Koha has course reserves. |
| 11:24 |
Dyrcona |
Guess if I have to send them some patron data, I can steal code from the migration-tools. |
| 11:25 |
Dyrcona |
I think one of the staff at the libraries that left last year got their patron data via reports. Not sure the report exists any more. |
| 11:26 |
Dyrcona |
Yeah, got an email reply saying they're asking the director about running the report. |
| 11:33 |
|
aabbee joined #evergreen |
| 12:07 |
rhamby |
terran: I wouldn't feel bad about anyone moving to Koha, as much as I love Evergreen I think Koha is a great fit for some instutitions |
| 12:08 |
terran |
rhamby: absolutely - especially if it is a small institution (I did my best to get my old university where I worked to move to Koha) |
| 12:09 |
rhamby |
terran: I don't think it's so much an issue of size as instutitional complexity, Koha can handle large data sets well, it can even handle consortia well - if the consortia want the same rules, if they want the power of lots of choices per instutition that's where Koha and Evergreen really split IMO |
| 13:49 |
|
terran joined #evergreen |
| 13:52 |
terran |
khuckins++ for submitting first new patch of the week :) |
| 13:54 |
terran |
And collum++ for the second! |
| 13:57 |
csharp |
fighting an issue where I'm trying to make a perm profile able to grant/change a perm (in this case ASSIGN_WORK_ORG_UNIT) - I've made sure the profile has the perm grantable at the System level, but when I open perms for a user of the same org/working location, that perm remains greyed out |
| 13:58 |
csharp |
if I understood the filtering logic for what's active/inactive as the perms editor grid is loaded, it would help me track down the problem |
| 14:11 |
pinesol |
[evergreen|Remington Steed] LP#1669120: Make scrollable dropdown height match column picker - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=04bc8b3> |
| 14:13 |
csharp |
does someone know the file path to the dojo pieces that load the user perms editor? |
| 14:14 |
berick |
csharp: /xul/server/patron/user_edit.xhtml |
| 14:14 |
berick |
in the installed directory, anyway |
| 14:15 |
csharp |
berick: thank you - I didn't realize anything was still pulling from the xul dir |
| 14:28 |
berick |
indeed, one of the complications with 'rm -rf xul' |
| 14:30 |
Dyrcona |
Cross the streams! |
| 14:33 |
csharp |
I'm going to have to walk away from this because I'm getting frustrated, but everything I'm looking at would indicate that the perm I'm trying to change shouldn't be greyed out |
| 14:43 |
|
stephengwills joined #evergreen |
| 14:51 |
berick |
grabbin' 1164 |
| 14:55 |
terran |
The web client is using the Bootstrap CSS library, right? (Or am I misremembering?) |
| 14:55 |
berick |
terran: that's right |
| 14:55 |
terran |
berick++ |
| 14:55 |
berick |
terran: AngJS is bootstrap 3, angular is bootstrap 4 |
| 14:56 |
terran |
Ooh, thanks, I didn't realize that difference |
| 15:01 |
Bmagic |
do people typically add an index for extend_reporter.legacy_circ_count.id ? |
| 15:02 |
csharp |
Bmagic: I see "legacy_circ_count_pkey" PRIMARY KEY, btree (id) when I \d+ that table |
| 15:02 |
Bmagic |
it seems that now that we have put some data in there, related reports are timing out - however it seems that postgres would have indexed it already? CONSTRAINT legacy_circ_count_pkey PRIMARY KEY (id) |
| 15:02 |
|
mmorgan1 joined #evergreen |
| 15:02 |
Bmagic |
jinx |
| 15:02 |
csharp |
yeah |
| 15:03 |
* csharp |
is looking at bug 1795972 |
| 15:03 |
pinesol |
Launchpad bug 1795972 in Evergreen "APPLY_WORKSTATION_SETTING perm description needs repair" [Undecided,New] https://launchpad.net/bugs/1795972 |
| 15:04 |
csharp |
do we care if someone has already changed the description of that? I was planning to clobber it with the upgrade script, but didn't know if that would be a Bad Idea™ |
| 15:05 |
* csharp |
moves forward with the plan to clobber it barring any objections |
| 15:06 |
Bmagic |
clobber++ |
| 15:07 |
jeff |
There are lots of other cases where we want to account for "changed / fixed it locally already", but IMO correcting a description isn't one of them. You can make a WHERE description <> 'new description here' to prevent a needless update, but even that seems unnecessary in this situation. |
| 15:08 |
csharp |
makes sense to me |
| 15:08 |
Bmagic |
yeah - good call - make sure they haven't changed it to something other than previous-stock |
| 15:08 |
Bmagic |
jeff++ # the pearls are flowing |
| 15:10 |
jeff |
you could do that also, a bit of the opposite approach. |
| 15:12 |
Dyrcona |
Bmagic: Just because you have an index doesn't mean that the planner will use it. |
| 15:13 |
Bmagic |
Dyrcona: apparently it's not because it's taking over an hour. I am going to have to wait a long time to get the explain analyze but I will hopefully have more information on the matter |
| 15:14 |
csharp |
EXPLAIN ANALYZE FASTER |
| 15:14 |
Dyrcona |
Bmagic: It could be using that index. It may be slow for some other reason... |
| 15:15 |
Bmagic |
I agree - the index was just my theory based on what I know. I know we just* put a ton of rows in that table and suddenly related reports are timing out |
| 15:15 |
jeff |
(like a significant change in number of rows without updating statistics) |
| 15:15 |
Dyrcona |
Bmagic: Did you analyze the table after adding the index? |
| 15:15 |
bshum |
It might be good to do just a regular analyze on the table then |
| 15:15 |
csharp |
me three |
| 15:15 |
Dyrcona |
bshum: Jinx! ;) |
| 15:15 |
jeff |
which can cause the planner to make decisions that are now poor in light of the new reality. |
| 15:15 |
Bmagic |
I haven't changed the table with regards to indexes (yet) |
| 15:16 |
Dyrcona |
I've seen Pg skip indexes when the table is "big enough." |
| 15:16 |
Dyrcona |
It just seems to say, "I'm gonna need to read 20GB of data anyway, so....." |
| 15:17 |
pinesol |
[evergreen|Remington Steed] LP#1774707: Allow saving Group Member Details grid settings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f04c373> |
| 15:17 |
pinesol |
[evergreen|Michele Morgan] LP#1774707: Add Seed Data for worstation setting for group member details - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c26da31> |
| 15:17 |
pinesol |
[evergreen|Bill Erickson] LP1774707 Stamping DB update: group members grid - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=79f27ab> |
| 15:19 |
csharp |
1) ANALYZE <table> 2) you can change the stats globally with default_statistics_target or per table/column with alter table |
| 15:20 |
csharp |
that hasn't always helped me though, so I add that to the mysteries I just live with |
| 15:20 |
Bmagic |
csharp: Dyrcona: Thanks! |
| 15:22 |
Dyrcona |
Bmagic: bshum says you're welcome. He mentioned it to me in private, and I commented back that I'd thought of that but didn't mention it. :) |
| 15:23 |
Bmagic |
lol |
| 15:24 |
csharp |
bshum is feeding us all of our lines in here, you know :-) |
| 15:24 |
csharp |
@who is pulling all of our strings |
| 15:24 |
pinesol |
jeffdavis is pulling all of our strings. |
| 15:25 |
bshum |
csharp: Dyrcona: Haha :) |
| 15:25 |
bshum |
I miss postgresql |
| 15:47 |
pinesol |
[evergreen|Bill Erickson] LP1817601 MARC Flat Text Editor Monospace Font - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=36e6e00> |
| 16:10 |
|
sandbergja joined #evergreen |
| 16:20 |
|
sandbergja joined #evergreen |
| 16:29 |
|
sandbergja joined #evergreen |
| 16:33 |
Bmagic |
Dyrcona: csharp: it looks like the issue is with the subquery-turned-into-table for "Last Date Circulated" which is defined in fm_IDL.xml as "rlc" reporter::last_circ_date |
| 16:35 |
Bmagic |
That in concert with "erfcc" "extend_reporter.full_circ_count" |
| 16:35 |
Bmagic |
I manually edited the Clark query and removed the subquery in favor of generating the last date circulated a different way - and it finished in 2 minutes |
| 16:37 |
|
mmorgan joined #evergreen |
| 16:37 |
Dyrcona |
Bmagic: Sounds about right. I've never had much look with the reporter myself. The SQL that I come up with is almost always faster than what *I* can get out of the reporter. (Emphasis on I because I almost always screw up when using the reporter.) |
| 16:38 |
Bmagic |
This issue isn't going to drive me to a completely different reporting platform just yet. |
| 16:39 |
Dyrcona |
Well, it hasn't done that to me, either. I just don't do reports. :) |
| 16:40 |
Bmagic |
you're lucky in that way! |
| 16:41 |
Dyrcona |
No, not lucky. It's a conscious choice. |
| 16:44 |
Bmagic |
FWIW https://explain.depesz.com/s/hScG |
| 16:47 |
pastebot |
"Bmagic" at 168.25.130.30 pasted "The reporter query that made https://explain.depesz.com/s/hScG" (36 lines) at http://paste.evergreen-ils.org/10008 |
| 16:50 |
Bmagic |
That sort is looking heafty |
| 16:50 |
Dyrcona |
To be honest with you, I'm not super proficient at reading explain output. |
| 16:51 |
Bmagic |
me either |
| 16:51 |
Bmagic |
depresz's tool makes it slightly* more clear |
| 16:51 |
Dyrcona |
I was about to disagree with that, at least for me. |
| 16:51 |
Bmagic |
lol |
| 16:51 |
Bmagic |
you can collapse the loops |
| 16:58 |
pinesol |
[evergreen|Kyle Huckins] lp1538678 Apply Warning Prompt when leaving dirty MARC editor - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d13e2e1> |
| 16:58 |
pinesol |
[evergreen|Kyle Huckins] lp1538678 MARC edit warning prompt translateable strings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=aff1d5d> |
| 17:02 |
pinesol |
News from qatests: Failed Create Evergreen Database <http://testing.evergreen-ils.org/~live/test.41.html#2019-05-20T16:58:09,067836175-0400 -0> |
| 17:02 |
bshum |
Ho hum |
| 17:03 |
Dyrcona |
Catch you later, bshum! :) |
| 17:08 |
|
mmorgan left #evergreen |
| 17:17 |
* dbwells |
pushes a quick fix for the test failure |
| 17:18 |
pinesol |
[evergreen|Dan Wells] LP#1774707 Quick fix-up: add missing comma - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d9f4558> |
| 17:19 |
berick |
dbwells++ |
| 17:20 |
berick |
only tested the upgrade script |
| 17:20 |
Dyrcona |
That happens.... |
| 17:20 |
Dyrcona |
dbwells++ |
| 17:26 |
aabbee |
"mark damaged failed: Event: 0:SUCCESS" |
| 17:26 |
aabbee |
wat. |
| 18:20 |
|
sandbergja joined #evergreen |
| 19:09 |
|
sandbergja joined #evergreen |
| 19:55 |
|
sandbergja joined #evergreen |
| 21:29 |
|
stephengwills joined #evergreen |
| 22:00 |
|
sandbergja joined #evergreen |
| 22:54 |
|
sandbergja joined #evergreen |
