| Time |
Nick |
Message |
| 00:35 |
|
stephengwills left #evergreen |
| 03:04 |
|
dickreckard joined #evergreen |
| 04:13 |
|
dickreckard joined #evergreen |
| 07:17 |
|
collum joined #evergreen |
| 07:33 |
|
kworstell-isl joined #evergreen |
| 08:17 |
|
dickreckard joined #evergreen |
| 08:33 |
|
_collum joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 09:06 |
|
Dyrcona joined #evergreen |
| 09:08 |
|
dguarrac joined #evergreen |
| 09:11 |
|
stephengwills joined #evergreen |
| 09:22 |
|
smayo joined #evergreen |
| 09:56 |
Dyrcona |
Crazy. NCIPServer worked for me without applying the HTTP::Body::XForms patch on Ubuntu 22.04. |
| 10:25 |
|
kmlussier joined #evergreen |
| 10:29 |
Dyrcona |
Looks Lp is having email issues again. |
| 10:30 |
|
collum joined #evergreen |
| 10:39 |
dickreckard |
Bmagic: still looking into that keyword mistery.. so by truncating the keyword_field_entry table and re-ingesting a bib, I see the new rows being created.. |
| 10:39 |
dickreckard |
but still, in the opac search, no results by keyword |
| 10:39 |
Bmagic |
that's interesting; |
| 10:40 |
Bmagic |
ellusive thing isn't it. Try autogen.sh as the opensrf user and restart Apache |
| 10:40 |
dickreckard |
so I am wondering if something got messed up in how the facet fields are setup |
| 10:43 |
dickreckard |
do you know how one would search by keyword in the srfsh interface? |
| 10:52 |
Dyrcona |
dickreckard: It's probably open-ils.search.biblio.multiclass. You'll need to look at the Perl code to see how it works, though. |
| 11:00 |
berick |
you can also search via the staff catalog and see the full JSON of the API call in the activity log -- then just remove .staff from the API call |
| 11:19 |
dickreckard |
ok something in the logs.. failed with exception: Exception: OpenSRF::EX::ERROR 2024-04-30T17:15:29 OpenILS::Application::AppUtils /usr/local/share/perl/5.36.0/OpenILS/Application/AppUtils.pm:202 System ERROR: Exception: OpenSRF::DomainObject::oilsMethodException 2024-04-30T17:15:29 OpenSRF::AppRequest /usr/local/share/perl/5.36.0/OpenSRF/AppSession.pm:1171 <500> *** Call to |
| 11:19 |
dickreckard |
[open-ils.storage.biblio.multiclass.staged.search_fts.staff.atomic] failed for session [1714490129.12382188876.283246714] |
| 11:19 |
dickreckard |
so the search fails when by keyword that makes sense |
| 11:23 |
dickreckard |
the erro thread trace goes to > Can't use an undefined value as a HASH reference at /usr/local/share/perl/5.36.0/OpenILS/Application/Storage/Driver/Pg/QueryParser.pm line 1346. |
| 11:23 |
Bmagic |
starting to sound like Evergreen isn't installed properly? |
| 11:23 |
Bmagic |
or a custom patch is breaking it somewhere? Are you using vanilla Evergreen? |
| 11:26 |
dickreckard |
mmm there is a custom patch but it should only relate with ldap authorization |
| 11:26 |
mmorgan |
dickreckard: Did you make any indexing changes? Do your rows in keyword_field_entry look normal? |
| 11:27 |
dickreckard |
mmorgan: just truncated the table so right now its the rows for only 1 bib.. they look 'normal' ( i mean they have their own weird vector syntax but doesnt look weirder than before ) |
| 11:28 |
* mmorgan |
nods. Weird vector syntax sounds normal :) |
| 11:31 |
|
kworstell_isl joined #evergreen |
| 11:32 |
Bmagic |
dickreckard: I'd run through the build steps again, and restart the services stack |
| 11:37 |
dickreckard |
ah yes with a fresh clean database the keyword search works. with the imported database doesn't |
| 11:38 |
dickreckard |
so i guess it is somewhere in the database upgrade steps that something breaks but didnt get errors in the process.. |
| 11:45 |
dickreckard |
will try to repeat again the db update steps |
| 11:45 |
dickreckard |
with more attention.. |
| 11:51 |
|
Stompro joined #evergreen |
| 11:59 |
|
jihpringle joined #evergreen |
| 12:07 |
Bmagic |
I'm suggesting just the Evergreen bits, you can leave the DB alone. Or, since you mention it, does config.upgrade_log contain rows equal to the version of Evergreen that you think you've upgraded to? |
| 12:17 |
dickreckard |
yes, the upgrade log arrives to 3.12.1.. |
| 12:18 |
dickreckard |
Bmagic: a new clean database works correctly with the current Evergreen bits. it seems to be the upgraded db that breaks the keyword search ( and probably other things then. ) |
| 12:18 |
Bmagic |
I see what you mean, carry on |
| 12:26 |
|
smayo joined #evergreen |
| 12:49 |
Dyrcona |
I have test/dev servers where features sometimes don't work. I've got one where the acq. interface completely fails. Search has been a problem in the past. A full ingest sometimes helps. |
| 12:49 |
Dyrcona |
dickreckard ^^ |
| 12:57 |
Dyrcona |
We usually blame these issues on the test environment being slower than production. |
| 14:05 |
|
sleary joined #evergreen |
| 14:54 |
Dyrcona |
oops. accidentally pushed a working branch to NCIPServer origin, and gitolite won't let me delete it. I should probably check/update the configuration to prevent pushing working branches in that repo. There's only 3 of us that use it, anyway.... |
| 15:09 |
|
kworstell-isl joined #evergreen |
| 15:13 |
dickreckard |
Bmagic Dyrcona: in the end I re-executed all the sql upgrade scripts from scratch and ended up with a working setup! \o/ so it was something that went wrong with the previous upgrade... thanks again for thinking along! :) |
| 15:13 |
Bmagic |
dickreckard++ |
| 15:25 |
Dyrcona |
Cool! |
| 15:25 |
Dyrcona |
also, I thought I was on the list to get NCIPServer commit emails, but I guess not.... Is there even such a list? /me checks. |
| 15:29 |
Dyrcona |
OK. There is no such list. |
| 15:47 |
Bmagic |
:) |
| 15:50 |
|
jihpringle joined #evergreen |
| 15:52 |
Dyrcona |
NCIPServer got some bug fixes and new features today. Stompro++ |
| 15:58 |
Stompro |
Huzza.... we just went live with Reshare today also. |
| 15:59 |
Bmagic |
Stompro++ # suuuweet! |
| 16:00 |
Stompro |
But I just found a possible bug in the lookupuser password auth stuff.... looks like it is sending in the barcode as the username argument for open-ils.auth.login |
| 16:01 |
Stompro |
Users with usernames set to something other than their barcode cannot login. |
| 16:01 |
Stompro |
https://gitlab.com/LARL/ncipserver/-/commit/237de8c96d33dfd5eaf2d88bca02e6ee72973aad#078d40ab367e08e872e32708828b718be4287eb6_2788_2863 |
| 16:02 |
Dyrcona |
I'd go with identifier and let Evergreen figure it out. |
| 16:04 |
Dyrcona |
Of course, even with local regexes there are usernames that won't work sometimes. We've had barcodes trip that up because our regex looks for 'D[0-9]{9}' and some have 'd' in the barcode. :) |
| 16:06 |
Dyrcona |
I guess a username that's 14 digits will cause us problems.... I've recently come out against letting patrons chose their own usernames in light of these issues and other bugs. |
| 16:07 |
Dyrcona |
I've been outvoted, so I go along with it. |
| 16:08 |
Dyrcona |
Stompro: Do you want to update the code or should I? |
| 16:09 |
Stompro |
Feel free, I'll hopefully be able to test it out tomorrow afternoon. I don't get why usernames don't actually work either, that might be a different bug. |
| 16:10 |
Dyrcona |
Well my barcode == username, and breaks the rules. I should have tested with a regular patron, and in light of this, I will test it again. |
| 16:11 |
Dyrcona |
I think I know the account to test with. One of those with the lowercase d in the barcode. They also have a different username. |
| 16:13 |
Dyrcona |
Hm.. the lowercase d password is inactive in my test database and the uppercase D one is active. I guess that's even better. :) |
| 16:17 |
Dyrcona |
Also, the code was implemented to only expect barcodes, but.... |
| 16:21 |
Stompro |
do you mean the "<AuthenticationInputType>barcode</AuthenticationInputType>" part? |
| 16:22 |
Stompro |
I noticed that also, but I don't remember what the other options in the standard were there off the top of my head. |
| 16:22 |
Dyrcona |
Nope. I mean the whole initial implementation was implemented to expect barcodes and not usernames. I think I know the issue with usernames. I'll look into it after this. |
| 16:22 |
Dyrcona |
I don't think the "standard" says anything about anything but barcodes. |
| 16:22 |
Dyrcona |
I'd have to look again. |
| 16:23 |
Stompro |
Thanks for taking a look. Dyrcona++ |
| 16:24 |
Dyrcona |
So, when I use this patron's username, they aren't found. That's because we search for users by barcode and not username. I think we could bug on that Lp and come up with an implementation that searches username, too. |
| 16:26 |
Dyrcona |
I use the barcode and I can find them and they authenticate correctly using either barcode or identifier, provided I give the correct password. |
| 16:27 |
Dyrcona |
I'll switch it to identifer and push a follow up commit to main, then open a Lp bug for looking up users by username. |
| 16:30 |
Dyrcona |
huh. Guess I haven't committed that yet. |
| 16:31 |
|
jihpringle joined #evergreen |
| 16:31 |
Dyrcona |
Oh, right! I had questions about a few things.... |
| 16:31 |
Dyrcona |
Been a longish day. |
| 16:51 |
Bmagic |
Dyrcona++ |
| 17:04 |
|
mmorgan left #evergreen |
| 17:15 |
|
sleary joined #evergreen |
| 17:36 |
|
jihpringle joined #evergreen |
| 18:30 |
|
stephengwills left #evergreen |
| 18:46 |
|
kmlussier left #evergreen |
