| 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> |
