| Time |
Nick |
Message |
| 00:11 |
|
jvwoolf joined #evergreen |
| 01:42 |
|
sandbergja joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:20 |
|
rjackson_isl_hom joined #evergreen |
| 07:29 |
|
rfrasur joined #evergreen |
| 07:50 |
|
Dyrcona joined #evergreen |
| 08:00 |
JBoyer_ |
claiming 1201 to the chagrin of all of many CSS experimenters |
| 08:00 |
JBoyer |
and English teachers, judging by that last sentence. |
| 08:08 |
|
alynn26 joined #evergreen |
| 08:15 |
pinesol |
[evergreen|Rogan Hamby] LP1849683: Permission for custom css setting - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3b9b5e7> |
| 08:15 |
pinesol |
[evergreen|Jason Boyer] LP1849683: i18n and space supplement - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f11b235> |
| 08:15 |
pinesol |
[evergreen|Jason Boyer] LP1849683: Stamp upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=da42d56> |
| 08:16 |
|
Dyrcona joined #evergreen |
| 08:26 |
|
alynn26_away joined #evergreen |
| 08:30 |
|
Stompro joined #evergreen |
| 08:31 |
|
mantis1 joined #evergreen |
| 08:34 |
|
AFloyd__ joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 08:43 |
|
mmorgan1 joined #evergreen |
| 08:52 |
|
alynn26 joined #evergreen |
| 09:03 |
|
dbwells joined #evergreen |
| 09:28 |
|
alynn26_away joined #evergreen |
| 09:42 |
|
jvwoolf1 joined #evergreen |
| 10:01 |
|
annagoben joined #evergreen |
| 10:18 |
|
alynn26_away joined #evergreen |
| 10:34 |
|
AFloyd__ joined #evergreen |
| 10:37 |
|
jvwoolf joined #evergreen |
| 10:48 |
|
dluch joined #evergreen |
| 10:55 |
dbs |
Ran into a neat error, looks like with web sockets, now that people are working from home with a wide variety of routers/firewalls/extensions: Failed to load resource: net::ERR_QUIC_PROTOCOL_ERROR.QUIC_TOO_MANY_RTOS |
| 10:56 |
dbs |
In Chrome of course. I suggested the following possible solutions and will update once I hear back on what worked: https://kinsta.com/knowledgebase/err_quic_protocol_error/#fix |
| 10:57 |
berick |
good to know |
| 10:57 |
|
agoben joined #evergreen |
| 10:59 |
|
annagoben joined #evergreen |
| 11:00 |
|
agoben joined #evergreen |
| 11:01 |
dbs |
meh, looks like it might be an entirely unrelated Hangouts error |
| 11:02 |
* berick |
implements Websocket-Over-Teams |
| 11:05 |
dbs |
Trying to debug why a few people occasionally get "loading..." screens that never actually load on the reports interface and the catalogue. sigh |
| 11:19 |
dbs |
Hmm: iframeResizer.min.js:8 [iFrameSizer][Host page: iFrameResizer0] IFrame has not responded within 5 seconds. Check iFrameResizer.contentWindow.js has been loaded in iFrame. This message can be ingored if everything is working, or you can set the warningTimeout option to a higher value or zero to suppress this warning. |
| 11:25 |
|
jihpringle joined #evergreen |
| 11:29 |
dbs |
Might try simulating a really slow network connection using the network dev tools to see if I can reproduce that. |
| 11:43 |
* dbs |
sets network to 20kp/s download, latency 500ms, cache disabled, and sees staff catalogue expected to take 6 minutes to load - heh |
| 11:55 |
Dyrcona |
I have some tin cans and string if that will help. :) |
| 11:58 |
dbs |
Estimate eventually climbed to over 16 minutes to load, I think I throttled a bit too much :) |
| 12:02 |
Dyrcona |
Maybe... I don't know of anyone still using a 14.4K modem... |
| 12:03 |
Dyrcona |
They must have 56.6K, at least.... |
| 12:09 |
|
khuckins joined #evergreen |
| 12:13 |
|
rjackson_isl_hom joined #evergreen |
| 12:15 |
dbs |
well with more reasonable throttling, I can reproduce the iFrameResizer warning but not the never-ending "Loading...". bah |
| 12:21 |
dbs |
interesting though, my warning spells "ignored" correctly, while the bug report spells it "ingored" |
| 12:22 |
dbs |
Maybe they have a really old version of the files still cached somehow? |
| 12:31 |
* dbs |
suggests the F12, network tab, disable cache trick |
| 12:35 |
dbs |
Might be handy to add a build version console.log() message into our compiled JS so we can check that more readily |
| 12:35 |
dbs |
build version/build date stamp |
| 13:30 |
dbs |
yep, cached files were the issue |
| 13:32 |
Dyrcona |
Not surprising. |
| 13:33 |
Dyrcona |
Cache causes a lot of "fun" particularly around upgrades. |
| 13:43 |
dbs |
Yeah. The last update I applied was in January, but the 1-year cache had already taken effect |
| 13:44 |
|
alynn26 joined #evergreen |
| 13:57 |
|
jyorio joined #evergreen |
| 14:07 |
|
mantis1 joined #evergreen |
| 14:17 |
|
mrisher joined #evergreen |
| 14:35 |
|
mantis1 joined #evergreen |
| 14:50 |
|
Dyrcona joined #evergreen |
| 15:18 |
|
alynn26_away joined #evergreen |
| 15:19 |
* Dyrcona |
has a suspicion that bug 1869896 is going nowhere. |
| 15:19 |
pinesol |
Launchpad bug 1869896 in Evergreen "Barcodes should be case insensitive " [Undecided,New] https://launchpad.net/bugs/1869896 |
| 15:20 |
Dyrcona |
And, for user names, it will be fun trying to decide who gets to keep their user name and who has to change. Of course, you could decide to do away with them and just patron barcodes.... |
| 15:21 |
Dyrcona |
"I am not a number! I am a free man!" |
| 15:24 |
|
jvwoolf joined #evergreen |
| 15:30 |
jeff |
release notes should probably spell out that UPDATE_ORG_UNIT_SETTING.opac.patron.custom_css is just another way of granting EVERYTHING, right? or am I missing something? |
| 15:31 |
jeff |
(re bug 1849683) |
| 15:31 |
pinesol |
Launchpad bug 1849683 in Evergreen "CSS From Library Setting Needs to have permissions " [Medium,New] https://launchpad.net/bugs/1849683 |
| 15:32 |
jeff |
and/or bug 1849152 |
| 15:32 |
pinesol |
Launchpad bug 1849152 in Evergreen "Being able to set custom CSS from a Library Setting " [Wishlist,Fix committed] https://launchpad.net/bugs/1849152 |
| 15:34 |
|
mantis1 left #evergreen |
| 15:37 |
jeffdavis |
jeff: are you referring to the risk of a user with that perm embedding malicious code in the OPAC, or something else? |
| 15:39 |
jeff |
yes, that. |
| 15:42 |
jeffdavis |
Perhaps something more than a warning in the release notes is advisable. |
| 15:43 |
Dyrcona |
Perhaps yanking it? |
| 15:44 |
jeff |
Locally, we'll just exclude that part of base.tt2 |
| 15:44 |
Dyrcona |
I don't trust anyone to add css to the OPAC, but, well, me. So I won't be granted that permission. |
| 15:45 |
Dyrcona |
s/ed/ing/ |
| 15:45 |
alynn26_ |
I'm with Dyrcona on this. There is too much to mess up. |
| 15:46 |
jeff |
And I don't think the perm is granted to any groups by default, but that's a big foot gun lurking. |
| 15:47 |
Dyrcona |
Well, it shouldn't be granted to anyone by default, but those with EVERYTHING will have it. |
| 15:48 |
Dyrcona |
I suppose I can trust that group not to add CSS via a setting. |
| 15:49 |
Dyrcona |
It doesn't sound like a bad idea until you realize.... |
| 15:49 |
alynn26_ |
Who is all in that group. :P |
| 15:54 |
jeffdavis |
We'll suppress that line in base.tt2 locally too, which makes me think we need a different implementation of the feature. I can open a security bug once I confirm the issue. |
| 15:57 |
JBoyer |
I don't have strong feelings about the css feature itself, but until bug 1849152 went in, there was no gate at all. (also my fault, admittedly; but I didn't want a release to include the setting without the permission.) |
| 15:57 |
pinesol |
Launchpad bug 1849152 in Evergreen "Being able to set custom CSS from a Library Setting " [Wishlist,Fix committed] https://launchpad.net/bugs/1849152 |
| 16:00 |
JBoyer |
(my point being that if the whole feature gets yanked pre-3.5 removing those commits is definitely not enough) |
| 16:03 |
jeffdavis |
For sure the permission is necessary if the feature is there at all. |
| 16:03 |
jeff |
looking back at when I originally raised the issue, I'm reminded that there is also bug 1849113 |
| 16:03 |
pinesol |
Launchpad bug 1849113 in Evergreen "Add the ability to have jQuery from a library setting" [Wishlist,New] https://launchpad.net/bugs/1849113 |
| 16:11 |
jvwoolf |
So, just to confirm, 245 c is not searched when searching by author by default? |
| 16:16 |
|
jihpringle joined #evergreen |
| 16:22 |
|
mrisher joined #evergreen |
| 16:23 |
jeffdavis |
jvwoolf: I think that's correct - 245$c ends up in a "note" element in the MODS32 version of the record, and the default author index definitions don't index that element |
| 16:24 |
mmorgan |
jvwoolf: Yes, that is true by default |
| 16:25 |
jvwoolf |
Thanks, that's what I thought. Anybody have luck adding that search? |
| 16:26 |
jvwoolf |
I tried adding it as a Data Field for "All Creators" but that doesn't seem to have worked. |
| 16:26 |
jvwoolf |
Is it because there's an XPATH defined? |
| 16:33 |
mmorgan |
jvwoolf: I have to run, but have a look at bug 1822875 |
| 16:33 |
pinesol |
Launchpad bug 1822875 in Evergreen "OPAC titles are truncated when query string present" [Undecided,Confirmed] https://launchpad.net/bugs/1822875 |
| 16:34 |
|
mmorgan left #evergreen |
| 16:34 |
jeffdavis |
mmorgan++ |
| 16:34 |
jvwoolf |
mmorgan++ |
| 16:35 |
jeffdavis |
jvwoolf: if you want 245$c in author results specifically, I think you want field_class='author' rather than 'keyword' |
| 16:35 |
jvwoolf |
Huh |
| 16:35 |
jvwoolf |
Looks like we have that |
| 16:36 |
jvwoolf |
Unless it's not configured quite like this |
| 16:38 |
jeffdavis |
Can you paste what you've got? |
| 16:38 |
Dyrcona |
jvwoolf: What's happening in that bug basically boils down to display fields. You guys at Biblio have a work around. I've looked at NOBLE's, too, and neither is quite right for a general fix. |
| 16:40 |
jvwoolf |
Dyrcona: So having that workaround won't change the search? |
| 16:41 |
Dyrcona |
Shouldn't affect the search only the display. I have to admit I was AFK and didn't read everything you said. I'm responding more to mmorgan's suggestion of looking at that bug, and now I have to fly. |
| 16:42 |
Dyrcona |
Good luck! |
| 16:46 |
jvwoolf |
jeffdavis: https://pastebin.com/0sDPW04V |
| 16:48 |
jvwoolf |
I think our display is fine, it's just the search that isn't using the field |
| 16:48 |
jeffdavis |
jvwoolf: hm, yeah, that index def looks right to me |
| 16:49 |
jvwoolf |
Thanks. I'll poke in again tomorrow. I gotta run soon too. |
| 16:49 |
jvwoolf |
jeffdavis++ |
| 16:50 |
jvwoolf |
Dyrcona++ |
| 16:51 |
jeffdavis |
It's possible that records haven't been reingested since that index definition was added, which you could test by modifying a record to put some unique value in the 245$c, saving it (which should force a reingest on that record), then do an author search for your unique value. |
| 16:51 |
jeffdavis |
Beyond that, I have no immediate ideas. |
| 16:51 |
jeffdavis |
Good luck! |
| 16:54 |
|
mikerisher joined #evergreen |
| 17:30 |
|
jihpringle joined #evergreen |
| 18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:31 |
|
jihpringle joined #evergreen |
| 21:39 |
|
sandbergja joined #evergreen |
| 22:34 |
|
sandbergja joined #evergreen |
