| Time |
Nick |
Message |
| 09:04 |
|
Christineb joined #evergreen |
| 09:19 |
|
Dyrcona joined #evergreen |
| 09:33 |
|
Rogan joined #evergreen |
| 10:34 |
|
sandbergja joined #evergreen |
| 11:29 |
|
jihpringle joined #evergreen |
| 11:34 |
Dyrcona |
"timed out waiting on open-ils.acq pid=1376 to die" seems to be a common thing, modulo the pid number. |
| 11:56 |
csharp_ |
@who timed out waiting on open-ils.acq pid=1376 to die? |
| 11:56 |
pinesol |
phasefx timed out waiting on open-ils.acq pid=1376 to die. |
| 12:12 |
|
mmorgan joined #evergreen |
| 12:24 |
Dyrcona |
The experimental Angular circ client has some issues with clipping. |
| 12:25 |
Dyrcona |
Maybe I'll make a LP. |
| 12:32 |
Dyrcona |
Creating a hold note doesn't seem to work. |
| 12:34 |
Dyrcona |
Think it might be a side effect of the Redis HA branch: WS failed sending data to OpenSRF, exiting |
| 12:34 |
Dyrcona |
2026-01-14T12:33:12.084371-05:00 jasontest client: [ERR :35627:transport_connection.c:301:17684119583562717] REDIS Error [NOPERM this user has no permissions to access one of the keys used as arguments] |
| 12:43 |
Dyrcona |
Might have another vm with plain o'l Redis to test with, but I'm gonna try it with ejabberd first. |
| 12:46 |
Dyrcona |
Adding a hold note is OK with Ejabberd, so it's definitely Redis. |
| 14:06 |
dluch |
Question: How does "Shelf Browse" in the staff client determine the call numbers to browse and display? For instance, staff member is looking at a record at the consortium level that has an item they own on it. They use LC call numbers, as do all the other libraries' items on the record except one, which is Dewey. When clicking on Shelf Browse in the record, it only returns Dewey bibs. Why? |
| 14:06 |
|
Dyrcona joined #evergreen |
| 14:07 |
dluch |
Not finding a bug report or documentation about it |
| 14:08 |
csharp_ |
dluch: peeking at the code |
| 14:09 |
dluch |
Thanks, csharp_! |
| 14:11 |
csharp_ |
dluch: on a glance, it looks like it starts with an org unit, then finds copies for that unit, then looks for non-deleted asset.call_numbers ("volumes") and uses the label_sortkey to sort them |
| 14:11 |
csharp_ |
so it's using the label on asset.call_number and not the bibs |
| 14:12 |
csharp_ |
dluch: I don't see anything related to dewey vs. LC |
| 14:12 |
dluch |
Huh. So, it's looking at asset.call_number and then sorting by label, so all the Dewey numbers come first? |
| 14:13 |
dluch |
Or am I not understanding that right? (very possible, lol) |
| 14:13 |
csharp_ |
(looking further...) |
| 14:14 |
csharp_ |
just imagine a progress bar for a minute |
| 14:14 |
dluch |
:-D |
| 14:16 |
|
Jaysal joined #evergreen |
| 14:20 |
csharp_ |
dluch: I would wonder what value(s) you have for each org unit for the cat.default_classification_scheme library setting |
| 14:20 |
csharp_ |
if it's "Dewey (DDC)" that's probably your issue |
| 14:20 |
csharp_ |
the label normalizing logic looks up that setting to do its work |
| 14:21 |
dluch |
Consortium level is Generic, the library in question is LoC. Some of the others are also LoC, but most are using consortium default |
| 14:23 |
csharp_ |
it will look up the setting for the owning library of the call_number (volume) |
| 14:24 |
csharp_ |
not finding one for that, it will search up the tree until it finds one |
| 14:24 |
csharp_ |
if it finds none, it lands on "1" (generic) |
| 14:26 |
csharp_ |
dluch: it's been a while since I've had to understand LC call numbers, but it looks like generic would do the job from my cursory reading of the code |
| 14:26 |
dluch |
Ah, okay. So, if there are multiple call numbers on the bib, it probably goes with generic? |
| 14:26 |
dluch |
Thank you for your help, csharp_! Long time for me, too, lol! |
| 14:27 |
dluch |
csharp__++ |
| 14:27 |
csharp_ |
it goes by generic if it can't find a cat.default_classification_scheme setting value |
| 14:27 |
mmorgan |
dluch: csharp_: It's worth noting that each asset.call_number row has a label_class, and the sortkey is determined by the normalizer for that class. |
| 14:27 |
csharp_ |
mmorgan++ # ahh |
| 14:27 |
mmorgan |
So if call numbers were added long ago with the wrong label_class, that can cause sorting issues. |
| 14:28 |
mmorgan |
Ask me how I know ;-) |
| 14:28 |
dluch |
ohh, okay |
| 14:28 |
csharp_ |
so you can learn that with a DB query or report, then do a batch update if needed |
| 14:28 |
dluch |
mmorgan++ |
| 14:29 |
csharp_ |
or, uh, just update all non-deleted CNs with the right class without caring what's there |
| 14:29 |
dluch |
Gee. mmorgan, how do you know? ;-) |
| 14:29 |
csharp_ |
mmorgan: I think we had to do that a long time ago |
| 14:29 |
dluch |
Awesome, okay! Thanks! |
| 14:29 |
csharp_ |
dluch: hopefully that gives you enough direction to know what to do |
| 14:30 |
dluch |
It does, thanks!! |
| 14:30 |
mmorgan |
csharp_++ |
| 14:30 |
csharp_ |
also, probably worth creating a doc somewhere... |
| 14:30 |
* csharp_ |
searches for that section |
| 14:31 |
dluch |
definitely |
| 14:34 |
csharp_ |
looks like there are some reference to this in the "Migrating from a legacy system" doc |
| 14:34 |
csharp_ |
honestly, it falls between admin and cataloging imo |
| 14:35 |
csharp_ |
maybe I'll just create the bug report and let someone else help |
| 14:38 |
|
Dyrcona joined #evergreen |
| 14:56 |
csharp_ |
https://bugs.launchpad.net/evergreen/+bug/2138398 |
| 14:56 |
pinesol |
Launchpad bug 2138398 in Evergreen "Documentation: need for docs on default classification scheme" [Wishlist,New] |
| 15:07 |
* Dyrcona |
wishes he had not been so squash happy with some of the customization commits. It it difficult now to disentangle a particular feature. |
| 15:08 |
csharp_ |
yeah - we've gone too far that direction in the past too |
| 15:09 |
Dyrcona |
I think I'm going to do an interactive rebase and edit some of the changes out. |
| 15:09 |
Dyrcona |
I started doing this a week or two before Christmas but gave up because the big "CWMARS Customizations" commit at the beginning of the branch is a giant hairball. |
| 15:10 |
Dyrcona |
Thing is, I can't just rebase on main because of issues with the Quipu code and our version of it. |
| 15:11 |
Dyrcona |
So, maybe I'll do two new branches: 1 with just our Quipu stuff (if that's possible) and the other with our non-Quipu stuff. |
| 15:12 |
csharp_ |
we skipped our own Quipu stuff in the reapply on 3.16 - going to start on that this week |
| 15:12 |
Dyrcona |
Yeah, that's what I'm planning to do, but I have to separate it from the other things first. That hairball I mentioned.... |
| 15:13 |
Dyrcona |
I suspect that we'll drop much of our Quipu customization and only keep a couple of things. |
| 15:14 |
* Dyrcona |
will try and tackle the Quipu changes first. That might be easier since there are some distinctly Quipu commits on top. |
| 15:14 |
csharp_ |
@band add Quipu Hairball |
| 15:14 |
pinesol |
csharp_: Band 'Quipu Hairball' added to list |
| 15:21 |
Dyrcona |
This is the culprit: "Forward Port CW MARS Legacy Customization." |
| 15:22 |
Dyrcona |
That commit got repeatedly squashed and fixed up, it's an amalgamation of hundreds of commits at this point. |
| 15:22 |
csharp_ |
ick |
| 15:23 |
Dyrcona |
The output of git show for that commit is 1,942,913 bytes. |
| 15:23 |
csharp_ |
yowza |
| 15:25 |
jeffdavis |
640,000 bytes out to be enough for any commit |
| 15:25 |
csharp_ |
git shrink |
| 15:29 |
Dyrcona |
Dropping 56 commits that don't touch Quipu, and editing the first one to do a reset and remove non-quipu changes, for this branch. |
| 15:30 |
Dyrcona |
Picking 19 commits that do touch Quipu, so 20 commits being kept in total. I never should have squashed the Quipu stuff into the legacy commit. |
| 15:31 |
Dyrcona |
I'll have to do this again in the other direction dropping the Quipu stuff. |
| 15:32 |
Dyrcona |
All new branches in case I mess up and lose something. It will still be around in the original branch. |
| 15:32 |
Dyrcona |
Well, here goes..... |
| 15:40 |
jeff |
Dyrcona: https://butt.holdings/ (appropriate and relevant, I swear) |
| 15:41 |
Dyrcona |
jeff++ |
| 15:47 |
Dyrcona |
Yay for bash functions. I wrote on the lets me pipe output from the command line into a new Emacs window. I don't use it very often, but it sure is useful right now. |
| 15:50 |
Dyrcona |
Now, what's the thing that runs the current selection through the shell? |
| 15:59 |
jeff |
I'm pretty sure that /eg/staff/login used to redirect to the splash page if you were already logged in. Somewhere (probably between 3.13 and 3.15) that stopped. Now, it clears the local auth token (leaving the session to time out later), and presents the login page. I don't remember if I've created a bug for that, but I suspect a return to the old behavior would be desirable. Am I missing something? |
| 16:00 |
jeff |
Dyrcona: this may or may not relate to that mystery you were working on the other day. I can't remember if I mentioned it at the time. |
| 16:04 |
Dyrcona |
jeff: It does relate, but thanks to csharp_ we figured it out. I'll check tomorrow if things are working better for the staff person in question. |
| 16:05 |
Dyrcona |
I'm sure the issue came about because we upgraded several versions to 3.15 recently. |
| 16:05 |
Dyrcona |
And, I think I dropped too many commits because I'm getting a conflict with one of the later Quipu commits. |
| 16:08 |
Dyrcona |
Odd. Sometimes just deleting text leads to conflicts where making changes to the text probably would not. |
| 16:10 |
Dyrcona |
Oh. I see. Looks like after conflict resolation, some <div> tags are not balanced, so I must have missed a commit somewhere. |
| 16:12 |
Dyrcona |
Well, only in 1 of the files. The others add up. |
| 16:13 |
Dyrcona |
Well, that wasn't so hard. I think the other will be more difficult. |
| 16:13 |
Dyrcona |
And, I can't just merge the quipu stuff with main (or the other way around, really) because of conflicts. |
| 16:14 |
Dyrcona |
I stopped last time because I started about this time of day and ran out of time to finish it. |
| 16:16 |
Dyrcona |
Seeing the commits for stuff from Lp bugs that we've applied but still have not made it into main, I think I'm going to advocate for these in the next release. |
| 16:17 |
Dyrcona |
Definitely for 4.0. |
| 16:23 |
Dyrcona |
Wonder if I should undo the hairball and base the commits on "features?" That will be more work, and I should probably wait and start this tomorrow in that case. |
| 16:23 |
Dyrcona |
Maybe I'll just remove Quipu for now. |
| 16:27 |
Dyrcona |
Well, that rebase was actually easier. |
| 16:28 |
Dyrcona |
Let's see if the noquipu branch rebases on current main |
| 16:29 |
Dyrcona |
Uh... I let a file slip through... |
| 16:29 |
Dyrcona |
Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/Ecard.pm guess, I'll rebase again. |
| 16:38 |
|
jihpringle joined #evergreen |
| 16:38 |
Dyrcona |
Fun thing about rebase: Sometimes you resolve conflicts in earlier commits with stuff that you remove in later commits. :) |
| 16:42 |
Dyrcona |
Then you see things in the conflicts that you should probably revisit. |
| 16:44 |
* Dyrcona |
shrugs this one off. |
| 16:50 |
Dyrcona |
Well, that wasn't so painful.... |
| 17:04 |
Bmagic |
what would you do if an order, when activated, didn't insert an ORDERS row into acq.edi_message ? I'm inclined to un-activate and click the button again with the hopes it works this time |
| 17:04 |
Bmagic |
un-activating an active order will require me to delete all of the encumbered rows from acq.fund_debit as well as nullifying the column fund_debit from acq.lineitem_detail (right?) |
| 17:09 |
|
mmorgan left #evergreen |
| 17:18 |
jihpringle |
Bmagic: you might want to start by resetting the trigger event |
| 17:19 |
jihpringle |
(I know we do this when EDI messages don't generate as expected when POs are activated but I'm not 100% what actually gets done as it's not me doing it) |
| 17:27 |
Bmagic |
jihpringle: I thought the row was inserted upon "Activate" button click |
| 17:27 |
Bmagic |
The action trigger mechanism I think is the "old" JEDI way |
| 17:33 |
jihpringle |
we use the EDI attributes and we still occasionally have to reset EDI messages (thought I'm not entirely sure what we do to reset them) |
| 17:34 |
jihpringle |
if the PO was created from a MARC file you might be better off cancelling the PO and creating a new PO from the file |
| 17:34 |
Bmagic |
jihpringle: when this occurs for you, do you remember using the interface and clicking "Activate" again? (after your support team does whatever they do?) |
| 17:35 |
jihpringle |
Usually it's just something behind the scenes, but what we've encountered may not be quite the same as you're seeing |
| 17:37 |
jihpringle |
generally for us the issue is that the EDI message for the PO just wasn't created |
| 17:43 |
Bmagic |
That's where I'm at. We have a perfectly good looking PO, and it's activated. And the provider is one that uses EDI Attr, so it should* have created an EDI message in acq.edi_message with a type of "ORDERS" if I'm not mistaken |
| 17:43 |
Bmagic |
though, I can't find the line of code in Order.pm that creates the edi_message |
| 18:50 |
jihpringle |
Bmagic: I've asked what it is we actually do to reset it and I'll let you know :) |
