| Time |
Nick |
Message |
| 01:24 |
|
jamesrf joined #evergreen |
| 03:14 |
|
sandbergja joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:16 |
JBoyer |
jeff++ # That's a good idea. |
| 07:37 |
|
littlet joined #evergreen |
| 07:49 |
|
agoben joined #evergreen |
| 07:56 |
jeff |
i wonder if just caching that stat cat call would be the best option. |
| 07:56 |
jeff |
(in memcached) |
| 08:23 |
jeff |
for us with a lot of stat cats the call takes about 4 seconds |
| 08:24 |
jeff |
i suspect it's all the overhead from subrequests, but we'll see. |
| 08:28 |
|
collum joined #evergreen |
| 08:40 |
|
bos20k joined #evergreen |
| 08:49 |
|
mmorgan joined #evergreen |
| 08:57 |
|
jamesrf joined #evergreen |
| 09:01 |
|
dbwells joined #evergreen |
| 09:13 |
|
aabbee joined #evergreen |
| 09:59 |
jeff |
We probably shouldn't allow a password reset request to be initiated using the barcode of an inactive card. |
| 10:00 |
* mmorgan |
would agree with that. |
| 10:08 |
|
StomproJ joined #evergreen |
| 10:38 |
dbwells |
berick: Testing the RC, and not seeing any search results in the experimental staff catalog. The search completes, the facets and counts load, I see the holdings fetches happening, but nothing gets drawn in the main area. Any thoughts on troubleshooting this? |
| 10:47 |
berick |
dbwells: that's different... |
| 10:47 |
berick |
console errors? |
| 10:47 |
dbwells |
not seeing any... |
| 10:49 |
berick |
does the pager load? can you navigate to the next page? |
| 10:49 |
dbwells |
Yes, the pager loads, but all the pages are blank. |
| 10:50 |
berick |
no idea on that. is there an RC branch I can install? |
| 10:50 |
|
sandbergja joined #evergreen |
| 10:51 |
jeff |
there is a tarball: https://evergreen-ils.org/downloads/previews/Evergreen-ILS-3.3.0.tar.gz |
| 10:51 |
berick |
ah, thanks jeff |
| 10:51 |
dbwells |
berick: It is just master with the build bits. |
| 10:51 |
berick |
k |
| 10:52 |
berick |
i'll start w/ master, see if I can reproduce there |
| 10:52 |
berick |
dbwells: browser? |
| 10:53 |
dbwells |
It is behaving the same in Chrome and Firefox. |
| 10:53 |
berick |
k |
| 10:55 |
|
sandbergja joined #evergreen |
| 10:56 |
berick |
no issues w/ master. i'll try the build. |
| 10:59 |
berick |
hm, build working fine too |
| 11:01 |
berick |
dbwells: last thing in the console is a list of calls to open-ils.circ.bre.holds.count ? |
| 11:02 |
dbwells |
berick: no, only thing is "Net: request open-ils.search.biblio.multiclass.query.staff" |
| 11:03 |
berick |
k, there should be a open-ils.pcrud.search.bre call after that, followed by the holds.count calls |
| 11:03 |
berick |
so.. |
| 11:03 |
berick |
what are you searching for? |
| 11:04 |
berick |
concerto data? |
| 11:04 |
dbwells |
yes, just the search term 'concerto' :) |
| 11:04 |
berick |
do any of the other catalogs work? |
| 11:06 |
dbwells |
The regular catalog works, if that is what you mean. |
| 11:06 |
dbwells |
Is there something else to try? |
| 11:06 |
berick |
yeah, just making sure it's not a back-end issue |
| 11:06 |
berick |
since they sue the same API for searching |
| 11:07 |
berick |
can you freely navigate other eg2 interfaces? |
| 11:07 |
dbwells |
It all feels pretty free |
| 11:08 |
dbwells |
It seems likely to be something wrong with our local install and not the code, but I'd love to figure out what. |
| 11:09 |
berick |
hm, so the pager works, which means the search call is returning... |
| 11:10 |
berick |
but then it never even tries to grab the bibs |
| 11:11 |
berick |
it uses the /opac/extras/unapi... stuff to grab the initial bib and holdings data |
| 11:11 |
berick |
i wonder if you see those calls hitting the apache/nginx access logs? |
| 11:12 |
berick |
e.g. GET /opac/extras/unapi?id=tag::U2 bre/30{holdings_xml}/CONS/0&format=holdings_xml ... |
| 11:15 |
berick |
also good to know if that URL produces results on your test machine |
| 11:25 |
|
sandbergja joined #evergreen |
| 11:27 |
dbwells |
berick: sorry, got pulled away. Yes I see those in the Network tab in chrome, and they appear to be working. |
| 11:31 |
berick |
k |
| 11:37 |
berick |
hm, but the call to request open-ils.pcrud.search.bre preceeds the unapi lookups |
| 11:40 |
jeff |
the pcrud lookups would probably all be under the same osrf-websocket-translator request entry in the Network tab of devtools. |
| 11:40 |
* jeff |
scrolls up |
| 11:41 |
berick |
the js console shows the network calls too |
| 11:42 |
berick |
well, the js console shows the osrf network calls |
| 11:43 |
jeff |
ah. |
| 11:44 |
jeff |
i noticed in scrolling up dbwells was talking console and not network tab. |
| 12:04 |
dbwells |
berick: okay, not sure how, but it appears my Console was filtered before. I am seeing more messages now. |
| 12:04 |
|
jihpringle joined #evergreen |
| 12:05 |
dbwells |
biblio.multiclass.query.staff, then facet_cache.retrieve, then pcrud.search.bre |
| 12:05 |
dbwells |
That's the end, I think for real this time. |
| 12:06 |
berick |
ok, good, that at least makes mores sense. |
| 12:07 |
dbwells |
It feels like a timing/promise resolution issue, but I can't easily see where. |
| 12:08 |
dbwells |
Or, again, maybe just something not right with our setup. |
| 12:09 |
dbwells |
berick: One other odd symptom, possibly unrelated. Occasionally, the facets do not load, or it appears that they load, then disappear. |
| 12:09 |
dbwells |
I can't reproduce it, but it has happened 3-4 times in testing this morning. |
| 12:09 |
berick |
dbwells: i have actually seen that one. |
| 12:10 |
berick |
same here, difficult to reproduce |
| 12:10 |
berick |
as far as the records go, all I can suggest at this point is adding console logs :( |
| 12:10 |
berick |
i can make suggestions if you want |
| 12:12 |
dbwells |
Sure, if you don't mind. You know your way around much better than I. |
| 12:12 |
berick |
yeah, i'll push a working branch, sec |
| 12:24 |
berick |
dbwells: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/ang-cat-debug-3.3 |
| 12:25 |
dbwells |
berick++ |
| 12:33 |
dbwells |
berick: I do not see any errors. I also do not see "Init result record component" or "fleshSearchResults() 2". Everything else comes through. |
| 12:34 |
berick |
ok... |
| 12:37 |
* berick |
adds more logs |
| 12:38 |
dbwells |
berick: Actually, see one thing out of whack. idx is always -1 in "fetched summary for record index" |
| 12:40 |
berick |
aha |
| 12:40 |
berick |
ok, i was just digging around in that part |
| 12:41 |
berick |
i bet somewhere it's expecting a number and getting a string |
| 12:42 |
* berick |
tries another patch |
| 12:44 |
berick |
dbwells: pushed another commit |
| 12:44 |
berick |
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=196ec9be16faa0ab8ac5707e6c54fb338bada234 |
| 12:45 |
dbwells |
berick: Unfortunately, I need to be afk for most of the afternoon. Thank you for all the help, but I'll need to leave you hanging in suspense for a while. Try not to think about it too much :) |
| 12:45 |
berick |
dbwells: yeah, no worries. |
| 12:45 |
* berick |
needs some food anyway |
| 12:45 |
berick |
thanks for helping me track it down |
| 13:55 |
jeffdavis |
How are people indicating in the OPAC that an item is in-library use only? Do you use a custom copy status, rely on descriptive copy locations...? |
| 13:55 |
jeffdavis |
I've had a request to create a new copy status for this and I wonder if that's the best solution. |
| 13:56 |
bshum |
With adding any new status, I've always been wary since it affects circulation/holds code logic |
| 13:57 |
JBoyer |
It's also very easy to lose via checkin, etc. |
| 13:58 |
JBoyer |
Locations are much stickier and hopefully more likely to be noticed. |
| 13:58 |
mmorgan |
jeffdavis: We created such a status early on. Our libraries use it and it serves the purpose, but as JBoyer said, it's easily cleared. |
| 14:00 |
mmorgan |
Our libraries didn't think a location code was sufficient. Available status tended to imply that it was available to check out. |
| 14:01 |
jeffdavis |
I think that's the motivating concern here too. |
| 14:03 |
mmorgan |
We have been using the home grown status Library Use Only for 7 years, so I think I can say with confidence nothing will blow up :) |
| 14:03 |
jeffdavis |
heh, that's good to know :) |
| 14:04 |
jeffdavis |
Thanks all for the answers! |
| 14:11 |
jeff |
Hrm. The (3.1, at least) web staff client seems to lack a way to print Items Out, even though there's a template for it. Am I missing something? |
| 14:13 |
mmorgan |
jeff: Print Item Receipt under Actions menu? |
| 14:15 |
jeff |
Yeah, just discovered... I need to select all items then right-click one and choose Print Item Receipt. |
| 14:23 |
|
sandbergja joined #evergreen |
| 15:00 |
jeff |
File this next one under: interesting things you break while trying to break something else. |
| 15:03 |
jeff |
You can't check items out to a patron whose primary card is not active (item barcode input is disabled). If you retrieved that patron via another active card, or via patron search, there's not even a warning to point you in the general direction of the card being the problem. |
| 15:04 |
jeff |
Also, the See All cards interface doesn't seem to trip the "unsaved data" warning. |
| 15:04 |
* jeff |
looks into what's required to fix that |
| 15:46 |
|
_bott_ joined #evergreen |
| 16:15 |
dbwells |
berick++ # latest patches are working |
| 16:15 |
berick |
dbwells: yay! |
| 16:16 |
berick |
let me know if you want me to re-push / sign off, etc. |
| 16:17 |
dbwells |
berick: What isn't clear to me yet is why it wasn't a problem for you today, or me before today. Any pointers on that? |
| 16:19 |
berick |
dbwells: i think there's just wiggle room w/ how numbers are encoded as json from the server (string vs. number) |
| 16:20 |
berick |
depending on which passages the data travels in its route |
| 16:21 |
berick |
it may or may not get coerced to/from one or the other |
| 16:25 |
berick |
csharp: remember recently we came to the conclusion you had to copy Angular --prod builds to all bricks for consistency? I think that's not in fact true. as long as the files are identical, the hashing algorithm should produce matching hashes on all servers |
| 16:25 |
berick |
just confirmed on a 2-brick setup |
| 16:25 |
berick |
both have identical files |
| 16:25 |
dbwells |
berick: Thanks. So do you think there is a more root cause/solution to this? |
| 16:27 |
berick |
dbwells: no, and it's not really a new problem. we've had similar issues in the JS side specifically with array.indexOf(...) |
| 16:27 |
berick |
which for whatever reason (speed I assume) JS uses === for the comparisons in indexOf(), which can be unexpected |
| 16:28 |
dbwells |
I guess it is just the inconsistency and unpredictability in this case which has me feeling uneasy. |
| 16:29 |
berick |
right, consistency just has to be enforced in the client |
| 16:31 |
* dbwells |
abides |
| 16:34 |
berick |
csharp: hm, though I suppose if you are rolling updates out and a client gets the index.html file of an updated brick, then attempts to grab a hashed file from a not-yet-updated brick, it wouldn't find it. that could be problematic and I bet it's what was happening in your case. |
| 16:39 |
csharp |
berick: thanks for the update - I haven't experimented with it since I tried it a few weeks ago |
| 16:48 |
berick |
csharp: heh, yeah, thought I had good news, but just found other challenges ;) |
| 16:49 |
berick |
i mean, problitunities |
| 16:58 |
csharp |
berick++ |
| 17:01 |
JBoyer |
berick++ |
| 17:04 |
mmorgan |
berick++ |
| 17:04 |
|
mmorgan left #evergreen |
| 17:20 |
|
nfBurton joined #evergreen |
| 17:21 |
Bmagic |
I have evidence in my system showing that an item went from available to checked out but there isn't a circulation for it. The last time it was circed was Janruary, but the auditor table claim that the item status went to checked out in March..... How is that possible? |
| 17:24 |
nfBurton |
ILS ghosts |
| 17:24 |
nfBurton |
That's really odd |
| 17:24 |
Bmagic |
no doubt |
| 17:28 |
Bmagic |
If you mark something lost after* it was checked in, will the system first move the item into checked out, then mark it lost in order to facilitate the billing properly? |
| 17:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:32 |
jeff |
Bmagic: any clues in the auditor tables with regard to the audit user or audit workstation? |
| 17:32 |
Bmagic |
those are blank, however, the editor column is populated with a staff account |
| 17:32 |
Bmagic |
my theory is that someone marked it lost (somehow) after it was checked in |
| 17:33 |
Bmagic |
but that theory is bunk if the system doesn't make a pitstop at checked out under that workflow |
| 20:11 |
jeff |
Bmagic: what other attributes on the audit entry are different from the current state of the copy? |
| 20:11 |
jeff |
if we rule out a direct database update or quirk of migration, other potentials may include: |
| 20:11 |
jeff |
(theories, untested) |
| 20:12 |
jeff |
templates can set a status. the "don't let a copy be placed in/out of a special status" is a weak client-side limitation. |
| 20:13 |
jeff |
i'm not aware of any common cases where a not-checked-out item could be marked lost, and i don't think anything in mark-lost related code sets a copy status to checked out. |
| 20:14 |
jeff |
Bmagic: no aged circulations either? |
| 20:30 |
jeff |
Bmagic: do (or did) any of your org unit settings related to status set status of checked out? Item Status for Missing Pieces, Claim Return Copy Status, etc? |
| 20:38 |
jeff |
Bmagic: do you have a checkin copy alert that sets next status to checked out? :-) |
