| 06:00 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-15_04:00:02/test.39.html> |
| 08:00 |
|
collum joined #evergreen |
| 08:36 |
|
mantis1 joined #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 11:19 |
berick |
heh |
| 11:25 |
mmorgan |
csharp_++ |
| 11:26 |
mmorgan |
though my head is now spinning a bit :) |
| 11:37 |
Dyrcona |
csharp_: Part of the point of what I'm testing is to avoid cataloging staff from using MarcEdit to edit the 856s....They say it's the most time consuming step. |
| 11:37 |
Dyrcona |
Since I've got a Perl program to do that part, I may just add code to clean up certain junk characters. |
| 11:38 |
csharp_ |
good plan |
| 11:39 |
Dyrcona |
Yes, I've assigned myself to look at Bmagic's record loader, but don't think I'll use it for this process, just yet: Bug1947898 |
| 11:39 |
Bmagic |
Dyrcona++ |
| 11:39 |
Dyrcona |
Missed a space: Lp 1947898 |
| 11:39 |
pinesol |
Launchpad bug 1947898 in Evergreen "Enhanced MARC importer script electronic_marc_import.pl" [Wishlist,Confirmed] https://launchpad.net/bugs/1947898 - Assigned to Jason Stephenson (jstephenson) |
| 11:54 |
Dyrcona |
The reload finished in time for me to start another test run before lunch, so here goes. |
| 11:55 |
|
jihpringle joined #evergreen |
| 12:33 |
Dyrcona |
Yeah, after looking up the Windows-1252 character set, I'm pretty sure that what I'm seeing are the Euro symbol (0x80), double dagger (0x87), and right single quotation mark (0x92). |
| 12:34 |
Dyrcona |
There may be others, but I remember those three codes from the output. |
| 12:51 |
Dyrcona |
We're using Pg 10. Haven't noticed any real performance differences with Pg 9.6. |
| 12:51 |
Dyrcona |
At Pg 11, most things start getting faster, but others seem to get hit. |
| 12:52 |
Dyrcona |
We do a dump and restore at least whenever we get new hardware. |
| 12:52 |
Dyrcona |
I do them weekly to keep some test databases up to date. Anyway, getting off topic. |
| 12:54 |
Dyrcona |
Going back to my record load/character issues, the message isn't coming from MARC::Record, either. I've got a program to dump the 856s that uses the same code to read the records and it doesn't peep. |
| 12:56 |
Dyrcona |
I wonder if I can just convert the raw MARC data or if I need to do it field by field.... |
| 13:04 |
Dyrcona |
Now, it's just looking like some garbage and not necessarily Windows 1252... Probably a mix.... :( |
| 16:27 |
abowling |
Dyrcona++ |
| 16:28 |
Dyrcona |
I'm not sure if Elaine's comment regards the patch (it sounds like it), or if she's saying that she doesn't see the bug. |
| 16:29 |
Dyrcona |
I guess since I |
| 16:29 |
Dyrcona |
I'm having fun loading resources in a test database, I could check that one out, too... |
| 16:38 |
Dyrcona |
Alright, so, some of the records were not set to UTF-8 in the LDR, and I suspect that at least one of them was giving me this warning/error. |
| 16:39 |
abowling |
Dyrcona: thanks again! that fixed it. |
| 16:40 |
Dyrcona |
abowling: Cool. If you could update the Lp bug, that would be great. |
| 16:47 |
|
jvwoolf left #evergreen |
| 16:47 |
abowling |
Dyrcona: will do |
| 17:04 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-15_16:00:02/test.29.html> |
| 18:23 |
|
jeff joined #evergreen |
| 18:59 |
|
jonadab joined #evergreen |
| 00:52 |
|
troy joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-14_04:00:02/test.39.html> |
| 07:44 |
|
collum joined #evergreen |
| 08:17 |
|
Dyrcona joined #evergreen |
| 08:37 |
Dyrcona |
Another stuck search query running for 18 hours, well, two, but they look like the same search in the database. I guess the patron/staff tried it again when it didn't return any results. |
| 11:13 |
Dyrcona |
We had some libraries leave a few years ago. While looking into adding records for an e-resource vendor, I stumbled across asset.uri entries from this vendor for one of the libraries that left. |
| 11:15 |
Dyrcona |
I though we must have some 856s still in the database, but no. There are no links to asset.uri_call_number_map for these asset.uri entries, no asset.call_number entries, and I didn't find any metabib.real_full_rec entries when I did a tsquery on index_vector. |
| 11:15 |
Dyrcona |
Anyone else seen orphaned asset.uri entries before? |
| 11:16 |
Dyrcona |
I was able to just delete them from a test database. |
| 11:16 |
mmorgan |
bug 1482757 rears its ugly head :) |
| 11:16 |
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 |
| 11:18 |
Dyrcona |
Yeah, maybe, but this feels like a different bug. I'll have to reread that one to see if orphaned entries are mentioned. |
| 11:22 |
pinesol |
Launchpad bug 1482757 in Evergreen "Loading records with located URIs should not delete and recreate call_numbers" [Low,Confirmed] |
| 11:22 |
Dyrcona |
Intereestingly, I found 20,000+ entries in metabib.real_full_rec that reference this particular libary in the 856, but no subfield u, just 9, y and z. |
| 11:22 |
Dyrcona |
GIGO. |
| 11:23 |
Dyrcona |
mmorgan: Cool, I'll read the bug description again. IIRC, I already signed off on the branch, no? I don't think it made much difference in performance when I tested it. |
| 11:24 |
* mmorgan |
needs to refresh memory on that, too. We are running some version of that patch in production. |
| 11:25 |
mmorgan |
Not sure it makes much difference in performance, but does eliminate call number churn. |
| 11:34 |
Dyrcona |
Right. I think I'm just going to do a blanket search for orphaned asset.uri entries and delete them. |
| 12:35 |
Dyrcona |
Over 2/3 of our asset.call_number table is deleted = 't' rows. I didn't bother to count those with the ##URI## label. |
| 12:38 |
|
jihpringle joined #evergreen |
| 12:44 |
|
jihpringle68 joined #evergreen |
| 12:52 |
Dyrcona |
Maybe it's high time that patch went in. I signed off over a year ago, but that probably means it needs a rebase and to be tested again. |
| 12:58 |
jvwoolf |
Dyrcona: If you rebase it, I can test it on a 9.6 DB with production data |
| 12:58 |
jvwoolf |
We're only running Evergreen 3.6 though |
| 12:59 |
jvwoolf |
Also, I see that there's an upgrade query in here to get rid of the orphaned entries in asset.uri_call_number_map but nothing to get rid of the call numbers |
| 13:00 |
jvwoolf |
I think that probably needs to be addressed in the release notes at the very least. It's probably better handled outside the upgrade scripts since it would be deleting the majority of the asset.call_number table in our case. |
| 13:03 |
Dyrcona |
jvwoolf: You can't really get rid of the call number. They just get tagged deleted. Or, do you mean, that there should be something to set call numbers deleted, too? |
| 13:04 |
jvwoolf |
Dyrcona: I think for us, we're going to need to get rid of the call number or our reports for filtering on call number are going to stay broken |
| 13:04 |
jvwoolf |
So maybe we're a special case |
| 16:30 |
|
Keith-isl joined #evergreen |
| 16:51 |
|
jvwoolf left #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-14_16:00:02/test.39.html> |
| 09:09 |
|
jvwoolf joined #evergreen |
| 09:10 |
csharp_ |
yes, lesson is never upgrade anything ever for any reason whatsoever |
| 09:11 |
alynn26 |
csharp_++ |
| 09:11 |
Dyrcona |
Pretty much. At least not without testing it on more or less the same hardware, first. |
| 09:11 |
Dyrcona |
csharp_++ |
| 09:14 |
|
jvwoolf1 joined #evergreen |
| 09:16 |
csharp_ |
now fighting with fastcgi (I think) |
| 09:36 |
jeff |
I'm not even certain open-ils.auth is to blame, or the only service affected. It's just the first thing that a staff login page hits. :-) |
| 09:44 |
jeff |
oh, cute. yep, it was auth. found more clues in router syslog messages, found a misbehaving client. |
| 09:44 |
jeff |
still, the misbehavior could be symptom-not-cause, but worth pulling on this thread next. |
| 09:51 |
Dyrcona |
jeff: I'm taking bug 1959904 from you. I'm testing a potential fix today. |
| 09:51 |
pinesol |
Launchpad bug 1959904 in Evergreen "Angular Patron Search Can Freeze the Browser" [Undecided,Confirmed] https://launchpad.net/bugs/1959904 - Assigned to Jeff Godin (jgodin) |
| 09:52 |
jeff |
cool, i was working on that this morning but I'll stop. |
| 09:53 |
Dyrcona |
Well, I don't want to intrude, but we really want this fixed. :) |
| 16:07 |
|
pinesol joined #evergreen |
| 16:31 |
|
jihpringle joined #evergreen |
| 17:05 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-11_16:00:02/test.39.html> |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 08:28 |
|
mantis1 joined #evergreen |
| 08:31 |
|
rfrasur joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 13:03 |
Dyrcona |
miker: I haven't tried that search. |
| 13:03 |
miker |
looks like we should push the exact match construct down into the initial search structures. I wonder if my "make joins CTEs" patch helps here. I'll dig that up. |
| 13:08 |
Dyrcona |
Did they actually type "winter AND sports" in the search box? Do I understand that corectly? I did a keyword from advanced search with winter in one and sports in the other and it came back rather quickly. |
| 13:09 |
jeff |
I haven't specifically tested the "make joins CTEs" patch against postgresql < 12 and >= 12, but the change in CTE optimization fence behavior suggests that it might be a good idea (to test/compare). :-) |
| 13:09 |
Dyrcona |
Looks like they typed "winter" AND "sports" |
| 13:10 |
Dyrcona |
I hate when they try to outsmart the query engine. They usually do with bad consequences. :) |
| 13:11 |
Dyrcona |
Yeahp. The variation with the quotes takes longer/hangs. Hasn't been long enough to tell, but the quotes definitely take longer. |
| 16:02 |
|
jihpringle joined #evergreen |
| 17:03 |
|
jvwoolf left #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:19 |
|
rjackson_isl_hom joined #evergreen |
| 08:24 |
|
collum joined #evergreen |
| 08:27 |
|
rjackson_isl_hom joined #evergreen |
| 15:12 |
phasefx |
miker++ |
| 15:12 |
shulabear |
What are the duties of the release team? |
| 15:12 |
terranm |
miker++ |
| 15:13 |
miker |
shulabear: coordinating, prodding folks to test/signoff/commit, release building |
| 15:13 |
gmcharlt |
miker++ |
| 15:13 |
terranm |
I'm happy to be bug squash/feedback fest wrangler again |
| 15:13 |
phasefx |
I didn't help a lick with the last team I was on; I'm willing to, but may need some help/direction |
| 15:27 |
Dyrcona |
gmcharlt: Does it still use Dojo? |
| 15:27 |
gmcharlt |
Dyrcona: correct, that hasn't changed |
| 15:28 |
Dyrcona |
Do we have plans to replace it with something that doesn't use Dojo? |
| 15:29 |
JBoyer |
I assume the choicest signoffs will involve using an Overdrive testing account, which I ... have gotten in the past but no longer remember the level of hassle one is required to endure. Have you and jeffdavis verified the actual downloading bits so that "Doesn't break my system and looks sane" type signoffs are sufficient? |
| 15:29 |
gmcharlt |
JBoyer: yes, we've verified it w.r.t. to real OverDrive credentials |
| 15:29 |
JBoyer |
gmcharlt++ |
| 15:29 |
JBoyer |
jeffdavis++ |
| 15:29 |
Dyrcona |
JBoyer: Even if you have credentials the Overdrive test environment is a pain to use. |
| 15:30 |
|
jvwoolf1 joined #evergreen |
| 15:31 |
JBoyer |
Though to guess at the answer to your Q Dyrcona, I haven't seen specific mention of a major update to the feature that I can recall. Depending on what Dojo is doing it could be a major undertaking. |
| 15:31 |
JBoyer |
And I can't say I'm surprised that it's a hassle to work with their backend. I'm still salty about the time they took away ftp access to new records. |
| 15:39 |
terranm |
JBoyer++ |
| 17:06 |
|
mmorgan left #evergreen |
| 17:34 |
|
jvwoolf1 left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:12 |
|
jihpringle joined #evergreen |
| 21:52 |
pinesol |
[evergreen|gmontimantis] Docs: Updating Opac Lists doc - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ad42342> |
| 22:45 |
pinesol |
[evergreen|Lynn Floyd] Adding videos from Conferences - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bb054da> |
| 00:08 |
|
Kolvir joined #evergreen |
| 00:09 |
Kolvir |
Can I run the evergreen server and the client interface on a single system? |
| 00:22 |
jeff |
It can be done, especially for testing or development, but I wouldn't recommend it for "real" production use. |
| 00:26 |
Kolvir |
I'm going to be in charge of computerizing a small church library, completely paper based now, and am looking for a software package |
| 00:31 |
Kolvir |
There will only be one computer for patron use, and really doesn't need to be a separate one for admin, unless evergreen would require it. |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:16 |
|
rjackson_isl_hom joined #evergreen |
| 07:55 |
|
alynn26 joined #evergreen |
| 08:34 |
|
mantis1 joined #evergreen |
| 14:42 |
|
Christineb joined #evergreen |
| 16:44 |
|
jvwoolf left #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:40 |
|
jihpringle joined #evergreen |
| 00:53 |
|
akilsdonk joined #evergreen |
| 00:53 |
|
Bmagic joined #evergreen |
| 00:54 |
|
troy joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Failed Create Evergreen Database <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-02_04:00:02/test.41.html> |
| 08:25 |
|
mantis1 joined #evergreen |
| 08:32 |
|
mmorgan joined #evergreen |
| 08:36 |
|
rfrasur joined #evergreen |
| 13:39 |
jeff |
INSERT INTO permission.grp_tree_display_entry (id, parent, all_parents, depth) VALUES (1, 1, 1, 1, NULL), (2, 1, 1, 2, 3), (3, 1, 1, 3, 2); |
| 13:42 |
Dyrcona |
I can also just remove about 26 charactes from the code and this problem "goes away." :) |
| 13:42 |
Dyrcona |
Yeah, I should find the loop. |
| 13:42 |
jeff |
see if this finds anything? |
| 13:42 |
jeff |
with recursive tree as (select id,parent,array[id] as all_parents, 0::int as depth from permission.grp_tree_display_entry union all select c.id,c.parent,p.all_parents||c.id, p.depth+1 from permission.grp_tree_display_entry c join tree p on (c.parent = p.id) where depth < 1000) select * from tree WHERE depth > 999; |
| 13:43 |
jeff |
(modified miker's query, tested it on my little test case) |
| 13:44 |
Dyrcona |
jeff: Your query returns 0 rows on my data. I wonder if the problem is pgt? |
| 13:44 |
jeff |
wacky. |
| 13:45 |
Dyrcona |
We have multiple nodes with null parent in pgtde. |
| 17:02 |
Dyrcona |
Anyway, look at the time! |
| 17:13 |
mmorgan |
jeff++ |
| 17:17 |
|
mmorgan left #evergreen |
| 18:02 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-02_16:00:02/test.29.html> |
| 03:35 |
|
Christineb joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:32 |
|
rjackson_isl_hom joined #evergreen |
| 07:48 |
|
collum joined #evergreen |
| 08:28 |
|
mmorgan joined #evergreen |
| 12:21 |
jeff |
good to hear. |
| 12:21 |
csharp_ |
so maybe a good troubleshooting practice to do packet captures when facing anything like this? Jeff was suggesting that from the beginning\ |
| 12:22 |
jeff |
the patron update API call doesn't need several things that we currently send it. I think it's still a good idea to remove children on the org unit when locally fleshing it (the current branch in that bug), but I think there's also some things we should stop sending in the patron update call, and of course there's still the unresolved issue of "services shouldn't fall over in the face of this" |
| 12:25 |
Dyrcona |
jeff: I see something else (though not strictly related) in logs from a test VM that bug me along similar lines. Looks like 1 backend call leads to 200+ on our system when it could probably be a single JSON query. |
| 12:27 |
csharp_ |
jeff++ |
| 12:30 |
|
rjackson_isl_hom joined #evergreen |
| 12:30 |
jeff |
Dyrcona: yeah, that does sound bad. |
| 16:54 |
|
jvwoolf left #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 17:59 |
|
nfBurton joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live//archive/2022-01/2022-01-31_16:00:03/test.29.html> |
| 21:59 |
|
nfBurton joined #evergreen |
| 01:00 |
|
JBoyer_ joined #evergreen |
| 01:01 |
|
jweston_ joined #evergreen |
| 01:07 |
|
berick_ joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 08:04 |
|
rjackson_isl_hom joined #evergreen |
| 08:11 |
|
Keith-isl joined #evergreen |
| 08:33 |
|
mmorgan joined #evergreen |
| 09:37 |
csharp_ |
so awitter and jlamos analyzed the packet capture and saw TCP ZeroWindow errors - we've upped net.core.rmem.max by 25% on one of our servers as an experiment and will run tshark again |
| 09:50 |
|
alynn26 joined #evergreen |
| 10:02 |
|
jvwoolf joined #evergreen |
| 10:18 |
Dyrcona |
Grr. Not sure if code is broken or the test environment is too slow. I can see in the logs that my search returned results, but the Angular catalog screen results section is "blank." |
| 10:18 |
Dyrcona |
And, now, a result is there. Just slow, I guess. |
| 10:42 |
Dyrcona |
I can't figure out why the Angular staff catalog patron search freezes for us as soon as it opens. |
| 10:43 |
Dyrcona |
It freezes the browser tab, even the JS console is non-responsive. |
| 10:43 |
Dyrcona |
Nothing in the Evergreen logs looks suspicious. |
| 10:43 |
Dyrcona |
It's consistent on a test vm and on our training server with Chrome Version 97.0.4692.99 (Official Build) (64-bit) |
| 10:45 |
Dyrcona |
There's a Chrome process running at 100.7% CPU. |
| 10:47 |
Dyrcona |
If I kill that Chrome process, I get the "Aw, snap" screen. |
| 11:13 |
|
mantis1 joined #evergreen |
| 13:07 |
csharp_ |
theory is that something in the new user message stuff is bringing in all the fleshed orgs - but I need to go talk to some food about this |
| 13:12 |
Dyrcona |
Seems like a decent hypothesis. |
| 13:13 |
|
awitter joined #evergreen |
| 13:14 |
Dyrcona |
As for my problem, it doesn't happen on a clean vm with concerto data, so I'm leaning toward an issue with our data or some crud hanging around in the test environment. I am told the problem happens on 3.5 with the experimental catalog enalbed. |
| 13:24 |
jeff |
csharp_: remind me -- is this 3.7 or 3.8? |
| 13:24 |
jeff |
(3.8 with messages, I think, but I'm being lazy and asking instead of verifying.) |
| 13:36 |
csharp_ |
jeff: 3.8.0 |
| 16:42 |
Dyrcona |
:) |
| 16:46 |
|
BAMkubasa joined #evergreen |
| 16:46 |
BAMkubasa |
Do the things in eg/staff/circ/holds/shelf live in a specific database table or are they derived from data in other tables? |
| 16:49 |
* jeff |
tests a fix |
| 16:50 |
Dyrcona |
BAMkubasa: I think that data is derived from action.hold_request where the shelf_time is not null and the shelf_lib is equal to the current working location. |
| 16:52 |
BAMkubasa |
awesome |
| 16:52 |
BAMkubasa |
thanks. I just came across shelf_lib and was starting to poke around and see what it contained |
| 17:39 |
|
mmorgan left #evergreen |
| 17:42 |
|
alynn26_ joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:01 |
jeff |
csharp_: one option to fix -- worked in quick testing here: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=1d6f2b25a7436060b20326e2b41b3b8ef4c306b0 |
| 18:01 |
jeff |
also, lp 1959461 |
| 18:01 |
pinesol |
Launchpad bug 1959461 in Evergreen "Fleshing org unit on standing penalties should omit org unit children" [Undecided,New] https://launchpad.net/bugs/1959461 - Assigned to Jeff Godin (jgodin) |
| 18:02 |
jeff |
we might not even need to send standing_penalties on the user object when saving, but we probably shouldn't flesh the children either. |
| 18:03 |
jeff |
(and we should more gracefully handle the large object being present, lest we have DoS issues) |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:06 |
|
JBoyer_ joined #evergreen |
| 07:38 |
|
rjackson_isl_hom joined #evergreen |
| 07:49 |
|
collum joined #evergreen |
| 16:55 |
terranm |
jihpringle: in the actual record - lemme look at in the search results... |
| 16:56 |
terranm |
eby: I'm not a guru, but feel free to ask! |
| 16:56 |
mmorgan |
eby: Can't claim guru status, but ... What terranm said!! |
| 16:56 |
jihpringle |
I just tried on our 3.8 test server and I'm not seeing the preferred library item details showing in the grid on the search results screen (just in the counts) |
| 16:57 |
Dyrcona |
I'll have to look at this more tomorrow, but I think my problem is cstore timeouts talking to the database. |
| 16:57 |
eby |
So say have a staff with cancel hold permission at system level. When they go to cancel a hold on another account is that system looking at the patron home library, where the hold is placed or going to or ...? |
| 16:58 |
terranm |
jihpringle: I'm seeing the same thing. The only thing I see for the preferred library is the hold count. |
| 17:02 |
mmorgan |
eby: We haven't come across this, we have UPDATE_HOLD at the consortium level. |
| 17:04 |
terranm |
eby: same here - we have ours set at the consortium level, so we haven't looked into that. I would expect it to either be based on the patron's home library or on the pickup library. |
| 17:04 |
terranm |
jihpringle: +1 to that being a bug |
| 17:05 |
jihpringle |
terranm: speaking of bugs, are you planning to submit a bug for the old notes/alerts/messages surfacing? we're seeing that on our test server too |
| 17:06 |
jeff |
eby: if you are attempting to cancel a hold, the permission check on CANCEL_HOLDS is not scoped to any org unit -- if you have it anywhere, you can cancel a hold. |
| 17:07 |
eby |
Thanks I'll do some more testing. It seemed like it was checking based on the staff's home library which didn't make sense to me. But I'll dig more. |
| 17:07 |
jeff |
eby: "uncancel" is checked at the current hold pickup lib (it also tests the CANCEL_HOLDS permission) |
| 17:07 |
jeff |
so, in theory you can cancel a hold which you cannot then uncancel (without more work) |
| 17:08 |
eby |
ok that is what i was seeing jeff. it was sending the home library which of course would always allow regardless of what you were looking at |
| 17:08 |
eby |
(if you can cancel your own) |
| 17:08 |
terranm |
jihpringle: I haven't been viewing that as a bug since those old messages were still in the system and not deleted. However, we are going to do a cleanup project to mark specific types of old messages deleted. |
| 17:08 |
jeff |
eby: actually, let me fix my first statement... it wasn't quite accurate/precise. |
| 17:09 |
jihpringle |
terranm: we're still early days in our testing but we'd be very interested in what you find as you do your cleanup project since it looks like we'll need to do the same when we upgrade this summer |
| 17:09 |
jeff |
eby: when you attempt to cancel a hold, the permission is checked without passing an org unit -- which means that the permission check is performed based on the org unit of the workstation associated with the user's login session. |
| 17:09 |
jeff |
eby: that might explain what you were seeing better. |
| 17:09 |
terranm |
jeff++ |
| 17:28 |
jeff |
that might be me failing to set a new(ish) org unit setting regarding renewals and expired accounts. I'll look into it. |
| 17:28 |
eby |
I think I did run into that but may have tweaked permissions |
| 17:29 |
jeff |
for now, I'm off. another day! |
| 18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:16 |
|
rjackson_isl_hom joined #evergreen |
| 07:47 |
|
alynn26 joined #evergreen |
| 07:56 |
|
collum joined #evergreen |
| 11:35 |
terranm |
*music added for my own entertainment |
| 11:40 |
mmorgan |
terranm++ |
| 11:41 |
mmorgan |
The music is perfect! It looks like you were getting several different template versions?? It made me dizzy! |
| 11:43 |
terranm |
Yep - the current version says "Test 8" at the top, but it is apparently randomly pulling up earlier test versions from ... somewhere? No idea where. |
| 11:52 |
Dyrcona |
terranm: Two questions: 1. Are you using Hatch? 2. Have you tried clearing all data from the browser developer tools? |
| 11:53 |
terranm |
1) Nope, 2) - let me try that |
| 12:06 |
terranm |
Nope, that didn't work either. |
| 12:07 |
terranm |
Going to try on a different test server. |
| 12:18 |
csharp_ |
I have OpenSRF debug level logs running on one of our servers and we've had a couple of instances of the open-ils.actor problem - going to keep it running throughout the day to see if we can collect enough data to help us figure this out |
| 12:23 |
|
eady joined #evergreen |
| 12:24 |
terranm |
I'm able to recreate the holds pull list problem on https://demo.evergreencatalog.com/ so I'll open a ticket |
| 16:14 |
|
jvwoolf1 joined #evergreen |
| 16:42 |
|
jvwoolf1 left #evergreen |
| 17:03 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 00:22 |
|
jvwoolf joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:30 |
|
rjackson_isl_hom joined #evergreen |
| 08:13 |
|
mantis1 joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 11:02 |
Dyrcona |
Yeahp. |
| 11:07 |
Dyrcona |
The places in the OpenSRF code where the errors are coming from look like it would be on first connection or getting the first response from ejabberd. |
| 11:09 |
Dyrcona |
RE Chrome issues from yesterday: I've also had to reload GMail more frequently to it to autofill email recipients. |
| 11:11 |
csharp_ |
ulimit shows 'unlimited' for every user we've tested opensrf, root, ejabberd |
| 11:11 |
csharp_ |
@quote add < Dyrcona> csharp_: My gut could be wrong. I am hungry at the moment. |
| 11:11 |
pinesol |
csharp_: The operation succeeded. Quote #221 added. |
| 11:12 |
csharp_ |
oh - didn't mean to keep the csharp_ part :-) |
| 11:17 |
Dyrcona |
:) |
| 14:45 |
Dyrcona |
terranm++ |
| 14:46 |
terranm |
https://bugs.launchpad.net/evergreen/+bug/1958573 |
| 14:46 |
pinesol |
Launchpad bug 1958573 in Evergreen "Action triggers that create messages for Patron Message Center are setting visiblity to false" [High,New] |
| 14:46 |
terranm |
patch ready for testing |
| 14:46 |
Dyrcona |
Yeah, I got the email. I've not seen it in the wild, but I think looking at the code qualifies me to confirm it. |
| 14:49 |
mmorgan |
terranm++ |
| 14:54 |
|
terranm joined #evergreen |
| 16:33 |
|
jihpringle joined #evergreen |
| 17:03 |
|
mmorgan left #evergreen |
| 17:52 |
|
mantis1 joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:08 |
|
jihpringle joined #evergreen |
| 19:44 |
|
jihpringle joined #evergreen |
| 23:08 |
|
Keith_isl joined #evergreen |
| 04:08 |
|
phasefx joined #evergreen |
| 04:08 |
|
abneiman joined #evergreen |
| 04:08 |
|
miker joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:09 |
|
collum joined #evergreen |
| 07:32 |
|
mantis joined #evergreen |
| 08:23 |
|
Dyrcona joined #evergreen |
| 09:57 |
mmorgan |
mantis: I'm pretty sure the expired staff login block wouldn't affect patrons, though I haven't actually looked :) |
| 09:57 |
jeff |
and yes, I don't think that the changes for bug 1844121 would have made this become a new issue for you from a patron / opac POV |
| 09:57 |
pinesol |
Launchpad bug 1844121 in Evergreen 3.6 "Able to login to staff client with old card number" [High,Fix released] https://launchpad.net/bugs/1844121 |
| 09:58 |
terranm |
I just tested on a 3.8 test box with the default settings and if you have 333 as a barcode and 222 as a user name, the 333 will work and the 222 won't. |
| 09:58 |
mmorgan |
It's not uncommon in our libraries that the primary barcode in a patron record gets changed when a patron gets a new barcode, but the username does not. |
| 09:59 |
mmorgan |
Then the patron can't login with the username because that "barcode" is inactive, as jeff describes. |
| 09:59 |
terranm |
If I replace the 333 barcode with 444, then the 333 no longer works. |
| 16:30 |
|
rfrasur joined #evergreen |
| 17:23 |
|
mmorgan left #evergreen |
| 17:26 |
|
jvwoolf1 left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 00:46 |
|
eglogbot joined #evergreen |
| 00:46 |
|
Topic for #evergreen is now Welcome to #evergreen (https://evergreen-ils.org). This channel is publicly logged. |
| 01:28 |
|
pastebot joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:30 |
|
Dyrcona joined #evergreen |
| 07:34 |
Dyrcona |
jeff: I figured out my issue with action triggers. It was the template changes. I had the templates in individual files and used m4 to build 1 update SQL file. The string "format" in the templates was interpreted by GNU m4 as the format macro. This broke the templates, including the originals, that got loaded into the database using this method. |
| 07:35 |
Dyrcona |
Two clever by half. :) |
| 13:38 |
|
pinesol joined #evergreen |
| 13:38 |
|
troy joined #evergreen |
| 13:52 |
|
abneiman joined #evergreen |
| 14:16 |
Dyrcona |
Argh...... My tests keep "failing" because of some overlooked detail..... |
| 14:26 |
Dyrcona |
Ah well. I can salvage it this time. |
| 15:48 |
|
Guest88 joined #evergreen |
| 15:57 |
|
jihpringle joined #evergreen |
| 16:13 |
|
abowling joined #evergreen |
| 17:03 |
|
mmorgan left #evergreen |
| 18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 04:50 |
|
alynn26 joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:18 |
|
Christineb joined #evergreen |
| 07:54 |
|
collum joined #evergreen |
| 08:31 |
|
mantis joined #evergreen |
| 09:38 |
|
jvwoolf joined #evergreen |
| 09:50 |
Dyrcona |
miker: Yes. The TTOPAC pulls titles and authors from the MARC, IIRC. BooPAC uses display fields. |
| 09:53 |
mmorgan |
JBoyer++ |
| 10:50 |
mantis |
We're on 3.6.5 using Angular for the staff but still using TPAC for the OPAC. When accessing the Patron View button on conjoined items, we get a server error. This however works when Boopac is enabled on our other test servers. Is this a known bug? |
| 11:06 |
Dyrcona |
mantis: IDK, but if it is not on Lp, then it's probably not widely known. |
| 11:41 |
|
jihpringle joined #evergreen |
| 12:15 |
collum |
mantis: We don't have any conjoined items, but I just tried it in our test database and it worked in the TPAC. We are on 3.7.2. |
| 12:17 |
mantis |
collum: Thanks for giving it a shot. With the community servers on Bootstrap, it's hard for us to tell if there is an issue on my end or an actual bug. |
| 12:43 |
|
jvwoolf1 joined #evergreen |
| 13:38 |
|
rfrasur joined #evergreen |
| 15:08 |
JBoyer |
Ah |
| 15:09 |
JBoyer |
In that case there should some good news in our email later I suppose. In short, you've got concerto and friends loading deterministically? |
| 15:09 |
JBoyer |
(again, that is) |
| 15:10 |
Dyrcona |
Yes. Test results are consistent. |
| 15:11 |
JBoyer |
Dyrcona++ |
| 15:11 |
Dyrcona |
And all pass, at least, the last few times that I tried. |
| 15:11 |
JBoyer |
Ok, I'm planning to skip release info updates for lack of non-placeholder-ness unless someone prefers that be changed. |
| 17:26 |
miker |
seems unlikely to have recently broken because of that, but I suppose it's possible. the opac email code lacks all the 2019/2020 updates that the reactor got. would be beneficial in any case to have them. I'll look at putting that in the branch as well |
| 17:26 |
miker |
but not tonight! |
| 17:26 |
terranm |
miker++ |
| 18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
