| 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 |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:52 |
|
rjackson_isl_hom joined #evergreen |
| 08:30 |
|
Dyrcona joined #evergreen |
| 08:32 |
|
mmorgan joined #evergreen |
| 09:37 |
Dyrcona |
JBoyer: I think we do, so I'll check that. Thanks for the suggestion. |
| 09:47 |
jeff |
chopPunctuation, chopPunctuation, chopPunctuation... heh. |
| 09:49 |
Dyrcona |
Yeah, I haven't looked but I suspect a busted field in the MARC. Maybe i should dump it now before someone changes it. |
| 09:54 |
jvwoolf |
Dyrcona: Before I forget again, I wanted to say that we tested the patch in 1482757 and it worked fine. We've got it running in production now. |
| 09:54 |
jvwoolf |
Let's see if I can get that to link correctly - lp1482757 |
| 09:54 |
Dyrcona |
Lp 1482757 |
| 09:54 |
pinesol |
Launchpad bug 1482757 in Evergreen "Loading records with located URIs should not delete and recreate call_numbers" [Low,Confirmed] https://launchpad.net/bugs/1482757 |
| 09:54 |
jvwoolf |
Dyrcona++ |
| 16:17 |
Dyrcona |
"Paprika! That will fix it." |
| 16:18 |
Dyrcona |
I just have to figure out why the proper logo isn't showing up, and why it still looks like it is in the navbar. I think that latter is a style issu. |
| 16:22 |
Dyrcona |
Guess I'll squash these little fixes out later... |
| 16:27 |
Dyrcona |
OK. I think I need to update the Apache configuration on my test vm to handle our library URLs correctly. |
| 16:27 |
Dyrcona |
But, that will have to wait for Monday. |
| 16:35 |
Dyrcona |
Have a good weekend, everyone! |
| 17:09 |
|
jihpringle joined #evergreen |
| 17:12 |
|
JBoyer joined #evergreen |
| 17:12 |
|
mmorgan left #evergreen |
| 17:49 |
|
jvwoolf left #evergreen |
| 18:02 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-25_16:00:02/test.42.html> |
| 01:22 |
|
Bmagic joined #evergreen |
| 01:38 |
|
Bmagic joined #evergreen |
| 01:38 |
|
dluch joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-22_04:00:02/test.39.html> |
| 07:16 |
|
rjackson_isl_hom joined #evergreen |
| 07:32 |
|
collum joined #evergreen |
| 08:26 |
|
rfrasur joined #evergreen |
| 08:34 |
|
jvwoolf joined #evergreen |
| 09:05 |
|
Dyrcona joined #evergreen |
| 09:07 |
|
Keith__isl joined #evergreen |
| 10:04 |
csharp_ |
somebody commit something to master so I can see whether the @rss version of commit announcement suffices for our purposes :-) |
| 10:06 |
csharp_ |
Dyrcona: I missed that you had included removing PG 9.6 on your branch - makes sense, but I wasn't seeing it before :-/ |
| 10:11 |
csharp_ |
Dyrcona: I'm interested in seeing that branch go in... to fully test it, would I want to run all the PGtap tests on PG 10-14? or is there another way? |
| 10:13 |
csharp_ |
(this is why I prefer more granular bugs/fixes, btw - not trying to be critical since you've done so much work though :-) ) |
| 10:28 |
Dyrcona |
csharp_: Commit the branch that updates the PostgreSQL prerequisite targets. That should test the rss feeds. :) |
| 10:29 |
Dyrcona |
My branch changes the default client to Pg 14, IIRC. I'm using it on almost all of my VMs with Pg 10 databases with no issues. |
| 10:30 |
Dyrcona |
As for more granular bug fixes, I mostly agree. I don't like the giant omnibus branches that sometimes appear. I also prefer more, smaller commits over larger commits that touch more lines/files. |
| 10:30 |
Dyrcona |
In the case of my branch, I think it's scope is fine. I don't see why removing Pg 9.6 and adding support for newer Pg version should be separate. |
| 10:32 |
csharp_ |
Dyrcona: makes sense - I wasn' |
| 10:32 |
csharp_ |
t speaking specifically about removal of 9.6 - it just looks like a whole lot to test at once :-) |
| 10:33 |
csharp_ |
but, I'm going for it, so we'll see :-) |
| 10:33 |
Dyrcona |
Nah, not so much. Just inst all Pg 10, if the tests pass, that's all you've really got to worry about. I say int he README that the other versions are not fully tested and may have performance issues. |
| 10:34 |
* Dyrcona |
wishes his fingers would cooperate. |
| 10:34 |
Dyrcona |
csharp_++ |
| 10:34 |
csharp_ |
ok, that's where I was starting anyway |
| 10:35 |
Dyrcona |
If you want to test a different Pg version, I'd recommend Pg 14. |
| 10:35 |
Dyrcona |
It has the most changes from Pg 9.6/10, and it is the latest. |
| 10:37 |
csharp_ |
will do |
| 10:40 |
Dyrcona |
I should use the other installations on my development db server more. I've mostly just been using Pg 10 lately. |
| 10:41 |
csharp_ |
Dyrcona: do you have the alternate versions running together on different ports? |
| 10:42 |
Dyrcona |
csharp_: Yes. When I want to test one version in particular, I'll swap out a configuration file with optimized parameters and reboot. |
| 10:42 |
Dyrcona |
If I'm not too fussed for performance, I'll just change the ports in my client config. |
| 12:00 |
|
jihpringle joined #evergreen |
| 12:04 |
csharp_ |
Dyrcona: I see this when running pg_prove on PG 10/master + your branch: https://pastebin.com/cYA4qzDW |
| 13:00 |
csharp_ |
Dyrcona: now I'm getting https://pastebin.com/LjE1DtxJ (I cherry-picked your latest commit on top and rebuild the DB) |
| 13:02 |
csharp_ |
s/rebuild/rebuilt/ |
| 13:02 |
csharp_ |
gonna step away for a few |
| 13:09 |
Dyrcona |
Another typo. I thought I tested these after making the changes.... |
| 13:10 |
Dyrcona |
Again, the db upgrade script is correct. Maybe I only ran the tests after running the db upgrade with the switch from namespace to local-name()? |
| 13:14 |
Dyrcona |
OK. This one looks like the last issue. I've poured over the diffs and don't see any other changed XPath that looks bad. |
| 13:16 |
Dyrcona |
Fortunately I put the XPath canges all in one commit. |
| 13:16 |
Dyrcona |
s/canges/changes/ |
| 13:16 |
Dyrcona |
typos-- |
| 13:19 |
Dyrcona |
csharp_: Same deal I pushed a new commit. |
| 13:22 |
* Dyrcona |
sighs. Some days are more typo-prone than others. |
| 14:41 |
csharp_ |
yay!: |
| 14:41 |
csharp_ |
Result: PASS |
| 14:41 |
csharp_ |
ok, now onto PG 14 |
| 15:01 |
csharp_ |
Dyrcona: ok, PG 14 pgtap tests pass too - is there anything else I should test? |
| 15:07 |
Dyrcona |
You could try the Perl tests. Do anything you'd normally do, like circulation or whatever. |
| 15:08 |
csharp_ |
10-4 |
| 16:07 |
Dyrcona |
So, I'm trying to figure out how the bootstrap OPAC knows to load main_logo.png. So far it just seems to be magic. My motivation is, I want to replace it with CWMARS' Logo, name home-logo.png. I'd rather not just replace main_logo.png, but I will if I have to. |
| 16:08 |
* csharp_ |
looks around for terranm but doesn't see her |
| 16:08 |
csharp_ |
she's our resident boostrap OPAC person :-) |
| 16:08 |
csharp_ |
@seen terranm |
| 16:08 |
pinesol |
csharp_: terranm was last seen in #evergreen 2 years, 23 weeks, 6 days, 4 hours, 39 minutes, and 31 seconds ago: <terranm> Bmagic++ for setting up bug squashing test server! https://docs.google.com/spreadsheets/d/1qYNGrJBt42_ArQzbwlcnKxS3TobDnmquSXZzopOkZh4/edit#gid=0 |
| 16:08 |
csharp_ |
huh I guess she's using a different nick lately :-/ |
| 16:10 |
Dyrcona |
My suspicion is it has something to do with glide.js, but my suspicions are frequently incorrect. |
| 16:11 |
csharp_ |
https://gapines.org/opac/images/main_logo.png - she must have figured out how to change it |
| 16:52 |
|
jvwoolf left #evergreen |
| 17:02 |
|
jihpringle joined #evergreen |
| 17:09 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-22_16:00:02/test.39.html> |
