| 06:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live//archive/2022-03/2022-03-31_04:00:03/test.49.html> |
| 07:20 |
|
collum joined #evergreen |
| 07:40 |
|
rjackson_isl_hom joined #evergreen |
| 07:56 |
|
rfrasur joined #evergreen |
| 09:27 |
Dyrcona |
mmorgan: Thanks. Is that even for older records that don't have a $q? |
| 09:29 |
mmorgan |
Dyrcona: For older records that have extra info included in $a along with the ISBN proper, the extra info *does* show in the BOOPAC. |
| 09:30 |
Dyrcona |
mmorgan: Thanks, again. I was just now trying to find such a record on our training server to check for myself. So far the one I've looked at has neither a $q nor extra info. |
| 09:31 |
* mmorgan |
mangles records on our test/training system when necessary :) |
| 09:31 |
Dyrcona |
yeah, I could do that, but thought I'd try finding one first. |
| 09:32 |
Dyrcona |
And, I found one with the extra info that shows up: Coelho's The Alchemist. |
| 09:33 |
Dyrcona |
Also, Coelho is in YA at some libraries? I never thought of his work as YA. |
| 14:24 |
Dyrcona |
mmorgan: Done! |
| 14:25 |
Dyrcona |
I seem to recall seeing a couple of other, older bugs in a similar state recently. Maybe I'll look for them next week. |
| 14:26 |
mmorgan |
Thanks! Confusion managed! |
| 14:30 |
Dyrcona |
What to call a second test VM for Ubuntu 22.04? I plan to name the first one "jammy," so the obvious name is taken. |
| 14:32 |
Dyrcona |
Ok, devjam it is. |
| 14:45 |
jvwoolf |
A few libraries reported being down just after noon. open-ils.actor drones were at 50%. Restarting services resolved it. Logs are not showing me anything that looks particularly out of the ordinary, as far as I can tell. Any ideas about troubleshooting this? |
| 14:46 |
Dyrcona |
jvwoolf: What do you mean by "down?" |
| 15:43 |
Dyrcona |
Not sure I was much help. I guess one other question is does this happen often at about the same time on the same day of the week? If so, that could be an indication that you're busier at those times and may need another brick. |
| 16:54 |
|
jvwoolf left #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live//archive/2022-03/2022-03-31_16:00:04/test.49.html> |
| 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 |
