| 05:46 |
|
JBoyer joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Failed Create Evergreen Database <http://testing.evergreen-ils.org/~live//archive/2022-03/2022-03-25_04:00:03/test.41.html> |
| 08:33 |
|
mantis joined #evergreen |
| 08:46 |
|
mmorgan joined #evergreen |
| 08:59 |
|
rjackson_isl_hom joined #evergreen |
| 09:16 |
|
rfrasur joined #evergreen |
| 09:22 |
|
Dyrcona joined #evergreen |
| 09:28 |
|
Keith-isl joined #evergreen |
| 09:39 |
miker |
Dyrcona: do you have any thoughts on what's up with the db tests? perhaps we need to spell "install the postgres contrib modules" differently for PG 10+? |
| 09:41 |
miker |
it /seems/ to be just the pgtap stuff that's failing, but even that seems like maybe a red herring because the end of the db log is "ERROR: could not open extension control file "/usr/share/postgresql/10/extension/pgtap.control": No such file or directory" ... but right above it says it's building pgtap with PG 14.2 |
| 09:43 |
Dyrcona |
miker: I never encountered a problem with pgtap during my testing. I always installed the version-specific pgtap packages. |
| 09:45 |
Dyrcona |
I can take another look later today. |
| 09:45 |
miker |
Dyrcona: kk ... I'm not familiar with exactly how the auto-tester works, but I know someone who is! (phasefx...) I may poke more later, but it seems to be a false positive ATM |
| 09:46 |
Dyrcona |
Do you have multiple versions of Pg running on the same server? |
| 09:47 |
Dyrcona |
It might also be a case where a newer psql version breaks things if the db version is older... I've not had that happen before. |
| 09:48 |
Dyrcona |
I'm working on something else at the moment, but I should be able to have a look on a test system in a bit. |
| 09:48 |
miker |
I mean, /I/ don't. I think the tester just says "I'm buster (or whatever), install what I need" |
| 09:49 |
miker |
there's no human intervention past the baseline OS install, IIUC |
| 09:50 |
csharp_ |
@blame [someone] |
| 13:09 |
miker |
JBoyer++ |
| 13:17 |
Dyrcona |
miker JBoyer: You installed pgtatp from source? Did I understand that correctly? |
| 13:18 |
JBoyer |
I don't, but the tester install script has for as long as I've ever known. |
| 13:20 |
Dyrcona |
Oh, OK. I didn't realize it was the test server. |
| 13:20 |
Dyrcona |
I thought miker was running pgtap tests on his own and having issues. |
| 13:20 |
Dyrcona |
JBoyer++ |
| 13:47 |
JBoyer |
Ok, I've changed the tester to look up the currently installed version of postgresql-server-dev-XYZ and install the correct pgtap package based on that. |
| 13:48 |
JBoyer |
This way apt-get should handle the dependencies and we still don't have to bother tracking what version of pg is installed by default. |
| 14:41 |
miker |
JBoyer++ |
| 14:42 |
miker |
Dyrcona: sorry, yeah, I was just looking at the test failures reported in here by the bot |
| 15:40 |
jvwoolf |
Finally getting around to testing deleting action_trigger.event_output. But it doesn't seem to cascade delete. It just yells about the ID being referenced in the event table. |
| 15:42 |
rhamby |
jvwoolf yeah, you need to eitther set the relevant event references (error output, template output) to null or delete the events first |
| 15:43 |
Dyrcona |
I thought it had on delete cascade... |
| 15:44 |
mmorgan |
jvwoolf: We saw the same thing. The database function deletes the events first, then cleans up the orphaned output. |
| 17:11 |
pinesol |
Launchpad bug 1091588 in Evergreen "Send out emails in patron's preferred language" [Wishlist,Confirmed] |
| 17:11 |
pinesol |
Launchpad bug 1839341 in Evergreen "Port Local Admin Org Unit Settings UI to Angular" [Wishlist,Confirmed] |
| 17:12 |
miker |
he said after 5pm on Friday... |
| 17:23 |
pinesol |
News from commits: Stamping upgrade script for JQuery YAOUS <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=3863ed4177da51362969ca4c99d421a2afdf135c> |
| 17:23 |
pinesol |
News from commits: adding query to opac by library setting <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=97cbb770058dbd8e360c9a383e6bcc4151831629> |
| 17:53 |
pinesol |
News from commits: LP1956970 Sort Patron Notes - Most Recent First <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=60efc98ffe680de07cc270c803c7cdeeac07f1ad> |
| 17:53 |
pinesol |
News from commits: LP1930614 Bootstrap OPAC Summary Block <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=e2028ee29bab4f970a8fa6354b64723674b7286e> |
| 18:01 |
pinesol |
News from qatests: Failed Create Evergreen Database <http://testing.evergreen-ils.org/~live//archive/2022-03/2022-03-25_16:00:02/test.41.html> |
| 18:16 |
|
rjackson_isl_hom joined #evergreen |
| 18:53 |
|
Keith__isl joined #evergreen |
| 18:54 |
JBoyer |
Ah, nerts. Tried to be “clever” with the petal fix and it backfired. I’ll fix that later. |
| 05:30 |
|
JBoyer joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live//archive/2022-03/2022-03-22_04:00:05/test.29.html> |
| 06:36 |
|
rfrasur joined #evergreen |
| 06:50 |
|
rjackson_isl_hom joined #evergreen |
| 07:58 |
|
collum joined #evergreen |
| 09:45 |
mmorgan |
https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/400.schema.action_trigger.sql;hb=5b7187ce79dd13cc567d6dee5c46554333b9b5e1#l337 |
| 09:46 |
mmorgan |
jvwoolf: I think batches could be done while the system is up, but would defer to Dyrcona :) |
| 09:47 |
JBoyer |
jvwoolf, what version are you on? I forget when the indexes on action_trigger.event (all of the output fields) went in, but they were basically required to make that function work on a large-ish system. |
| 09:47 |
jvwoolf |
JBoyer: We're on 3.6.5 |
| 09:49 |
jvwoolf |
JBoyer: What's funny that we have tested this on many a test database with our production data, and it always completes in 15-20 minutes. |
| 09:51 |
Dyrcona |
jvwoolf: You should be able to purge everything while the system is up. I'm suggesting just doing: DELETE FROM action_trigger.event_output WHERE .... LIMIT {some number}; It should cascade to delete from action_trigger.event. |
| 09:51 |
mmorgan |
jvwoolf: Could any action triggers be running when you are attempting the purge? |
| 09:52 |
jvwoolf |
mmorgan: No, we took Evergreen offline and disabled all cron jobs |
| 09:57 |
JBoyer |
Oh, that makes sense. I thought it was also having trouble at some point, maybe both, |
| 09:58 |
* Dyrcona |
refreshes his memory on copy (....) to csv.... 'cause newer psql with the --csv option has spoiled me. |
| 09:59 |
Dyrcona |
Yeah, could just be busted after the recent upgrade. Possibly a Python 2 to 3 issue. |
| 09:59 |
jvwoolf |
Oh yep. |
| 09:59 |
jvwoolf |
According to Pg Admin, 0 indexes on action_trigger.event_output |
| 10:00 |
jvwoolf |
Same thing on the test databases where it worked, though |
| 10:02 |
jvwoolf |
Oh wait I take it back |
| 10:04 |
jvwoolf |
I looked in the wrong place, we have all of the indexes listed here on action_trigger.event |
| 10:05 |
JBoyer |
It would be weird if you didn't, but I was hoping that would find something. In that case, maybe compare the indexes on both that and event_output on test and prod and see if anything is different. |
| 10:06 |
Dyrcona |
Well, sometimes a DB upgrade script slips through the cracks. |
| 10:09 |
* Dyrcona |
is looking into a report that a patron got spammed with a call number via sms, so also poking around action_trigger.event at the moment. |
| 10:10 |
jvwoolf |
JBoyer: They look the same. Our process is not to reload test databases anyway, we replace them with the most recent dump of production we have when we need to update them. So our test database *should* always be the same as production. |
| 10:10 |
jvwoolf |
We do replication on production, that's the only difference |
| 10:11 |
Dyrcona |
Replication can slow large deletes and is a good reason to limit them. |
| 10:12 |
Dyrcona |
So, looks like the patron sent themselves the same call number 729 times over a 4-day period. I think I'll check the apache and/or gatweay logs. |
| 10:12 |
JBoyer |
Ah, and depending on settings and what's happening on the replicant it can cause delays in large commits. Though I wouldn't really expect that for a/t stuff. |
| 16:20 |
|
Keith_isl joined #evergreen |
| 17:09 |
|
mmorgan left #evergreen |
| 17:26 |
|
jvwoolf left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:17 |
|
rfrasur joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:49 |
|
JBoyer joined #evergreen |
| 07:30 |
|
rjackson_isl_hom joined #evergreen |
| 07:57 |
|
rfrasur joined #evergreen |
| 10:34 |
csharp_ |
probably a worthwhile security discussion |
| 10:35 |
Dyrcona |
Given the number of malicious packages that turn up, our use of npm is a worthwhile security discussion. |
| 10:38 |
Dyrcona |
Github seems to be OK, now. I can access npm. |
| 10:39 |
terranm |
gmcharlt: Yesterday Bill revised the patch for bug 1958265 that you have on festivus - could you please update it with the newest version for testing? |
| 10:39 |
pinesol |
Launchpad bug 1958265 in Evergreen "Angular Holds Pull List - Download CSV and Print Full Grid missing barcode" [Medium,Confirmed] https://launchpad.net/bugs/1958265 |
| 10:40 |
terranm |
gmcharlt: Bill also updated the patch for bug 1950826 which is also loaded onto festivus |
| 10:40 |
pinesol |
Launchpad bug 1950826 in Evergreen 3.7 "invalidate email silent failure" [High,Confirmed] https://launchpad.net/bugs/1950826 |
| 13:52 |
pinesol |
Launchpad bug 1920039 in Evergreen "Bootstrap Opac: More Details button does not change on use" [Medium,Confirmed] https://launchpad.net/bugs/1920039 |
| 13:52 |
Dyrcona |
mmorgan++ |
| 14:06 |
Dyrcona |
I have number of signedoff branches that have been signed off for a while. Maybe I'll push them in later? They're almost all bug fixes. |
| 14:09 |
Dyrcona |
And one where our own testing has been held up by the pandemic and other things. |
| 14:10 |
gmcharlt |
rfrasur++ # giving ALL Evergreen catalogers a vacation ;) |
| 14:10 |
Dyrcona |
:) |
| 14:11 |
rfrasur |
You're so very welcome :)) |
| 14:28 |
Dyrcona |
Yum! |
| 14:28 |
JBoyer |
Been too long since I looked at it. |
| 14:29 |
Dyrcona |
JBoyer: If you're talking about the branch, I just fixed it today while going through my local branches. |
| 14:40 |
JBoyer |
For anyone interested in testing lp 1091588 (different A/T templates for user-specific locales) I've set up pattypan to send email and have updated the Test Email Notification template with all of the currently available non-English locales (According to Google Translate, anyway.) |
| 14:40 |
pinesol |
Launchpad bug 1091588 in Evergreen "Send out emails in patron's preferred language" [Wishlist,Confirmed] https://launchpad.net/bugs/1091588 |
| 15:00 |
|
jihpringle joined #evergreen |
| 15:58 |
|
terranm joined #evergreen |
| 17:07 |
|
rfrasur joined #evergreen |
| 17:16 |
|
mmorgan left #evergreen |
| 17:31 |
|
jvwoolf left #evergreen |
| 17:44 |
|
jihpringle joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 22:50 |
|
JBoyer joined #evergreen |
| 01:54 |
|
dbs joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:15 |
|
rjackson_isl_hom joined #evergreen |
| 07:48 |
|
rjackson_isl_hom joined #evergreen |
| 08:01 |
|
rfrasur joined #evergreen |
| 09:53 |
Dyrcona |
miker: Yeah, I was about to say that the call used in the OPAC sorts the holds in the backend. |
| 09:54 |
Dyrcona |
I'll try it on our training server, then Lp it, and push a working branch. |
| 10:05 |
Bmagic |
This bug continues. The query that Evergreen creates still can create duplicate rows. This time due to multiple hold notes. Consider this query: https://pastebin.com/rFfzJa5D |
| 10:07 |
Bmagic |
If a hold has more than one note, the query returns more than one copy of the hold for the pull list. Which breaks pagination. So, I'm thinking that the pull list code needs to DISTINCT or GROUP BY. However, there are 49 columns there, that would be a "fun" GROUP BY clause. I've gone ahead and tested the query with DISTINCT and again with GROUP BY |
| 10:08 |
Bmagic |
There is an error, because the ORDER BY clause is ordering by the shelving location, which isn't in the column selection. And that's not been an issue apparently. But it is an issue as soon as you want PG to dedupe the rows |
| 10:09 |
Bmagic |
My question is: can I just edit the Evergreen code so that it does ask PG for the shelving location column? |
| 10:15 |
Bmagic |
ahopl |
| 11:06 |
berick |
haven't looked recently for a fix, could be one |
| 11:08 |
Dyrcona |
breick: Ok. Thanks.... |
| 11:09 |
Dyrcona |
grr. berick ^^ |
| 11:11 |
Dyrcona |
Well, that puts the kibosh on the testing I was about to do. |
| 11:15 |
csharp_ |
@decide breick or berick |
| 11:15 |
pinesol |
csharp_: go with berick |
| 11:15 |
csharp_ |
pinesol: good bot |
| 16:00 |
Bmagic |
JBoyer: right, I submitted a patch to that query (in the IDL) - that produces duplicate rows on it's own when patrons have more then one non-CAPTURE-blocking penatly. But now, I've encountered the same bug but for a different reason. That query gets wrapped inside of another one with all those LEFT JOINS |
| 16:02 |
JBoyer |
Ah, ok. I may not have read close enough to tell where you were running into trouble. |
| 16:14 |
berick |
grabbing 1313 |
| 16:20 |
pinesol |
News from commits: LP1956003 Stamping DB upgrade / hold group grids <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=91fa2ee5f2ad75a5ad480d92c74fe91f3ddfbbeb> |
| 16:20 |
pinesol |
News from commits: LP1956003 Hold Group Workstation Settings to Server Settings. <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=4d667aa09ff61496c9f60a0cfae34c13566a5a61> |
| 16:20 |
pinesol |
News from commits: LP1960956 Stamping DB upgrade / usr message index (fix) <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=64803ff1fbca0fc24d649eb10b31cf7f26a19019> |
| 16:20 |
pinesol |
News from commits: LP1922975 Build scripts python3 minor fixes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=9ab97eb8d80d4f1d5852ea30ee64dbffc32766e1> |
| 16:20 |
pinesol |
News from commits: LP#1922975: install python3 dependencies, rather than python2 <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=e4a07d8f825c986774a11bf52a7d20a23062163e> |
| 16:20 |
pinesol |
News from commits: LP#1922975: update i18n scripts for Python 3 <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=b49185fd713b3ea27a023cf30f0b1fc4d1940f71> |
| 16:50 |
pinesol |
News from commits: LP1846552 Shelving location Order handle new locations <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=48771af5ae7d6292eef763f9a5677acc93ecacc9> |
| 16:50 |
pinesol |
News from commits: LP1846552 Shelving Location Order Angular UI <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=6516659d05dc80d3169462ee91a62e5cfd134292> |
| 16:50 |
pinesol |
News from commits: LP1965161: Sort Monograph Parts in Holds Metadata <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=f61f1e147b1d4ed288554c88ff72d040c924a0f1> |
| 17:17 |
|
mmorgan left #evergreen |
| 17:20 |
pinesol |
News from commits: LP1847827 - Evergreen Web Based Self Check - Use prefered first name in header. <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=fddcefb2fb0db58ff5357f205034bc62f20dbac8> |
| 17:25 |
|
jvwoolf left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:20 |
pinesol |
News from commits: LP1863196-Add series title to holds pull list. <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=93646c82129e6399251f7c9d795877cf86b0bb55> |
| 22:28 |
|
JBoyer joined #evergreen |
| 00:37 |
|
Keith_isl joined #evergreen |
| 02:20 |
|
JBoyer joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:05 |
JBoyer |
Bmagic, that almost sounds like lp 1847805, with pcrud grabbing as many rows as you ask for then removing the ones you're not allowed to see, leaving you with less than you expected. |
| 07:05 |
pinesol |
Launchpad bug 1847805 in Evergreen "pcrud search can fail to retrieve rows that the user has access to" [High,Confirmed] https://launchpad.net/bugs/1847805 |
| 07:12 |
|
rjackson_isl_hom joined #evergreen |
| 17:05 |
|
jihpringle joined #evergreen |
| 17:07 |
|
jvwoolf left #evergreen |
| 17:11 |
Bmagic |
I just noticed something about this pull list issue. In the examples where it's broken, I'm not getting the dropdown menu for the pickup library, even though I'm global admin, plus, the loading bar just bounces left to right, no percentage, like I see on other examples..... |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:22 |
|
jihpringle joined #evergreen |
| 20:16 |
|
JBoyer joined #evergreen |
| 00:05 |
|
Keith-isl joined #evergreen |
| 00:06 |
|
Keith_isl joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:17 |
|
rjackson_isl_hom joined #evergreen |
| 08:07 |
|
rfrasur joined #evergreen |
| 08:14 |
|
mantis1 joined #evergreen |
| 09:42 |
Dyrcona |
The coffee database is probably not accessible. |
| 09:44 |
|
jvwoolf joined #evergreen |
| 09:47 |
|
JBoyer joined #evergreen |
| 10:32 |
jvwoolf |
Good morning. Over the weekend, we tried running action_trigger.purge_events() on our production database for the first time. We ran SELECT action_trigger.purge_events() ; in pqsl rather than using the srfsh script. I tested it on test database with production data and it only took 15 - 20 minutes to run. This weekend, it ran for over 3 hours in production with all application servers disabled and cron jobs turned off. We had to st |
| 10:32 |
jvwoolf |
it because we didn't plan for that much down time. Any ideas why the discrapancy the test runs and the production run? |
| 10:38 |
miker |
jvwoolf: if the test db was a dump/reload of production, it'll likely be because of table bloat and/or bad stats. I'd recommend a vacuum analyze to start |
| 10:39 |
jvwoolf |
miker++ |
| 10:59 |
Dyrcona |
jvwoolf: It should be OK to run the purge while Evergreen is running. We run it daily at 5:30 AM. We keep 6 months of events. |
| 11:16 |
jvwoolf |
Dyrcona: We actually did restart it after it failed, but it didn't seem to be doing anything. |
| 16:55 |
|
rfrasur joined #evergreen |
| 16:57 |
mmorgan |
Bmagic: Which release of evergreen? |
| 16:58 |
Bmagic |
3.7.2 |
| 16:58 |
Bmagic |
I just tried it on 3.7.1 and it wasn't an issue, but the two tests aren't exactly identical |
| 17:00 |
mmorgan |
Bmagic: I'm not seeing that issue on 3.7.2. The pull list respects my chosen number of rows and has pagination. |
| 17:00 |
Bmagic |
mmorgan++ # thanks for checking, must be a local issue |
| 17:02 |
Bmagic |
The behavior I'm seeing is: Let's say there are 100 holds. And you choose 10 rows. It will give you 5, no pagination. If you choose 25 rows, it will give you 20, no pagination. It's like it's croaking on a hold somewhere and giving you what it came up with so far |
| 17:08 |
mmorgan |
Could it be one of those holds that got broken? Like a part or metabib hold where it's target went away? |
| 17:09 |
Bmagic |
I was chasing that idea down, but the logs don't have that issue. It's like the DB is only giving the results for the JSON query, just like it's asking for "limit: 5" |
| 17:12 |
Bmagic |
But the DB is not even coming up with 5. It's like 2. But if the limit were higher, like 25, then the DB returns 20 (for example). And I know there are well over 100. If I set it to 100, I get 89 rows. I'm still running different tests. No worries. I'll reply if I get stuck again, maybe with more info |
| 17:25 |
Bmagic |
perhaps this is a problem? https://pastebin.com/PWWN5AbR |
| 17:36 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live//archive/2022-03/2022-03-14_16:00:02/test.29.html> |
| 18:17 |
|
jihpringle joined #evergreen |
| 18:48 |
|
jihpringle joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rfrasur joined #evergreen |
| 07:03 |
|
rjackson_isl_hom joined #evergreen |
| 07:04 |
|
JBoyer joined #evergreen |
| 12:45 |
* miker |
looks |
| 12:47 |
miker |
Dyrcona: see line ~87 of OpenILS/WWW/EGCatLoader/Util.pm (master-ish) |
| 12:48 |
miker |
that's search, but see OpenILS/SIP/Patron.pm around line 104 for a retrieve example |
| 12:52 |
Dyrcona |
miker: Thanks. You just saying that rings a bell. But I'm almost ready to test my script. |
| 12:57 |
Dyrcona |
Funny thing. I recently wrote a cstoreeditor search with idlist=>1, and I got an error when I wrapped the params in an arrayref. It worked without it, though. I think it depends on what you're doing. |
| 13:08 |
Dyrcona |
It's all an approximation, anyway. :) |
| 13:30 |
|
jihpringle joined #evergreen |
| 15:29 |
Dyrcona |
If you build the db ins some other way then you're on your own. :) |
| 15:29 |
Bmagic |
ok, I think it's a patch I've merged |
| 15:31 |
Bmagic |
thanks for helping me talk through it. The issue ended up being something different (once I manually set the :eg_version variable) and got passed that, the real issue is at the bottom, where a patch is creating two new tables in the config schema... but it's REFERENCEing a table that doesn't exist (yet) |
| 15:32 |
Dyrcona |
Bmagic: What patch are you testing? |
| 15:32 |
Bmagic |
bug 1786524 |
| 15:32 |
pinesol |
Launchpad bug 1786524 in Evergreen "Add a support script for importing patrons" [Wishlist,New] https://launchpad.net/bugs/1786524 |
| 15:32 |
Bmagic |
I'm about to fix it and supply the commit |
| 17:01 |
|
mmorgan left #evergreen |
| 17:09 |
|
jvwoolf left #evergreen |
| 17:45 |
|
book` joined #evergreen |
| 18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:28 |
|
rjackson_isl_hom joined #evergreen |
| 07:50 |
|
collum joined #evergreen |
| 08:25 |
|
rfrasur joined #evergreen |
| 11:42 |
|
Christineb joined #evergreen |
| 11:51 |
miker |
@later tell Dyrcona no, currently not possible to say "ORDERY BY ... NULLS LAST" but ... it would be nearly trivial to add a peer to "direction" called, say, "nulls" that checks for "first" or "last" values and does that |
| 11:51 |
pinesol |
miker: The operation succeeded. |
| 12:05 |
mmorgan |
phasefx: re: cover image uploader discussion yesterday. Here's a public link to some images: |
| 12:06 |
mmorgan |
https://drive.google.com/drive/folders/1_SrHH7GZPVwdhCZLquVmn9cw3q3saxco?usp=sharing |
| 12:06 |
mmorgan |
On my test system, of the six files, beebe and the two starting with test all work, cones and the two starting with LOT fail. |
| 12:28 |
|
Lew70 joined #evergreen |
| 12:36 |
|
jvwoolf left #evergreen |
| 12:44 |
|
rjackson_isl_hom joined #evergreen |
| 14:41 |
Keith-isl |
I always just assumed Hatch provided some level of protection against staff blowing away workstations by clearing the entire cache. |
| 14:42 |
jeff |
but you may still have to go out of your way to make it work. I think the hatch.properties file TRIES to store settings in %ProgramData%\Hatch by default, but I know at one point the permissions on that file weren't correct, and the hardcoded default was to store in the user profile. |
| 14:43 |
Keith-isl |
+++ I have learned much this day. Thank you! |
| 14:44 |
jeff |
Also, something you'll run into in a mixed Chrome OS / Chrome on other operating systems environment: if your users have the Hatch browser plugin installed and enabled, trying to log in to Evergreen on Chrome OS (where Hatch the Java app is not installed) will likely fail / lead to partially-loaded staff interfaces with Hatch-related errors in the browser console. |
| 14:44 |
jeff |
I think (but can't recall if we've tested) that the Hatch extension being installed/enabled is something that syncs by default when you're logged into Chrome with sync enabled. |
| 14:45 |
Keith-isl |
Oh yeah, we've definitely run across that before with new Windows machines and users logging into Chrome accounts before installing the Hatch Windows app. >< |
| 14:45 |
jeff |
The long term solution there is to have the Hatch browser extension fail more gracefully when Hatch the Java app isn't available. |
| 14:49 |
Keith-isl |
Yeah, that would be ideal - the Hatch extension breaking things if it can't communicate with the Java app has been a source of many tickets. |
| 16:56 |
mmorgan |
:) |
| 16:56 |
Keith-isl |
"I'm telling you, TTOOPAC is still alive out there." |
| 17:02 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:29 |
|
jihpringle joined #evergreen |
| 20:49 |
|
JBoyer joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:18 |
|
rjackson_isl_hom joined #evergreen |
| 08:06 |
|
rfrasur joined #evergreen |
| 08:41 |
|
mantis1 joined #evergreen |
| 09:08 |
|
Keith-isl joined #evergreen |
| 09:34 |
|
jvwoolf joined #evergreen |
| 09:41 |
|
BAMkubasa joined #evergreen |
| 09:44 |
BAMkubasa |
I'm trying to play around with AuthorizeNet for the first time and in Evergreen one of the settings is "AuthorizeNet server" which I'm not seeing referenced in their testing guide. I do see something for the api test, but that doesn't seem to be what I'm looking for. Can any of you have a look in your history for the "AuthorizeNet server" setting |
| 09:44 |
BAMkubasa |
and see what you were using when you were testing the initial connection? |
| 09:51 |
Dyrcona |
BAMkubasa: Six years ago, we had "test.authorize.net". It may have changed. We've switched credit card processors twice since then. |
| 09:51 |
Dyrcona |
Or, maybe only once. Authorizent may have been #2. |
| 09:52 |
rfrasur |
Whilst there are attendant eyes. Anyone know what "pre-fetch all holds" does? I've checked the docs and did a little launchpad search, but not finding anything. (might need to go way back in the docs though) |
| 09:56 |
Dyrcona |
rfrasur: Not off the top of my head. |
| 15:15 |
csharp_ |
unless this is on a low-traffic server |
| 15:15 |
* phasefx |
can't tell you how many times leaving the log details up has caused him to run out of disk space :) |
| 15:16 |
csharp_ |
oh yea |
| 15:16 |
mmorgan |
test server, so should be ok :) |
| 15:16 |
mmorgan |
Thanks for the tips! |
| 15:16 |
JBoyer |
mmorgan++ |
| 15:16 |
JBoyer |
phasefx++ |
| 15:17 |
JBoyer |
csharp_++ |
| 15:21 |
jeffdavis |
I don't think it should block the new feature from being committed or anything, just something to look out for once the feature goes in |
| 15:21 |
* mmorgan |
also has one more comment |
| 15:21 |
phasefx |
but the problem space should be explored already for a given installation with regards to reports |
| 15:22 |
mmorgan |
On my test server, I had to create the directories for the cover images, so thought mention of that should go in release notes. |
| 15:22 |
JBoyer |
Yeah, that's worth documenting since I think this is the one use of shared space that could cause patron-facing problems. (Though I don't know what happens if the existing custom covers stuff isn't repsonding) |
| 15:23 |
jeffdavis |
anyway I'll test more and file a bug when I can |
| 15:24 |
phasefx |
jeffdavis++ |
| 15:24 |
mmorgan |
jeffdavis++ |
| 15:24 |
JBoyer |
mmorgan, I forgot the vandelay settings had an effect here, make sure that your importer directory isn't /tmp, because that doesn't work on more recent Ubuntu and Debian releases. |
| 16:06 |
jeff |
it was clearly not something that they had meant to intercept HP ePrint print jobs, and was quite amusing to picture "clicking" on a link on the printed page, etc... anyway, the "Get support or give us feedback." link was similarly useless. :-) |
| 16:06 |
jeff |
"Thank you for keeping HP information safe!" |
| 17:12 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:41 |
|
ejk joined #evergreen |
| 18:41 |
|
jeffdavis joined #evergreen |
| 18:41 |
|
eby joined #evergreen |
| 05:37 |
|
JBoyer joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:41 |
|
collum joined #evergreen |
| 07:50 |
|
mantis joined #evergreen |
| 08:33 |
|
mmorgan joined #evergreen |
| 10:34 |
* Dyrcona |
ponders fixing the 856 by moving subfield 3 in front of the others instead of being at the end. |
| 11:16 |
mantis |
Weird thing. I noticed when using Angular, I get a weird rollover effect when trying to place an Item Hold that prevents me from clicking the option in Chrome. But in Firefox it's fine. Has anyone else noticed this? |
| 11:26 |
Dyrcona |
Hrm.. "Not an array reference..." |
| 11:37 |
Dyrcona |
mantis: I haven't seen that, but I hardly ever use the staff client, only when testing something specific. |
| 11:48 |
mmorgan1 |
mantis: I'm not seeing the same thing. Are you looking at the full record in the staff catalog? |
| 11:53 |
jeff |
mantis: I'm pretty sure it's a Chrome bug. We just had a report of exactly that today. |
| 11:54 |
jeff |
Chrome 99 on Windows exhibits the problem. Chrome 98 on macOS does not. |
| 11:54 |
jeff |
I haven't found a Chrome bug/issue for it yet. |
| 11:55 |
jeff |
one quick workaround for placing an item/copy level hold from that point is to select the "view" option to bring the copy up in Item Status, and then use the "Request" feature to place the copy hold. |
| 11:56 |
jeff |
(not a suitable workaround in all scenarios, but useful in many) |
| 12:03 |
jeff |
none of the current Chrome release channels on macOS include Chrome 99.x. I suspect it's currently on a phased release as the main channel. |
| 12:04 |
jeff |
I'm going to test more on Windows, to see if it's OS specific or just Chrome 99. |
| 12:14 |
|
jihpringle joined #evergreen |
| 12:17 |
jeff |
hah! vendor stated that they had a document that went into detail about how their product uses SIP2. We asked for a copy, they sent us the 2006 3M SIP 2.0 protocol specification document. |
| 12:19 |
mantis |
jeff++ |
| 12:19 |
JBoyer |
jeff, hah, reminds me of those self-certifying sip implementations. "What parts of the standard do you support?" "Oh, all of them. (As far as you or we know.)" |
| 12:29 |
jeff |
When talking (or joking) about idiosyncrasies of the SIP2 protocol, I can never decide if I want to go the Emo Philips route or the Monty Python route. |
| 15:06 |
pinesol |
Launchpad bug 1910452 in Evergreen 3.6 "Angular Catalog: Search links and Added Content" [Undecided,Fix released] https://launchpad.net/bugs/1910452 |
| 15:07 |
jihpringle |
mmorgan: we're on 3.7.0 so the links in Patron View don't work for us and placing holds via the traditional catalogue always uses the staff account contact details |
| 15:09 |
jihpringle |
I'm really looking forward to our next upgrade when we get all the awesome catalogue fixes that came in 3.7.2 |
| 15:13 |
mmorgan |
jihpringle: Oh right! We've also applied bug 1939426, which grabs the user prefs. Haven't tested it rigorously enough to sign off yet, though. |
| 15:13 |
pinesol |
Launchpad bug 1939426 in Evergreen "Placing holds as staff in traditional catalog in 3.7 doesn't always load user settings" [Undecided,Confirmed] https://launchpad.net/bugs/1939426 |
| 15:15 |
Dyrcona |
mmorgan: Are you using it in production? |
| 15:17 |
Dyrcona |
If you've been using a patch in production for a while and no one has complained, that's pretty thorough testing. :) |
| 15:17 |
mmorgan |
Dyrcona: We are, but we are still having some issues with the screen. |
| 15:18 |
mmorgan |
Agreed, putting in production = thorough testing :) |
| 15:21 |
* mmorgan |
will take another look and try and add a signoff this afternoon. |
| 16:13 |
jeff |
in Chrome 99, offsetWidth and offsetHeight on the eg-grid-body-cell element returns 0. |
| 16:13 |
jeff |
(but only in that one column -- "Holdable?") |
| 16:46 |
jeff |
looks like placing <div>hello<//div> in an <ev-grid-body-cell> causes the eg-grid-body-cell to have offsetHeight 0 |
| 17:17 |
jeff |
confirmed Version 99.0.4844.51 (Official Build) (arm64) |
| 17:17 |
jeff |
(as affected) |
| 17:18 |
jeff |
on macOS |
| 18:00 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live//archive/2022-03/2022-03-04_16:00:02/test.29.html> |
| 22:22 |
|
JBoyer joined #evergreen |
| 02:24 |
|
JBoyer joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:13 |
|
rjackson_isl_hom joined #evergreen |
| 07:49 |
|
collum joined #evergreen |
| 08:01 |
|
rjackson_isl_hom joined #evergreen |
| 12:58 |
Dyrcona |
Also, I had to rm <other file>.orig 'cause I forgot to say no backups to patch. |
| 12:59 |
Dyrcona |
Admittedly, it's of limited utility, but I have a use case where file b started as a copy of file a. I made an edit to file b that I wanted to put in file a, and I was feeling lazy and figured that git diff trick would work, so I tried it. |
| 13:01 |
* jeff |
nods |
| 13:02 |
Dyrcona |
Also, I'm tempted to put in another patch that I tested. I hesitate because it accesses a Perl object's internals, and it could break in a future release of the Perl package, though I doubt it. |
| 13:06 |
Dyrcona |
@praise Encapsulation |
| 13:06 |
* pinesol |
Encapsulation LOVES the RESISTANCE! |
| 13:31 |
dluch |
Reminder: DIG Meeting starts in 30 minutes! |
| 14:37 |
abneiman |
the process I followed is from Jane & I think it's documented though |
| 14:37 |
mantis |
should we reply to announcement emails with branches ready to go prior to the meeting? |
| 14:37 |
dluch |
csharp, thanks! |
| 14:38 |
abneiman |
well, I thought we were going to try to pivot to github commits (I do git command line right now) so we can take advantage of the new build-testing plugin |
| 14:38 |
abneiman |
that's what I'm supposed to teach myself this month before I talk to y'all about it in April :) |
| 14:38 |
dluch |
Correct (I think) |
| 14:38 |
dluch |
:-) |
| 14:39 |
mantis |
I see |
| 15:58 |
Dyrcona |
Anyone know off the top their head what happens if you check in a claims returned item? |
| 16:11 |
jihpringle |
I think it depends on your library settings |
| 16:12 |
Dyrcona |
<John_Cleese>Naturellement.</John_Cleese> |
| 16:12 |
* Dyrcona |
thinks he'll just try it on a test database next week and see what happens. :) |
| 16:13 |
Dyrcona |
jihpringle++ |
| 16:15 |
Dyrcona |
I'm likely to be asked to checkin and delete a bunch of old clams returned items. |
| 16:15 |
jihpringle |
Dyrcona: the item gets checked in (with an item alert to tell you it was claimed returned) and goes to reshelving and then bills may be voided depending on your library settings (at least that's what happens on our test server) |
| 16:15 |
Dyrcona |
Maybe I should share this program. I have one that will checkin and delete copies from a spreadsheet. |
| 16:16 |
Dyrcona |
jihpringle: Thanks for looking. |
| 16:16 |
Dyrcona |
I suspect it might do the same here. |
| 16:19 |
Dyrcona |
My suspicion is it will work on claims returned just as well as it works on lost, long overdue, and missing. |
| 16:24 |
Dyrcona |
Well, it's about that time. I'll catch everyone again tomorrow! |
| 17:05 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:47 |
|
jvwoolf joined #evergreen |
| 20:01 |
|
jvwoolf left #evergreen |
| 20:28 |
|
Guest30 joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:15 |
|
JBoyer joined #evergreen |
| 07:14 |
|
rjackson_isl_hom joined #evergreen |
| 07:40 |
|
collum joined #evergreen |
| 11:08 |
miker |
hrm... that's strange ... could the records be claiming MARC8? IIRC we do look at the leader, but I think there's a way to force the issue |
| 11:09 |
Dyrcona |
Ah, wait a minute. The records don't seem to say that they're UTF-8.... |
| 11:09 |
Dyrcona |
vendor-records-- |
| 11:10 |
Dyrcona |
I'll have to test this... again.... I have a prep script that can set the encoding, I saw 'a' in the leader and thought I didn't have to, but after counting, that 'a' isn't the 'a' that I want. :) |
| 11:14 |
Dyrcona |
I'm going to see what these problem records look like in the database before I do anything else. |
| 11:16 |
Dyrcona |
One of them has different characters for the first letter of the author's last name in different fields. It's \xC3\x85 in one field and \xC3\x81 in another.... |
| 11:18 |
Dyrcona |
245$c on that record is empty in the database, but has the author's name in the input. It's the one with \xC3\x85. |
| 11:35 |
Dyrcona |
I've found all kinds of crap in MARC from 3rd parties. |
| 11:36 |
miker |
right on. fwiw, many of our scripts and db functions use both assume_unicode(1) and ignore_errors(1). see the top part of Open-ILS/src/extras/import/marc_add_ids for instance |
| 11:38 |
Dyrcona |
Well, I've set the 09 in the leader to 'a' for this batch. When I open the file in Emacs it looks like UTF-8. |
| 11:39 |
Dyrcona |
I'm running it again in another db with a fresh copy of production. I reloaded them after yesterday's tests. |
| 11:40 |
jeff |
the last time I looked at pymarc was years ago, and I thought that there were a few broken things about it, especially with regard to encoding. |
| 11:40 |
Dyrcona |
jeff: I don't recall if I actually used it. I may just perused the repo or something like that. |
| 11:41 |
jeff |
It may have gotten better since then, or I may have been mistaken. I only remember that I had issues with a large set of changes that had recently gone into it, but don't recall more than that offhand. |
| 11:59 |
Dyrcona |
Yeah, it has passed the author with the different characters for the first letter of the last name with no warnings or errors. |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:12 |
Dyrcona |
Well, there's "stuff" in the author's name in the database. I'm not sure it's correct. |
| 12:28 |
Dyrcona |
Looks good in my test catalog, so... I guess I'll load these into production. |
| 12:29 |
Dyrcona |
multiple-test-environments++ |
| 13:07 |
mantis |
Does anyone have suggestions for software that locks browsers into a kiosk mode for OPAC use? We used OpenKiosk for a while but it's causing a lot of white screening and timeouts on Linux OS. |
| 13:28 |
berick |
mantis: have you tried the kiosk mode options baked into most browsers? |
| 13:31 |
jeff |
I've heard good things about webconverger in the past, but it seems that they haven't updated in a while. We used to use OpenKiosk, but now I think we use Chrome/Chromium with a browser plugin called from a pruned-down xinitrc or the equivalent on some little linux boxes. |
| 13:32 |
jeff |
Biggest issue (other than it being somewhat cobbled together) is that the image doesn't do much to avoid writes, so the microSD cards tend to wear out often. |
| 13:33 |
jeff |
I don't think Chrome, Edge, or Firefox have stock "kiosk" mode options that would be suitable for an OPAC. Chrome OS does have a kiosk mode that you might look into, though. |
| 13:33 |
jeff |
It will likely require a management license for the Chrome OS device. |
| 13:45 |
mantis |
berick++ |
| 13:45 |
mantis |
jeff++ |
| 13:45 |
mantis |
thanks for the suggestions; I'm mostly speaking on behalf of our network services |
| 13:45 |
mantis |
I think they did try at one point using the Kiosk setting in Firefox but they liked OpenKiosk because it really locks the browser down |
| 13:46 |
mantis |
unrelated but where in the Boopac is the search courses module? This is my first time testing it |
| 13:49 |
Dyrcona |
So, why does "identical" css produce different results on different servers in the same browser? I seem to have a discrepancy between my devleopment VM and my training server, and git tells me the relevant files are the same.... |
| 13:51 |
|
JBoyer joined #evergreen |
| 13:53 |
Dyrcona |
I even emptied cache and hard reloaded..... |
| 16:47 |
Dyrcona |
JBoyer++ |
| 16:47 |
Dyrcona |
Yeah, that's what a narrows is. |
| 16:47 |
Dyrcona |
narrows are? is? I'm not gonna bother looking it up. |
| 16:58 |
pinesol |
News from commits: LP#1955931 Staff catalog show more details - add due date <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=4e6fe743271992347686a113c390b208c162942b> |
| 17:07 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:19 |
|
Christineb joined #evergreen |
| 18:39 |
|
jihpringle joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live//archive/2022-03/2022-03-01_04:00:02/test.42.html> |
| 07:13 |
|
rjackson_isl_hom joined #evergreen |
| 07:16 |
|
collum joined #evergreen |
| 08:00 |
|
mantis joined #evergreen |
| 08:01 |
JBoyer |
^ A test about spaces around values was *also* testing whether or not URIs were deleted when records are changed. We don't do that anymore, and now the test is updated. |
| 08:23 |
pinesol |
News from commits: Update Test for LP1722827 After LP1482757 <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=e9c6750312c9c1ba001119e918ac84f4bcd017a6> |
| 08:33 |
|
mmorgan joined #evergreen |
| 08:40 |
csharp_ |
JBoyer++ |
| 08:40 |
|
jvwoolf joined #evergreen |
| 11:33 |
pinesol |
Dyrcona: Your current monologue is at least 45 lines long. |
| 11:34 |
Dyrcona |
Thanks, ducky! |
| 11:34 |
Dyrcona |
I should check the load script. Not sure it does anyone encoding. |
| 11:38 |
Dyrcona |
Also, TRAMP++ EMACS++ # I edited the file on the remote test server, committed it to the repo on that test server, then pushed it to the main repo, all using Emacs running on my laptop.... BTW, I know you can do that in vim, but most vim users don't know that. :) |
| 11:41 |
Dyrcona |
It would be nice if there was an easy way in git to apply a commit to a different, almost identical file. There probably is, and I just don't have the magic sauce. |
| 11:41 |
Dyrcona |
@monologue |
| 11:41 |
pinesol |
Dyrcona: Your current monologue is at least 50 lines long. |
| 17:04 |
|
mmorgan1 left #evergreen |
| 17:18 |
|
jvwoolf left #evergreen |
| 17:48 |
|
Keith_isl joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:25 |
|
jihpringle joined #evergreen |
| 20:25 |
|
JBoyer joined #evergreen |
| 21:11 |
|
Keith-isl joined #evergreen |
