| Time |
Nick |
Message |
| 01:49 |
|
dbwells joined #evergreen |
| 04:18 |
|
dbwells joined #evergreen |
| 06:49 |
|
dbwells joined #evergreen |
| 06:54 |
|
dbwells joined #evergreen |
| 06:56 |
|
dbwells joined #evergreen |
| 07:16 |
|
rjackson_isl_hom joined #evergreen |
| 07:31 |
|
Dyrcona joined #evergreen |
| 08:01 |
|
collum joined #evergreen |
| 08:12 |
|
rfrasur joined #evergreen |
| 08:22 |
rhamby |
Dyrcona - just saw it, out yesterday and ... merged |
| 08:22 |
|
collum joined #evergreen |
| 08:27 |
Dyrcona |
rhamby++ # I got the emails from github, before I checked here. |
| 08:27 |
Dyrcona |
typos-- :) |
| 08:27 |
* Dyrcona |
keeps seeing typos...typos everywhere. |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:51 |
|
alynn26 joined #evergreen |
| 09:04 |
|
collum_ joined #evergreen |
| 09:15 |
rhamby |
some people claim it's turtles all the way down, it's really just typos |
| 09:16 |
|
jvwoolf joined #evergreen |
| 09:19 |
Dyrcona |
heh. |
| 09:19 |
Dyrcona |
That explains a lot! :) |
| 09:41 |
JBoyer |
They don't even know they're misspelled! |
| 09:44 |
Dyrcona |
:) |
| 09:45 |
Dyrcona |
Speaking of. I did a case insensitive grep -R through the code looking for dojo and found some SHA hashes that match. I guess they don't know it's not Dojo. :) |
| 10:02 |
Dyrcona |
Heh. I feel like i should just copy and paste (See Appendix A.) into each section of my "what Evergreen interfaces use Dojo" document, because Appendix A is a list of the source files where Dojo is found. |
| 10:03 |
|
sandbergja joined #evergreen |
| 10:20 |
Dyrcona |
It's going to be interesting to see how we replace Dojo, particularly in the OPAC. |
| 10:47 |
|
mantis joined #evergreen |
| 11:17 |
|
dbwells joined #evergreen |
| 11:54 |
|
dbwells joined #evergreen |
| 11:54 |
|
jihpringle joined #evergreen |
| 12:51 |
|
collum 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:01 |
jeffdavis |
Yes, looks like open-ils.actor.user.opac.vital_stats.authoritative is returning holds.ready as a string: "0" (though holds.total is a number) |
| 14:04 |
|
dbs joined #evergreen |
| 14:08 |
JBoyer |
I thought I had a branch or a bug somewhere but my machines disagree with me. :/ |
| 14:23 |
jeffdavis |
bug 1774268 is a different issue but maybe what you're thinking of? |
| 14:23 |
pinesol |
Launchpad bug 1774268 in Evergreen 3.5 "webstaff UX: default hold notification preferences for patrons confusingly presented" [High,Fix released] https://launchpad.net/bugs/1774268 |
| 14:32 |
|
dbwells joined #evergreen |
| 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. :( |
| 15:41 |
jeffdavis |
Issue confirmed on another 20.04 server running 3.7ish. |
| 15:46 |
|
mantis left #evergreen |
| 16:00 |
Dyrcona |
jeffdavis: So, you get this just by looking up a patron? |
| 16:04 |
jeffdavis |
Dyrcona: yeah - go to Check Out and enter a patron barcode or double-click a row in patron search |
| 16:04 |
Dyrcona |
Are you using concerto or production data? (I plan to check with both, myself, but thought I'd ask.) |
| 16:08 |
jeffdavis |
One server with production data, another with a modified subset of production that we use for training. I don't have access to a 20.04 env where I can use concerto just now. |
| 16:10 |
Dyrcona |
I have two, at least. |
| 16:10 |
Dyrcona |
One, I can do either production or concerto, but the latter is faster to set up for master/3.7. |
| 16:13 |
Dyrcona |
Is open-ils.actor.user.opac.vital_stats.authoritative a new call? |
| 16:18 |
Dyrcona |
To answer my own question: No, it isn't, and it hasn't changed in a long time. |
| 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 |
