Evergreen ILS Website

IRC log for #evergreen, 2022-02-04

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
06:02 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
07:31 rjackson_isl_hom joined #evergreen
07:39 rjackson_isl_hom joined #evergreen
08:29 mantis1 joined #evergreen
08:37 mmorgan joined #evergreen
08:51 Stompro joined #evergreen
09:05 jvwoolf joined #evergreen
09:08 Keith-isl joined #evergreen
09:36 Dyrcona joined #evergreen
10:43 jeff thank you irc client paste protection.
10:44 jeff added opinions to bug 1746800
10:44 pinesol Launchpad bug 1746800 in Evergreen "Bibs with Transcendant of 'f' showing on location limited searches" [Undecided,Confirmed] https://launchpad.net/bugs/1746800
10:44 jeff (almost pasted the text of my comment instead of the bug number)
10:45 jeff berick: in your Elasticsearch staff search branch, did you opt to include empty records in search results?
10:45 berick jeff: as in recs without holdings?  yes
10:46 jeff (I guess I could look to see what it currently does, but I'm curious what you considered also.)
10:46 jeff got it! thanks!
10:46 berick and they are included in results when the API is called with .staff
10:47 jeff I'd been giving thought to excluding them by default recently, and then miker commented on the bug above today, so I took the opportunity to add my thoughts.
10:48 * miker takes a peek
10:49 jeff in a nutshell, I agree that there's a use case for including them, but I think changing the default to omit them benefits more staff / more staff searches. more detail in my comment. :-)
10:50 miker jeff: I'll comment on the LP, but I think there needs to be a search syntax mechanism. that could be added at the UI level based on a user/ws setting, but I don't like the idea of entirely spooky action in search based on a user's pref
10:51 miker but, I have no dog in the round-1 fight of "inlcude or not" ... I just care how it's implemented :)
10:51 jeff I don't think I like that either. I just threw it out there. :-)
10:52 miker as it happens, I was looking at the code when I made the comment, so I'll offer a branch that makes it possible, and then we can all discuss how/when to include/exclude empty
10:53 jeff sounds good! I just happened to be giving thought to the behavior this week, but hadn't looked at the code in question again, so your bug comment was well-timed.
10:57 * Dyrcona mostly agrees with jeff. What about a sticky checkbox to include empty records?
10:59 miker Dyrcona: since the behavior today is to include by default, I'm adding an #exclude_empty modifier (as a proposal), though I think we can flip the logic in the UI if that's the desired UX
11:00 miker but, obv, it'd be trivial to invert the modifier, if changing the core behavior to require action to include empty is the consensus
11:06 jeff Dyrcona: I don't think we have any other sticky (as in, state is stored in a setting and persists until changed) staff catalog search UI bits, so I was thinking changing the preference should be intentional (as options under "Catalog Preferences"). I could be wrong.
11:06 jeff and as I think about if it should be a workstation or a user setting, I almost want it to be both, but I don't think we're set up for that.
11:06 Dyrcona Well, it wouldn't need to be sticky, and I think it ought to exclude empty bibs by default.
11:07 Dyrcona s/it/staff search/
11:07 Dyrcona But, I don't use the client except when I'm told something's buggy or broken, so my opinion probably matters less that other people's opinions.
11:08 Dyrcona s/that/than/
11:21 miker branch pushed for lookin' at, and LP updated.  you'll see it's trivial to go with an #include_empty modifier if that's the way things shake out. I think there's a pretty strong argument for making it sticky (for catalogers) rather than making it a setting outside of the search UI, as long as the checkbox is always available up front on searches.
11:21 miker and, probably sticky as a WS setting, IMO ... but, I won't fight too hard for that
12:16 jihpringle joined #evergreen
13:02 rfrasur joined #evergreen
14:22 eby jeff: you around for a quick dcb/mel question
14:22 jeff sure!
14:23 jeff even if the answer is just "yes, we have heard those same disturbing sounds emanate from that same black box" :-)
14:58 Dyrcona :)
15:05 Dyrcona @decide Cronscript.pm or DBI
15:05 pinesol Dyrcona: go with DBI
15:05 Dyrcona Thanks, pinesol, I will!
15:48 jvwoolf left #evergreen
16:21 Dyrcona Grr. It's not working.
16:21 Dyrcona I'm trying to change 347$b using DBI and I'm not doing something right.
16:24 jeff Are you using MARC::Record to manipulate the marcxml?
16:26 Dyrcona jeff: Yes, and that's not my problem.
16:26 Dyrcona I just assumed that the data was gonna look like what's in metabib.real_full_rec.value, but it doesn't.
16:26 Dyrcona The value gets normalized.
16:27 jeff ah. could be worse. you could be parsing/manipulating the marcxml using regular expressions, which brings to mind the classic (humorous) stackoverflow answer: https://stackoverflow.com/a/1732454/157515
16:29 jeff if the normalization is causing problems only with your change attempt, and the problem is that the normalization makes it difficult to find the relevant records, could you change your approach to use mrfr metabib.real_full_rec to find *possibly* relevant records, then parse their marcxml to determine the non-normalized value in 347$b?
16:29 jeff (you probably already have that idea or better)
16:30 Dyrcona jeff: It's pretty simple. I'm searching mrfr using the value string converted to a tsvector to find the records that I want to update.
16:31 Dyrcona I'm using that string, preconversion to look for matching 347$b in the MARC::Record. It's the $subfield eq $str that it is failing, basically.
16:32 Dyrcona If normalize $subfield, then it will match, but then I'll be stuffing a different, normalized value into the MARC and our catalogers might not like that.
16:33 Dyrcona Turns out, too, that it's only 49 records, so I may just ask the cataloging center to fix them.
16:34 Dyrcona Now, I want to make t-shirts and wrist bands with "WWJSD" on them: What would Jon Skeet do?
16:36 Dyrcona I'm tempted to stuff this code into my private scripts repo anyway.
16:40 Dyrcona I can still use my program. After all, I can just denormalize the value that I want to put in. I just need to decide with the cat center what goes in the 347$b.
16:45 Dyrcona Anyway, that's it for now.
16:45 Dyrcona Have a great weekend, #evergreen!
17:07 mmorgan left #evergreen
18:02 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat