| 00:34 |
|
sandbergja joined #evergreen |
| 00:49 |
|
sandbergja joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live//archive/2021-04/2021-04-13_04:00:03/test.49.html> |
| 07:16 |
|
rjackson_isl_hom joined #evergreen |
| 08:21 |
|
rfrasur joined #evergreen |
| 08:37 |
|
mantis joined #evergreen |
| 12:10 |
|
jihpringle joined #evergreen |
| 12:27 |
* mmorgan |
is thinking bug 1923225 is a critical bug, do others agree? |
| 12:27 |
pinesol |
Launchpad bug 1923225 in Evergreen "ISBN display includes code in traditional catalogue" [Undecided,Confirmed] https://launchpad.net/bugs/1923225 |
| 12:27 |
mmorgan |
Here is a result from a 'concerto' search on abowling's test server: https://eg-master-test.emeralddata.net/eg/opac/record/92?query=concerto;qtype=keyword;locg=1;detail_record_view=0 |
| 12:32 |
jihpringle |
mmorgan: I agree it's critical since it's patron facing |
| 12:37 |
|
sandbergja joined #evergreen |
| 13:19 |
jeffdavis |
I haven't had a chance to investigate but I'm pretty sure the problem is that the display-field version of the ISBN is being run through the "|html" filter (or an equivalent thereof) too many times; avoiding the filter when it's a display field would be the fix |
| 15:10 |
JBoyer |
jeff++ |
| 15:10 |
jeff |
Are we looking at one each for xul and dojo, or combined, or whatever I decide? |
| 15:11 |
Dyrcona |
I'm OK with whatever you decide, jeff. |
| 15:11 |
JBoyer |
I think it may touch enough stuff that having 2 separate branches will cause more trouble merging / testing than it would save by having 2 slightly more focused branches. |
| 15:12 |
JBoyer |
And I just realized there's no english in the second half of that. |
| 15:13 |
Dyrcona |
Some features are going to require implementation in a different toolkit or be removed, so that could warrant multiple bugs/branches, but IDK. |
| 15:13 |
JBoyer |
I think merge conflicts and a general difficulty in getting branches tested means that 1 might be easier for all involved, is what I was trying to say. |
| 15:13 |
abowling |
JBoyer: it might have been a little clunky, but I think you established the point well enough |
| 15:14 |
Dyrcona |
Yeah, that makes sense, but I'm a bit wary of massive branches. |
| 15:14 |
JBoyer |
Dyrcona, I can see there being a separate branch for removing dojo (and xul) from this or that major section, but I don't think we should have this collection of branches to remove dojo and that collection to remove xul, for instance. |
| 15:36 |
gmcharlt |
agreed |
| 15:36 |
JBoyer |
Hurray for removing unnecessary duplicate calls though. |
| 15:36 |
JBoyer |
Any other release updates? |
| 15:37 |
gmcharlt |
a question: has anybody not-me tested the 3.6.2 to 3.7 schema update? |
| 15:37 |
Dyrcona |
gmcharlt: No, I haven't, but I have tried a 3.2.10 to 3.7 schema upgrade. It takes a long time. :) |
| 15:38 |
gmcharlt |
Dyrcona: but succeeded? |
| 15:38 |
Dyrcona |
Yeah, once that one update was removed. |
| 15:38 |
* phasefx |
noticed a qatest failure with geosort, will poke at that |
| 15:38 |
gmcharlt |
which update? |
| 15:39 |
Dyrcona |
I'm trying to remember. Hang on a sec. You dropped it, IIRC. |
| 15:39 |
JBoyer |
phasefx, I'm wondering if its a timeout or something weird about the environment, I ran some local tests and it was fine. |
| 15:39 |
jeffdavis |
gmcharlt: I've done 3.6.2-3.7 beta minus a couple big updates on real data, haven't tried the RC. |
| 15:39 |
JBoyer |
Dyrcona, gmcharlt : The materialized payment by billing type update |
| 15:39 |
Dyrcona |
Yeah, that's it. 1257 was the number. |
| 15:40 |
phasefx |
oof, I've lost my IRC-fu |
| 15:40 |
gmcharlt |
Dyrcona: jeffdavis: thanks. That's making me confident enough that SELECT randomize_marc_tags(); isn't part of the schema update |
| 15:41 |
* JBoyer |
cackles, "I have spelled it auditor.update_auditors(); Ha!" |
| 15:42 |
JBoyer |
I may also have a 3.6.2-ish db to test against tonight. |
| 15:42 |
JBoyer |
but if not it's just concerto, which I suspect would obviously work. |
| 15:43 |
JBoyer |
I think that and the clock takes us to new business. |
| 15:43 |
JBoyer |
#topic New Business |
| 17:02 |
miker |
FTR, the markup embedded in (highlighted) display fields has the intentional effect of properly escaping embedded would-be markup, so that normal CSS can be used to style. if a scheme is invented to allow that via some sort of templating instead of <span>s with @classes, we'll just need to remember that the angular catalog also uses CSS to style highlighting, so we'll need to teach it the same thing. |
| 17:25 |
|
mmorgan left #evergreen |
| 18:01 |
|
sandbergja joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:51 |
jeffdavis |
ugh |
| 18:52 |
jeffdavis |
I thought I fixed these display field/XSS issues |
| 18:53 |
|
jihpringle61 joined #evergreen |
| 04:49 |
|
jweston joined #evergreen |
| 04:49 |
|
gmcharlt joined #evergreen |
| 04:49 |
|
berick joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:24 |
|
rjackson_isl_hom joined #evergreen |
| 08:11 |
|
collum joined #evergreen |
| 08:29 |
|
mmorgan joined #evergreen |
| 11:15 |
* miker |
mumbles something about queued ingest and making imports faster and authority propagation possible... |
| 11:17 |
Dyrcona |
jeffdavis++ |
| 11:39 |
jeffdavis |
Disabling maintain_symspell_entries_tgr on *_field_entry tables does the trick. Now to try adding that flag... |
| 11:44 |
Dyrcona |
So, I'm writing Perl tests for Lp 1923076. Looks like I have it working for open-ils.actor.user.hold_requests.count. I'll go through miker's list and add tests for the backend calls. |
| 11:44 |
pinesol |
Launchpad bug 1923076 in Evergreen 3.6 "Incorrect typing when encoding some values as JSON" [Medium,Confirmed] https://launchpad.net/bugs/1923076 |
| 11:46 |
Dyrcona |
Using some the B module to determine if a value is an integer or not. |
| 11:46 |
Dyrcona |
Oops. Bad edit... |
| 11:47 |
jeff |
should we be testing that, or testing the result of the JSON encode? |
| 11:47 |
jeff |
(I don't know) |
| 11:56 |
Dyrcona |
jeff: The responses go through JSON encode in OpenSRF. Look at https://bugs.launchpad.net/evergreen/+bug/1923076/comments/2 and try the srfsh command (adding the missing comma after the authtoken). On an affected, but unpatched system, you'll see the responses are strings. |
| 11:56 |
pinesol |
Launchpad bug 1923076 in Evergreen 3.6 "Incorrect typing when encoding some values as JSON" [Medium,Confirmed] |
| 11:57 |
Dyrcona |
Meahwhile...It's lunch time for me. |
| 12:08 |
|
jihpringle joined #evergreen |
| 12:38 |
Dyrcona |
So, I think I've come across one that I can't test on concerto, but I'm pretty sure it needs a patch: open-ils.circ.hold.clear_shelf.process |
| 12:51 |
miker |
Dyrcona++ |
| 12:58 |
Dyrcona |
miker: There are a couple that I'm sure don't need fixes, but I'm unsure about this one: Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Driver/Pg/storage.pm:401: return scalar(@fm_nodes); |
| 12:59 |
Dyrcona |
I had trouble find a context where it is used, so I moved on. |
| 14:35 |
jeff |
(I don't think we should switch to Cpanel::JSON::XS right now.) |
| 14:36 |
jeff |
But it also supports passing an additional argument to encode_json, so you can write a spec of what your encoded JSON should look like. |
| 14:37 |
Dyrcona |
I think we should ditch Perl, tbh. Seems like every few years we play whack-a-mole with nonsense like this. |
| 14:44 |
Dyrcona |
I'm testing Cpanel::JSON::XS on buster. Looks like all of the necessary changes are limited to 1 file. |
| 14:46 |
Dyrcona |
I still get some numbers that are strings, but the superpage size one is fixed. I'm gonna see if my tests pass. |
| 14:47 |
Dyrcona |
The tests that I have written pass with Cpanel::JSON::XS on the unpatched buster VM. I think switching to Cpanel::JSON::XS is easier than ditching Perl. |
| 14:49 |
Dyrcona |
So, looking at the output of these tests and some other calls, I'd say we have bigger problems than calling scalar on empty arrays and passing the results through JSON::XS. |
| 14:54 |
jeff |
Do you mean that you think Cpanel::JSON::XS fixes more things than we were focusing on? |
| 14:56 |
Dyrcona |
Yes, I do, but it still isn't perfect. I'm updating the bug. |
| 14:57 |
* jeff |
nods |
| 17:00 |
jeff |
arguably, scalar(@empty-lexical) is the only place we've found change in behavior. |
| 17:13 |
jeff |
if we flip every numeric string to a JSON number, we'll probably shoot ourselves in the foot in one or two places. :-) |
| 17:15 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 21:07 |
|
jvwoolf1 joined #evergreen |
| 00:46 |
|
dbwells_ joined #evergreen |
| 03:05 |
|
dbwells joined #evergreen |
| 05:34 |
|
dbwells joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:25 |
|
rjackson_isl_hom joined #evergreen |
| 07:41 |
|
Dyrcona joined #evergreen |
| 07:42 |
Dyrcona |
typos-- |
| 10:50 |
Dyrcona |
I'm getting a numeric zero. |
| 10:58 |
jeff |
My understanding of why that is: the difference in behavior / characteristics is mostly in the Perl internals, which aren't available to Perl code. Things like Devel::Peek, B::*, and JSON::XS are perl extensions written in C which have access to the Perl API and can inspect the internals. JSON::XS uses this to try and treat simple scalar values correctly, but acknowledges that it's difficult. |
| 11:00 |
Dyrcona |
Yeah, well I was quickly getting into the elephant grass trying to chase a path through the Perl code itself. |
| 11:00 |
jeff |
In order to write a test case for my git bisect last night, I needed to redirect stderr to a string, so that when I called Devel::Peek::Dump() I could examine the output. |
| 11:01 |
Dyrcona |
So, when are we gonna ditch Perl? :P |
| 11:02 |
jeff |
Interesting. I don't think that the new value of scalar(my $lexical) is just any "0" with a string representation. That would be a SV = PV as shown with perl -MDevel::Peek -e '$str = "0"; Dump($str);' |
| 11:03 |
Dyrcona |
Admittedly, I need to get better at reading Devel::Peek output. |
| 11:06 |
* jeff |
nods |
| 11:07 |
jeff |
perlguts documents the various SV types |
| 11:08 |
Dyrcona |
On perl 5.26, it's PV = IV with or without my. |
| 11:09 |
jeff |
I think the first priority is to fix / work around the identified issues, then do a little looking to see if we have any other similar issues, and as/if time allows, gather some test cases and bring them to the attention of Perl hackers to see if this is something that needs any action on their part (fixing a bug, documenting the change in behavior, etc). |
| 11:09 |
Dyrcona |
perl -MDevel::Peek -e '@ar = (); $str = scalar @ar; Dump($str);' |
| 11:10 |
jeff |
There is a lot of elephant grass to go around. :-) |
| 11:11 |
Dyrcona |
And, I meant SV = IV when I typoed, PV = IV above, just for the logs. |
| 15:46 |
Dyrcona |
miker++ |
| 15:48 |
miker |
oh, I should mention, I also excluded all uses where the return value of scalar() was used inline with a numberish operator, like addition or multiplication, which forces numeric context and should be safe (per 0+ working) |
| 15:48 |
miker |
I basically limited the list to where it was not obviously safe |
| 15:59 |
JBoyer |
miker, I'm not so sure about your "I've excluded uses that are only used in truthiness tests..." from lp 1923076 , I got the impression that simply subjecting them to the testing might be enough to twiddle some bits in their storage and make them look string-y enough for JSON::XS. |
| 15:59 |
pinesol |
Launchpad bug 1923076 in Evergreen 3.6 "Incorrect typing when encoding some values as JSON" [Medium,Confirmed] https://launchpad.net/bugs/1923076 |
| 16:00 |
JBoyer |
Though I've mostly been at the edges of this discussion, if that's not what's actually happening that's great. |
| 16:00 |
miker |
JBoyer: oh, I mean like "if (scalar(@foo))" and the like |
| 16:07 |
gmcharlt |
as a general announcement: I'm planning on cutting 3.7-rc on Monday and the 3.7.0 release on Wednesday |
| 16:12 |
|
jvwoolf joined #evergreen |
| 16:26 |
|
akilsdonk_ joined #evergreen |
| 16:27 |
jeff |
miker: and just think, any times where we're testing an empty @lexical in a boolean context, it's ~314% faster because of the optimization present in Perl 5.28! |
| 16:32 |
|
mantis left #evergreen |
| 16:58 |
miker |
jeff++ |
| 17:17 |
|
mmorgan left #evergreen |
| 17:43 |
Dyrcona |
Correct > Fast. |
| 17:43 |
Dyrcona |
Perl-- |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:32 |
|
sandbergja joined #evergreen |
| 21:27 |
|
JBoyer joined #evergreen |
| 22:05 |
jeffdavis |
Lots of symspell-related deadlocks trying to import records in parallel on a 3.7 system |
| 00:00 |
|
sandbergja joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:18 |
|
rjackson_isl_hom joined #evergreen |
| 08:02 |
|
collum joined #evergreen |
| 08:29 |
|
mantis joined #evergreen |
| 11:51 |
|
jihpringle joined #evergreen |
| 11:56 |
|
dbwells joined #evergreen |
| 12:16 |
|
jamesrf joined #evergreen |
| 12:19 |
Dyrcona |
jeffdavis: Going to back to your thing with holds counts yesterday, it looks like the real culprit is open-ils.actor.user.hold_requests.count. I've only tested it on Perl 5.30 so far, and it returns the holds available count as a string. |
| 12:24 |
Dyrcona |
Seems bizarre that it would do that, though. The total field is returned as a number, and the way they're calculated *should* be functionally equivalent. |
| 12:24 |
Dyrcona |
I have a suspicion of how to fix it, though. |
| 12:25 |
jeffdavis |
I'm happy to test any ideas you might have. :) |
| 12:32 |
Dyrcona |
Hm... eg_db_config through some errors for me on Ubuntu 18.04. I need to check that before I can go on. |
| 12:35 |
Dyrcona |
OK. I have to install some prerequisites. |
| 12:43 |
Dyrcona |
In Perl 5.26 it's a number. That's really bizarre and must be some kind of Perl bug. |
| 12:43 |
|
dbwells joined #evergreen |
| 12:44 |
|
collum joined #evergreen |
| 12:50 |
Dyrcona |
And, it doesn't happen with a little Perl script intended to test the problem. so it's more complicated than it appears at first glance. |
| 12:54 |
Dyrcona |
So, my "fix" resolves it, but I think it's just patching over the real problem, which I suspect is buried in OpenSRF somewhere. I was not able to reproduce the behavior with a simple Perl script. |
| 12:55 |
Dyrcona |
We should have to go adding int() around all of our uses of scalar(@array)... |
| 12:56 |
Dyrcona |
s/should/shouldn't/ |
| 13:13 |
Dyrcona |
Might be it. I'll see if I can find where we use JSON to turn off allow_nonref. |
| 13:14 |
jeffdavis |
Seems like it might only be an issue where ready = 0? For a user with 1 or more holds ready, the result is an int rather than a string. |
| 13:15 |
Dyrcona |
I don't think that's it after reading the documentation, unless there's a bug with that setting. |
| 13:15 |
Dyrcona |
jeffdavis: I only tested with a handful of concerto patrons, none of whom turned out to have holds. |
| 13:16 |
jeff |
also interesting, https://metacpan.org/source/ISHIGAKI/JSON-4.03/Changes#L25 "allow PERL_JSON_PP_USE_B environmental variable to restore old number detection behavior for compatibility" |
| 13:17 |
Dyrcona |
We already turn allow_nonref on. |
| 13:17 |
jeff |
and: |
| 14:54 |
|
mantis joined #evergreen |
| 14:54 |
jeff |
I see a difference with Perl 5.32.1 with JSON::PP 4.04 vs JSON::XS 4.03. I see the documented behavior of scalars with a string context (where there's a PV and FLAGS includes PV/PVOK): the value is quoted. |
| 14:58 |
jeff |
Dyrcona: what version of JSON::XS are you running on your Ubuntu 18.04 system? |
| 15:02 |
Dyrcona |
jeff: This is Ubuntu 20.04 where I'm testing, the one that show the bug. |
| 15:02 |
jeff |
yep, got that. |
| 15:03 |
* jeff |
looks on packages.ubuntu.com |
| 15:03 |
Dyrcona |
Ubuntu 20.04 has 4.02 |
| 15:03 |
Dyrcona |
Ubuntu 18.04 has 3.02. |
| 15:04 |
Dyrcona |
I see the bug when I use srfsh to make the request, but trying to emulate what looks like the problematic code on 20.04 turns up nothing. |
| 15:04 |
Dyrcona |
I updated all packages before testing today. |
| 15:06 |
Dyrcona |
I have 5.32.1 on a FreeBSD server. |
| 15:07 |
pastebot |
"Dyrcona" at 168.25.130.30 pasted "Here's my latest test" (10 lines) at http://paste.evergreen-ils.org/10132 |
| 15:11 |
Dyrcona |
I get identical results on both Ubuntu servers with the above. I don't have Evergreen on the FreeBSD machine, so I won't test it there. |
| 15:12 |
Dyrcona |
Also, don't have JSON::XS on FreeBSD... |
| 15:12 |
Dyrcona |
I could install it, but this isn't a machine that I use for development. |
| 15:13 |
Dyrcona |
Maybe I should switch from ZZ Top to Jefferson Airplane.... :) |
| 15:15 |
mantis |
running 3.5.4 on a test server and images are failing to load in the catalog |
| 15:23 |
Dyrcona |
mantis: All images or just added content/book jackets? |
| 15:25 |
mantis |
content jackets |
| 15:26 |
mantis |
I'm not sure why that happened |
| 15:26 |
Dyrcona |
Did you configure the added content provider in opensrf.xml? |
| 15:26 |
Dyrcona |
I think that's where it goes.... |
| 15:36 |
jeff |
okay, I think I have a simple (yet still relevant) test that demonstrates a difference in behavior between Perl 5.26.3 and Perl 5.32.1, both with JSON::XS 4.03. I'm going to try and narrow down where it changes. |
| 15:38 |
Dyrcona |
jeff: Can you paste the test? I'd like to see it. |
| 15:38 |
mantis |
Dyrcona: thanks I'll take a look at it |
| 15:38 |
mantis |
Dyrcona++ |
| 15:39 |
|
mantis left #evergreen |
| 15:41 |
jeff |
here's the test and output under 5.26.3 and 5.32.1 so far, with some Devel::Peek Dump() output to help see where the flags are: https://gist.github.com/jeff/6ab1d188db2cd21ac1d45cf06544d7d2 |
| 15:42 |
jeff |
I'm installing 5.28 and 5.30 to help identify where the change was introduced. |
| 15:45 |
Dyrcona |
jeff: Interesting. My tests haven't done that. |
| 15:45 |
|
dbwells joined #evergreen |
| 15:48 |
miker |
oh, my, that's terrible if scalar() returns strings now |
| 15:49 |
jeff |
miker: not obvious in that simplified test, but it seems to only be when we have an empty array. |
| 15:50 |
Dyrcona |
Yeah, but I can't make it do that. jeff's test does for me, but my tests don't. |
| 15:53 |
jeff |
5.28.3 does it also. |
| 15:53 |
jeff |
updated gist with new output |
| 15:53 |
|
jihpringle joined #evergreen |
| 16:02 |
miker |
so do we just need to spell it 0+scalar(@bar) then? |
| 16:02 |
jeff |
> A new kind of magic scalar, called a "nonelem" scalar, has been introduced. It is stored in an array to denote a non-existent element, whenever such an element is accessed in a potential lvalue context. |
| 16:02 |
jeff |
but I'm not sold on that being related. |
| 16:04 |
miker |
changing jeff's test to that (cast to number by prepending 0+ ) "fixes" foo for me on 5.28 |
| 16:04 |
Dyrcona |
miker: int(scalar(...)) works, too. |
| 16:05 |
miker |
Dyrcona: yeah, either way ... s/scalar\(/0+scalar(/g in vim is easier though ;) |
| 16:06 |
Dyrcona |
What's weird is I'm not seeing it with the scripts that I pasted earlier. |
| 16:11 |
Dyrcona |
Also, looks like anyone using Debian Buster in production would see this, too. |
| 16:12 |
miker |
Dyrcona: I understand, I meant internal to opensrf perl code, not evergreen application code (looking for Worse Problems :) ) |
| 16:13 |
Dyrcona |
Right. |
| 16:16 |
jeff |
Dyrcona: that is interesting that your tests using OpenSRF libs aren't showing the problematic behavior. I modified one of your recent ones to use JSON::XS directly and it shows the same issue with the same versions (no surprise, since it's almost the same as one of my tests now): https://gist.github.com/jeff/a4fd184305f0a7870258040e3e3ce702 |
| 16:18 |
jeff |
"Various integer-returning ops are now more efficient in scalar/boolean context." |
| 16:18 |
jeff |
(also from perl5280delta) |
| 16:18 |
jeff |
"Converting a single-digit string to a number is now substantially faster." |
| 16:20 |
Dyrcona |
jeff: I didn't get it when I used the JSON::XS object interface, either. |
| 16:23 |
Dyrcona |
So, should we add this to Lp? |
| 16:24 |
miker |
jeff: "... faster, because it doesn't happen" ;) |
| 17:37 |
|
mmorgan left #evergreen |
| 17:46 |
jeffdavis |
Python 3 also makes installing translations "fun" on Ubuntu 20.04. |
| 17:46 |
jeffdavis |
Starting to wonder if we should stick with 18.04 for our upgrade. :( |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:42 |
|
sandbergja joined #evergreen |
| 19:45 |
|
dbwells joined #evergreen |
| 22:09 |
|
sandbergja joined #evergreen |
| 13:00 |
|
sandbergja joined #evergreen |
| 13:06 |
|
jamesrf joined #evergreen |
| 13:32 |
|
jihpringle joined #evergreen |
| 13:49 |
jeffdavis |
On my 3.7 beta test server, initial retrieval for any patron account results in a blank alert message - you get redirected to the Other tab with a STOP sign and the "Press a navigation button above (for example, Check Out) to clear this alert." message, but there is no alert. |
| 13:52 |
jeffdavis |
Test users are active, not expired/deleted/barred, card is active, no alert message, no standing penalties, no holds ready, no invalid addresses. Once the alert is cleared, it does not appear again for that patron. |
| 14:00 |
JBoyer |
jeffdavis, that sounds familiar. I've seen that happen when the number of holds available is formatted as a string rather than a number because 0 is false and "0" is true. |
| 14:00 |
JBoyer |
I thought there was a patch for that (unless this is a new instance of a similar issue) |
| 14:01 |
jeffdavis |
JBoyer++ |
| 14:47 |
|
dbwells joined #evergreen |
| 14:52 |
|
stephengwills joined #evergreen |
| 14:56 |
|
jihpringle joined #evergreen |
| 15:20 |
jeffdavis |
The test server where I'm seeing the issue is running Ubuntu 20.04. I tried installing the same OpenSRF/EG branches on an 18.04 server and cannot replicate the error there. |
| 15:21 |
jeffdavis |
(Perl v5.30.0 vs v5.26.1) |
| 15:22 |
|
jihpringle joined #evergreen |
| 15:29 |
rhamby |
r |
| 15:31 |
JBoyer |
No, I was definitely looking specifically at this ready_holds: "0" issue and more recently than that bug was last updated, but I'm having a hard time finding *where* I was looking at it. :( |
| 16:31 |
Dyrcona |
Oh well, time's up. I'll have a look tomorrow. I suspect it had more to do with Ubuntu 20.04 than the version of Evergreen. |
| 16:57 |
|
jvwoolf left #evergreen |
| 17:32 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live//archive/2021-04/2021-04-06_16:00:02/test.29.html> |
| 19:36 |
|
sandbergja joined #evergreen |
| 22:01 |
|
sandbergja joined #evergreen |
| 23:04 |
|
jamesrf joined #evergreen |
| 00:07 |
|
khuckins joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:37 |
|
jeff joined #evergreen |
| 07:15 |
|
khuckins joined #evergreen |
| 07:18 |
|
rjackson_isl_hom joined #evergreen |
| 09:09 |
|
alynn26 joined #evergreen |
| 09:15 |
|
jvwoolf joined #evergreen |
| 09:33 |
|
mmorgan1 joined #evergreen |
| 09:56 |
mantis1 |
A library staff member contacted me recently asking if we have a new feature. They are finding that when searching for a title after logged into the opac, they will get a "I have checked this out before" note in the results. I'm trying to replicate on my end but unsure what features need to be enabled to see this. I enabled circ history and checked out/in a few test items, searched for them, but won't find the note. |
| 10:09 |
collum |
mantis1 - There is a setting in the Library Settings Editor entitled "Tag Circulated Items in Results" that needs to be set to true, as well. |
| 10:26 |
mmorgan1 |
collum++ |
| 10:27 |
* mmorgan |
was looking for that but failed to find it :) |
| 11:39 |
mantis1 |
collum ++ |
| 11:49 |
Dyrcona |
collum++ |
| 12:24 |
|
jihpringle joined #evergreen |
| 13:25 |
jeffdavis |
Dyrcona: new fix incoming for that security bug, just testing now |
| 13:30 |
csharp |
jeffdavis++ |
| 13:31 |
Dyrcona |
jeffdavis++ |
| 13:57 |
miker |
jeffdavis: I have not had a chance to look at it in detail, but, I assume it does not break search result highlighting? |
| 16:32 |
|
Guest76203 joined #evergreen |
| 17:17 |
|
jvwoolf left #evergreen |
| 17:26 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:39 |
|
khuckins joined #evergreen |
| 20:40 |
|
sandbergja joined #evergreen |
| 21:43 |
|
sandbergja joined #evergreen |
public.localhost seems to work