| 14:31 |
jeffdavis |
Sorry, recreate which aspect exactly? |
| 14:34 |
miker |
I mean, does that happen everywhere, or just on some workstations that attempt to use offline? |
| 14:35 |
miker |
IOW, could it be bad IndexedDB data in some browser instances? |
| 14:38 |
jeffdavis |
Myself and at least two other folks here are seeing it on separate workstations (all using Chrome on Windows or Ubuntu, connecting to the same test server). Clearing cache and local data doesn't help, the same org units are consistently missing from that one dropdown. |
| 14:41 |
jeffdavis |
I added some console logging to the reconstituteTree function in lovefield.js. Seems like the missing org units are in the list when it is initially retrieved by getListFromOfflineCache, but they are missing after the list is processed. |
| 14:41 |
jeffdavis |
I'll share a patch to show what I mean, one sec |
| 14:45 |
pastebot |
"jeffdavis" at 64.57.241.14 pasted "lovefield.js reconstituteTree logging" (22 lines) at http://paste.evergreen-ils.org/4436 |
| 14:50 |
jeffdavis |
the first log entry there, "log: %o", shows missing org units which do not appear in the second log entry, "tree: %o" |
| 15:03 |
|
abowling joined #evergreen |
| 17:49 |
Bmagic |
I see, ok. So how do I complete an invoice? From the PO interface, I can see "view invoices" and that pops a new tab with hardcoded search critera to the linitem id but the results are not clickable |
| 17:49 |
Bmagic |
I suppose I need to click on "View Invoices" at the top of the interface |
| 17:51 |
Bmagic |
berick++ |
| 18:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:43 |
|
abowling left #evergreen |
| 19:50 |
|
rlefaive joined #evergreen |
| 20:41 |
jeffdavis |
I almost understand the issue with bug 1770478 but trying to put it into words is not easy |
| 20:41 |
pinesol_green |
Launchpad bug 1770478 in Evergreen "Web Client: Offline Issue Affects System where child orgs have lower ID number than parent" [High,Confirmed] https://launchpad.net/bugs/1770478 |
| 20:41 |
jeffdavis |
the filter() call is indeed the source of our problem |
| 20:41 |
jeffdavis |
we iterate through the list of org units; for each entry in the list we call filter() on the full list |
| 20:42 |
jeffdavis |
filter() in turn iterates through the full list in order |
| 20:43 |
jeffdavis |
let's say item.id = 20 |
| 20:44 |
jeffdavis |
as filter() works through the list, it does this test on each org unit: kid[parent_field]() == item[pkey]() |
| 20:44 |
jeffdavis |
for org units where id < 20, that test will always return false |
| 20:45 |
jeffdavis |
because, roughly speaking, kid[parent_field]() is a function and item[pkey]() is not |
| 20:46 |
jeffdavis |
but where id >=20, kid[parent_field]() is an actual value rather than a function, so it will return the correct value (true if the parent_ou is 20, false otherwise) |
| 20:48 |
pastebot |
"jeffdavis" at 64.57.241.14 pasted "LP#1770478 console logging 3 - filter check" (13 lines) at http://paste.evergreen-ils.org/4478 |
| 20:49 |
pastebot |
"jeffdavis" at 64.57.241.14 pasted "LP#1770478 console logging 3 - filter check (output)" (8 lines) at http://paste.evergreen-ils.org/4479 |
| 20:50 |
jeffdavis |
I'm sure I'm not explaining the test failure quite right but the above console log output hopefully shows what I mean |
| 03:44 |
|
jaswinder joined #evergreen |
| 04:38 |
|
beanjammin joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:06 |
|
agoben joined #evergreen |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:35 |
|
rlefaive joined #evergreen |
| 08:41 |
|
rlefaive joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:56 |
csharp |
after a recent re-install of master on my testing server, I'm seeing several instances of this issue: https://stackoverflow.com/questions/41281515/possibly-unhandled-rejection-in-angular-1-6 and things like the "Item Status" view aren't loading |
| 08:57 |
csharp |
since I don't hear anyone else talking about it, I'm wondering if it's just me, but my test server is kind of dead in the water until I resolve this |
| 08:57 |
csharp |
from the symptoms, it looks like issues common to upgrading to angular 1.6 |
| 09:01 |
csharp |
hmm - normally I wouldn't celebrate something like this, but I just hit a white screen - hooray! |
| 09:05 |
|
Dyrcona joined #evergreen |
| 09:06 |
|
rlefaive_ joined #evergreen |
| 09:06 |
JBoyer |
csharp, Maybe we'll have to start pinning Angular versions to get semi-stable installations? :/ |
| 10:42 |
|
rlefaive joined #evergreen |
| 11:19 |
Dyrcona |
JBoyer | jeff: Turns out to be easy enough for my purposes: https://pastebin.com/per3f5QY |
| 11:24 |
JBoyer |
Dyrcona, that looks like that may be pretty handy. I was thinking about the last time someone asked about incoming payments for overdue vs lost which I absolutely hated. |
| 11:43 |
csharp |
JBoyer: I can confirm that your FF branch works fine (using web-ext) on my Fedora workstation - planning to test Windows in a VM next |
| 11:44 |
JBoyer |
Woo. |
| 11:44 |
JBoyer |
I can also toss out some anecdata that Hatch works fine with Java 10 since I forgot I had it installed on my laptop while fighting with this. |
| 11:45 |
csharp |
good |
| 12:46 |
|
mmorgan joined #evergreen |
| 14:16 |
|
yboston_ joined #evergreen |
| 14:17 |
|
gsams__ joined #evergreen |
| 14:36 |
pinesol_green |
[evergreen|Jane Sandberg] LP1766712: Add Scrollbar to Patron Search Permission Group Field - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=06fda6a> |
| 14:54 |
|
tlittle joined #evergreen |
| 15:38 |
|
mmorgan1 joined #evergreen |
| 16:02 |
pinesol_green |
[evergreen|Bill Erickson] LP#1740537 Transit dialog showing wrong branch - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0b3b42b> |
| 16:08 |
|
jaswinder joined #evergreen |
| 16:14 |
|
jaswinder joined #evergreen |
| 16:15 |
|
mmorgan joined #evergreen |
| 17:06 |
|
Dyrcona joined #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 17:39 |
|
abowling left #evergreen |
| 18:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:42 |
|
gsams__ joined #evergreen |
| 18:52 |
|
akilsdonk_ joined #evergreen |
| 19:59 |
|
JBoyer-alt joined #evergreen |
| 00:55 |
|
stephengwills joined #evergreen |
| 01:45 |
|
beanjammin joined #evergreen |
| 04:57 |
|
jaswinder joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Failed Log Output: osrfsys.log - Expected 3 errors but encountered 6. <http://testing.evergreen-ils.org/~live> |
| 07:14 |
|
gsams__ joined #evergreen |
| 07:16 |
|
agoben joined #evergreen |
| 07:19 |
|
rjackson_isl joined #evergreen |
| 07:24 |
|
JBoyer joined #evergreen |
| 07:30 |
|
jaswinder joined #evergreen |
| 07:34 |
|
collum joined #evergreen |
| 07:42 |
csharp |
JBoyer++ # FF Hatch - I'll test when I get a chance - sick and mostly off today |
| 07:42 |
JBoyer |
csharp++ |
| 07:43 |
JBoyer |
Lemon tea first, testing second. |
| 08:09 |
|
kmlussier joined #evergreen |
| 08:25 |
|
rlefaive joined #evergreen |
| 08:42 |
|
Dyrcona joined #evergreen |
| 17:05 |
|
mmorgan left #evergreen |
| 17:18 |
|
jaswinder joined #evergreen |
| 18:07 |
|
mllewellyn left #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:02 |
|
stephengwills left #evergreen |
| 19:03 |
|
jaswinder joined #evergreen |
| 19:22 |
|
jvwoolf1 joined #evergreen |
| 02:15 |
|
jonadab joined #evergreen |
| 04:39 |
|
abowling joined #evergreen |
| 06:20 |
|
jaswinder joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:37 |
|
kmlussier joined #evergreen |
| 07:47 |
|
rlefaive joined #evergreen |
| 08:08 |
|
rlefaive_ joined #evergreen |
| 10:53 |
kmlussier |
jeff: Thank you! Now I won't be able to shift responsibility for typos to anyone but me. |
| 10:54 |
mmorgan |
kmlussier: You can always blame the cat |
| 10:54 |
Dyrcona |
@blame the cat |
| 10:54 |
pinesol_green |
Dyrcona: the cat tests their code on the LIVE SERVERS, then blames the user. SAD! |
| 10:55 |
kmlussier |
If 'tests their code' = 'walks on keyboards' that is indeed a true statement. |
| 10:57 |
|
Christineb joined #evergreen |
| 11:02 |
|
yboston joined #evergreen |
| 11:19 |
|
abowling1 joined #evergreen |
| 11:51 |
|
khuckins joined #evergreen |
| 12:03 |
|
jaswinder joined #evergreen |
| 12:04 |
|
jihpringle joined #evergreen |
| 12:17 |
* csharp |
hires a cat to test his code |
| 12:21 |
bshum |
"Everybody wants to be a cat... because a cat's the only cat who knows where it's at..." /singsong |
| 12:25 |
kmlussier |
bshum++ |
| 12:25 |
* kmlussier |
will now have that song stuck in her head all day. |
| 16:06 |
|
jvwoolf joined #evergreen |
| 16:30 |
|
jvwoolf1 joined #evergreen |
| 16:38 |
|
sandbergja joined #evergreen |
| 16:50 |
jeffdavis |
Is anyone else seeing apache2-websockets processes maxing out CPU? |
| 16:52 |
jeffdavis |
I believe we've fixed instances of this before. I'm seeing it in production on 2.12, not so far in our 3.1 test environment. |
| 16:58 |
|
khuckins_ joined #evergreen |
| 17:01 |
|
sandbergja joined #evergreen |
| 17:02 |
|
mmorgan left #evergreen |
| 17:44 |
jeffdavis |
aha, thanks miker |
| 18:11 |
|
abowling1 joined #evergreen |
| 18:30 |
|
abowling joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:33 |
|
beanjammin joined #evergreen |
| 19:58 |
csharp |
6f1f2a4f |
| 19:58 |
pinesol_green |
csharp: [evergreen|Mike Rylander] LP#1676608: copy alert and suppression matrix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6f1f2a4> |
| 01:25 |
|
beanjammin joined #evergreen |
| 03:49 |
|
abowling joined #evergreen |
| 06:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:20 |
|
rlefaive joined #evergreen |
| 07:33 |
|
jaswinder joined #evergreen |
| 11:04 |
csharp |
gsams: no problem! |
| 11:04 |
gsams |
your patch does work though |
| 11:04 |
gsams |
I can confirm. |
| 11:05 |
csharp |
oh - cool - thanks for testing ;-) |
| 11:05 |
csharp |
gsams++ |
| 11:06 |
gsams |
No problem, I had made the same change on my end before I had thought to suggest it. I wasn't really sure if it was intentionally set that way or not. |
| 11:06 |
csharp |
ugh - I'm definitely catching this cold my family has been passing around while we were living it up in St. Charles :-/ |
| 11:07 |
gsams |
That was pre-conference me though, post-conference me will put it out there in the future. |
| 16:33 |
jaswinder |
thanks guys |
| 16:34 |
mmorgan |
Bmagic: Maybe lp 1736419 ? |
| 16:34 |
pinesol_green |
Launchpad bug 1736419 in Evergreen "Search Showing Bibs with no Holdings" [High,Fix released] https://launchpad.net/bugs/1736419 |
| 16:35 |
Bmagic |
my test machine with 3.0.7 on it works fine. Thanks yall - it's a BUG |
| 16:35 |
bshum |
Apparently 3.0.3 is the magic release number that fixes those things :) |
| 16:38 |
Bmagic |
3.0.3++ |
| 16:38 |
Bmagic |
for that matter |
| 17:52 |
|
abowling1 joined #evergreen |
| 17:56 |
|
rlefaive left #evergreen |
| 18:21 |
|
jvwoolf joined #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:45 |
|
jaswinder joined #evergreen |
| 18:51 |
|
jaswinder joined #evergreen |
| 19:25 |
|
jaswinder joined #evergreen |
| 01:19 |
|
yar joined #evergreen |
| 02:29 |
|
gmcharlt joined #evergreen |
| 02:38 |
|
jaswinder joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:39 |
|
jaswinder joined #evergreen |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 07:57 |
|
rlefaive joined #evergreen |
| 15:09 |
phasefx |
mutual increment society :D |
| 15:56 |
|
rlefaive joined #evergreen |
| 16:28 |
csharp |
@karma |
| 16:28 |
pinesol_green |
csharp: Highest karma: "bshum" (2), "phasefx" (2), "evergreen" (1), "csharp" (1), and "miker" (1). Lowest karma: "evergreen" (1), "csharp" (1), "miker" (1), "jeffdavis" (1), and "bshum" (2). You (csharp) are ranked 3 out of 6. |
| 16:33 |
|
beanjammin joined #evergreen |
| 17:01 |
|
mmorgan left #evergreen |
| 17:43 |
|
jaswinder joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:44 |
|
abowling1 joined #evergreen |
| 19:19 |
|
jaswinder joined #evergreen |
| 22:56 |
|
dbwells_ joined #evergreen |
| 02:16 |
|
beanjammin joined #evergreen |
| 02:45 |
|
dwgreen joined #evergreen |
| 02:58 |
|
jaswinder joined #evergreen |
| 06:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 08:00 |
|
idjit joined #evergreen |
| 08:02 |
|
bdljohn joined #evergreen |
| 17:25 |
jaswinde_ |
Hey Guys, I want to make an ajax to an api from ebook. Is there is document for that? |
| 18:05 |
jeffdavis |
jaswinde_: I don't know if there is documentation for that. You could look at the files in Open-ILS/web/js/ui/default/opac/ebook_api/ to see how it's currently done for other ebook vendors (although there may be better ways to achieve what you are trying to do). |
| 18:07 |
jaswinde_ |
jeffdavis: The current js files does not seem to do ajax calls. I wonder if we have existing libraries used somewhere that I can use |
| 18:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:51 |
|
jaswinder joined #evergreen |
| 18:53 |
bshum |
Bah, aircraft maintenance delays in Chicago |
| 18:54 |
jeff |
fun! |
| 00:41 |
|
beanjammin joined #evergreen |
| 02:13 |
|
jaswinder joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:14 |
|
jaswinder joined #evergreen |
| 07:29 |
|
tlittle joined #evergreen |
| 07:51 |
|
kmlussier joined #evergreen |
| 09:39 |
kmlussier |
abneiman: That's a thought. Thanks! |
| 09:47 |
miker |
kmlussier / abneiman: I'm pretty sure 260b is included because I asked a PINES cataloger "hey, if there's just no author field in a record, what should we include to disambiguate works with the same title?" back in 2004-ish |
| 09:49 |
kmlussier |
miker: In that case, then, we probably should include the 264b. But will the system grab the 700 author before it gets to 260? In my experience, it goes through the fields in the order they're on the MARC record. |
| 09:51 |
miker |
the intent is to get them in xpath order. it /used/ to do that, but I admit I haven't tested since we moved to the built-in xpath() function (in my defence, that's because it's the same code, just in core PG rather than an extension -- both versions use libxml2) |
| 09:52 |
miker |
it iterates through "|" separated expessions, executing each and returning the set returned by each. then we just take the first that comes out of the function |
| 09:53 |
miker |
also, +1 to 264b (or any other additions -- /still/ not a cataloger ;) ) |
| 09:53 |
kmlussier |
miker: It's been a couple of years since I've looked at it. I'll test it further to see if I can confirm what the current behavior is. |
| 09:54 |
kmlussier |
Also not a cataloger, though I did head a tech services department once for about a year. |
| 09:59 |
|
Christineb joined #evergreen |
| 10:08 |
csharp |
@quote search parties |
| 10:08 |
pinesol_green |
csharp: 1 found: #46: "<_bott_> I am not a cataloger, but I speak..." |
| 12:06 |
berick |
that sounds promising.. |
| 12:07 |
csharp |
so after removing the "allowed_origins" section and adding "allowed_extensions", it sees my printer |
| 12:07 |
berick |
nice! |
| 12:07 |
csharp |
and no more barfing in the background page |
| 12:12 |
csharp |
something's still not right because test print stuff is non-responsive, but I need a lunch break |
| 12:12 |
csharp |
might be a good thing to finish at the hackfest |
| 12:16 |
Bmagic |
charp++ |
| 12:16 |
Bmagic |
csharp++ even |
| 12:16 |
Bmagic |
speaking of karma |
| 12:17 |
berick |
csharp++ # indeed |
| 12:27 |
|
jihpringle joined #evergreen |
| 12:49 |
|
collum joined #evergreen |
| 13:07 |
csharp |
the print message successfully makes it to hatch.sh so I think my problem is at the OS level |
| 13:07 |
csharp |
I've had not-fun printing issues on Fedora for the last few releases |
| 13:08 |
csharp |
so, an apparently successful test of Firefox hatch! |
| 13:10 |
berick |
yay |
| 13:10 |
alynn26_away |
resistance++ |
| 13:20 |
|
jaswinder joined #evergreen |
| 13:30 |
|
jaswinder joined #evergreen |
| 13:43 |
jeffdavis |
csharp: did you force-push an update to user/csharp/lp1746300_fix_circ_counts_item_status_details a few days ago? |
| 13:43 |
jeffdavis |
also, |
| 13:43 |
jeffdavis |
csharp++ # hatch ffx testing |
| 13:49 |
jeff |
kmlussier, rhamby: if you didn't know, "sched" seems to be spamming twitter on your behalf. If you did know, well... then "spam" might be the wrong term. |
| 13:50 |
rhamby |
jeff: I sent out a single one from it, is it sending more than that? |
| 13:50 |
kmlussier |
jeff: Yes, you have to intentionally share to get sched to post to twitter. |
| 13:56 |
csharp |
jeffdavis: I had trouble creating the for loop that dbwells recommended from the XUL code and added some additional logic for handling a null value for one of the two possible rows from circbyyr |
| 13:57 |
csharp |
almost certainly not the most elegant approach, so if someone wants to correct it, I'm totally good with that (bug 1746300) |
| 13:57 |
pinesol_green |
Launchpad bug 1746300 in Evergreen "Item Status screen - Total Circs Current and Prev Incorrect" [Undecided,Confirmed] https://launchpad.net/bugs/1746300 - Assigned to Jeff Davis (jdavis-sitka) |
| 13:57 |
jeffdavis |
I think I ran into the latter case when testing last week, I'll try out the updated branch |
| 13:58 |
csharp |
cool |
| 13:58 |
csharp |
please let me know if you see trouble |
| 14:03 |
csharp |
found while exploring FF addon information: https://addons.mozilla.org/en-US/firefox/addon/the-laser-cat/?src=hp-dl-promo |
| 16:25 |
kmlussier |
miker: I'm hoping you can assist me with something. I'm logging long-running queries, well, actually, all sql queries so that I can grab the core query for a search. Things look different in 3.1. Could you tell me where I would find the core query in this paste? https://pastebin.com/E4aHbxHd |
| 16:25 |
kmlussier |
I thought it might be somewhere around "Completed canonicalized SEARCH IS", but I'm mostly just seeing queries for facets and for highlighting. |
| 16:30 |
* csharp |
closes out the day by mentioning my linked branch on bug 1731922 |
| 16:30 |
pinesol_green |
Launchpad bug 1731922 in Evergreen "Firefox add-on for Hatch" [Wishlist,Confirmed] https://launchpad.net/bugs/1731922 |
| 17:04 |
|
mmorgan left #evergreen |
| 17:49 |
|
jaswinder joined #evergreen |
| 18:24 |
|
jaswinder joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:57 |
|
jaswinder joined #evergreen |
| 21:35 |
|
jaswinder joined #evergreen |
| 01:50 |
|
jaswinder joined #evergreen |
| 05:50 |
|
jaswinder joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:52 |
|
agoben joined #evergreen |
| 06:52 |
|
JBoyer joined #evergreen |
| 07:17 |
|
rjackson_isl joined #evergreen |
| 10:26 |
|
dwgreen joined #evergreen |
| 10:27 |
Bmagic |
Is there a trick to running reports on a postgres replica? Sometimes we are getting "The row dissappeared" for long running reports |
| 10:34 |
|
bwicksall joined #evergreen |
| 10:38 |
bwicksall |
What version of Node.js should I have for Evergreen 3.0? Back when I setup my test server LTS was 6.X and now it is 8.11.1. I'm having some odd issues in the web staff client. |
| 10:38 |
JBoyer |
Bmagic, where are you seeing that and is it a postgres error or something from evergreen? |
| 10:38 |
Bmagic |
It's a postgres error that surfaces in the error message in the reporter GUI |
| 10:39 |
Bmagic |
FATAL: terminating connection due to conflict with recovery |
| 10:47 |
* bshum |
thinks we should revise that step |
| 10:47 |
bwicksall |
Yes, I'm following 4.1.1. |
| 10:48 |
bwicksall |
I'll try to roll back |
| 10:48 |
bshum |
6.14.1 should be fine, in theory. I think I tested up through 6.13 when I was poking around |
| 10:49 |
bshum |
But the makefile script is supposed to download 6.11.3 specifically |
| 10:49 |
|
kmlussier joined #evergreen |
| 10:49 |
bshum |
Which is considered "stable" from testing |
| 10:49 |
bwicksall |
Ok, se here is my problem. On the patron registration we are using org unit settings to hide alias. It will not hide on my test server. |
| 10:50 |
bwicksall |
Works find on my Equinox hosted live server |
| 10:50 |
JBoyer |
Bmagic, Yeah, I think those are what I was thinking of, but I didn't think hot_standby was necessary. May be. Setting those slightly longer than the timeout on your reports queries should prevent them from causing too much trouble. |
| 10:54 |
kmlussier |
Does anyone know why we include 260b in the author bit for the biblio fingerprint? |
| 10:55 |
bshum |
bwicksall: Hard to say then, might be code differences between versions (you said 3.0, but which .x point release is it) and whatever Equinox is running for your other instance |
| 12:44 |
jeff |
ah, there it is! |
| 12:44 |
kmlussier |
I'm guessing it would get used a lot with videos. But if it does make sense to continue to include the publisher, we would need to add the 264b |
| 12:44 |
dbs |
kmlussier: ours has the 260$b at the end |
| 12:45 |
kmlussier |
dbs: In the configuration? Yes, ours does too, but when I tested it a few years ago, the order in the config didn't seem to matter. |
| 12:45 |
dbs |
oooh, right, I see |
| 12:45 |
kmlussier |
Unfortunately, I don't have much time to look at it more closely now. I also found a record that made me think authors from the 700$a weren't being added at all. |
| 12:46 |
kmlussier |
Maybe something to explore further at the hackfest! :) |
| 16:59 |
|
jaswinder joined #evergreen |
| 17:02 |
|
mmorgan1 left #evergreen |
| 17:45 |
|
jaswinde_ joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 21:42 |
|
jaswinder joined #evergreen |
| 22:13 |
|
jaswinder joined #evergreen |
| 22:55 |
|
jaswinder joined #evergreen |
| 00:12 |
|
jaswinder joined #evergreen |
| 00:43 |
|
bshum joined #evergreen |
| 02:48 |
|
jaswinder joined #evergreen |
| 06:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:43 |
|
kmlussier joined #evergreen |
| 07:11 |
|
troy__ joined #evergreen |
| 07:14 |
kmlussier |
@coffee [someone] |
| 09:29 |
jaswinder |
thanks csharp! I will check out Actor class |
| 09:35 |
|
yboston joined #evergreen |
| 09:44 |
|
mmorgan1 joined #evergreen |
| 09:56 |
Bmagic |
I am finding that an email address that contains a period before the @ sign is ending up in the from address missing the ending domain name. for example: test.from from.com ends up being test.fromfrom |
| 09:56 |
bshum |
Stompro: That's an interesting find about the auditor.biblio_record_entry_history that you noted on that general email about upgrading |
| 09:57 |
bshum |
I think I've never noticed it because I'm building from scratch and the auditor function bases its creation on whatever exists at the time, so the new columns are fine for me in my test database. But I guess something should account for those new columns on upgraded systems :\ |
| 09:58 |
|
Christineb joined #evergreen |
| 10:01 |
Stompro |
bshum, there does seem to be a function that corrects the auditor tables so they match the source tables, so it probably is a simple fix... although I don't know how long it takes to add columns to huge tables, so it might be a more of a problem. |
| 10:02 |
bshum |
Stompro: I don't have a large database to test on anymore, but let us know what you discover :) |
| 10:02 |
bshum |
Stompro++ |
| 10:03 |
Stompro |
bshum, I also just noticed that the auditor table trigger is included in the ones to remove for the visibility update, so I guess that answers my question, it is something that is done. |
| 10:05 |
|
beanjammin joined #evergreen |
| 10:14 |
|
stephengwills left #evergreen |
| 11:04 |
|
idjit joined #evergreen |
| 11:09 |
|
tlittle joined #evergreen |
| 11:16 |
|
rlefaive joined #evergreen |
| 11:21 |
jaswinder |
I need to authenticate a user in test. I think to pass in the type of user. How do I determine the type of user from db? |
| 11:22 |
jaswinder |
for instance, staff, opac, etc |
| 11:28 |
|
eby joined #evergreen |
| 11:51 |
|
beanjammin joined #evergreen |
| 11:54 |
|
jwoodard joined #evergreen |
| 15:18 |
Bmagic |
jeff: no |
| 15:20 |
Bmagic |
during this research, I am a bit confused about the variable "lib" - it doesn't seem like it should work but apparently id does |
| 15:20 |
Bmagic |
the context is action.hold_request which doesn't contain a column "lib" |
| 15:20 |
jeff |
Bmagic: can you pastebin the template somewhere? if you hardcode the From: address as a test (in a test system / test template / whatever) do you see the same behavior? |
| 15:21 |
jeff |
Bmagic: generally you would have something in the template that sets lib, though the stock hold available notice doesn't do that. |
| 15:24 |
Bmagic |
so the lib variable (from the default template) is null and therefore skipped? Weird. The template does not set that variable |
| 15:25 |
jeff |
not seeing the weird part. the stock template neither defines nor uses 'lib'. i'm wondering what your template looks like. |
| 15:27 |
pastebot |
"Bmagic" at 64.57.241.14 pasted "sample template" (6 lines) at http://paste.evergreen-ils.org/3074 |
| 17:06 |
|
mmorgan left #evergreen |
| 17:21 |
|
jaswinder joined #evergreen |
| 18:29 |
|
jaswinder joined #evergreen |
| 18:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:09 |
|
jaswinder joined #evergreen |
| 20:14 |
|
jaswinder joined #evergreen |
| 20:23 |
|
jaswinder joined #evergreen |
| 00:46 |
|
stephengwills left #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:21 |
|
jaswinder joined #evergreen |
| 08:05 |
|
dwgreen joined #evergreen |
| 08:38 |
|
rjackson_isl joined #evergreen |
| 12:56 |
gsams |
kmlussier: I think ours were set for us, but I think I was really not part of that conversation at the time. |
| 12:58 |
* mmorgan |
was just looking at boundaries over the past week or so, but now realizes that the boundary is stored in the hold. So changing settings won't unbound existing holds. |
| 12:58 |
kmlussier |
mmorgan: Perhaps. If boundaries take that into consideration. |
| 12:59 |
gsams |
I just tested it, and it does indeed fix that particular issue. |
| 12:59 |
gsams |
I had to cancel and replace the hold as mmorgan is correct about the boundary being stored. |
| 12:59 |
gsams |
kmlussier++ |
| 12:59 |
gsams |
mmorgan++ |
| 13:00 |
gsams |
thanks for helping me understand these settings better. |
| 13:00 |
mmorgan |
gsams: Thanks for having the question at the same time I was trying to understand them myself! |
| 13:01 |
mmorgan |
gsams++ |
| 13:01 |
kmlussier |
gsams: I don't know if it's still helpful as there have been many changes in holds, but the results of our original holds testing were posted to the list. https://markmail.org/message/oesp74to5nkw64zt |
| 13:01 |
kmlussier |
This testing is what helped me understand boundaries a little better. |
| 13:04 |
|
jvwoolf1 joined #evergreen |
| 13:04 |
gsams |
kmlussier: Thanks, that might help me make some educated changes! |
| 13:06 |
Bmagic |
Can Evergreen sign outgoing emails with DMARC? |
| 13:12 |
kmlussier |
sigh...that moment when you follow the 3.1 readme for a 3.0 installation. |
| 13:14 |
jeff |
> Please complete registration within 240:00 minutes. |
| 13:30 |
Bmagic |
I assume that EDI messages from the vendor can cancel items automatically. I am trying to figure out where that is signaled in the message |
| 13:33 |
jeff |
I'm not even sure an hour had passed since I sent that search_path related email before something blew up in a test db here due to a search_path issue from... seven years ago. |
| 13:36 |
dbwells |
kmlussier: I am doing some wiki cleanup. Would it hurt anything for me to fix the typo in this link? (I am not sure what this page is for): https://wiki.evergreen-ils.org/doku.php?id=scrachpad:survey_help |
| 13:37 |
dbwells |
(scratchpad is missing the 't') |
| 13:37 |
dbs |
dbwells: if you fix the link, then it will no longer point to the same content |
| 17:55 |
|
b_bonner left #evergreen |
| 18:05 |
|
foobarrel joined #evergreen |
| 18:24 |
|
jaswinder joined #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Failed Log Output: osrfsys.log - Expected 3 errors but encountered 6. <http://testing.evergreen-ils.org/~live> |
| 19:17 |
|
dwgreen_ joined #evergreen |
| 21:06 |
|
jaswinder joined #evergreen |
| 21:57 |
|
jonadab joined #evergreen |
| 00:54 |
|
beanjammin joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:30 |
|
rjackson_isl joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:41 |
|
stephengwills joined #evergreen |
| 12:19 |
|
jvwoolf joined #evergreen |
| 12:42 |
|
jaswinder joined #evergreen |
| 12:45 |
|
jihpringle joined #evergreen |
| 13:12 |
pinesol_green |
[evergreen|Mike Rylander] LP#1745233: Don't test for LURIs during copy location searches - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=61d6e6c> |
| 14:50 |
|
remingtron joined #evergreen |
| 15:04 |
|
mmorgan1 joined #evergreen |
| 15:05 |
jaswinder |
Does anyone know how I can change user password? |
| 15:07 |
jaswinder |
It appears changing directly at table level (usr.password) does not work. |
| 15:10 |
dbwells |
jaswinder: usr.password is now a placeholder, as the passwords are kept in a separate table due to security related changes. |
| 15:11 |
jaswinder |
is there a way that I can change it. I need some test accounts and I want to change password for existing accounts |
| 15:11 |
dbwells |
jaswinder: take a look at actor.set_passwd() (a database function). It can probably help you out. Otherwise, change it in the client :) |
| 15:11 |
jaswinder |
okay thanks |
| 15:12 |
dbwells |
jaswinder: new passwords are now in actor.passwd, by the way |
| 18:30 |
dbwells |
Bmagic: If so, I'd be curious about your output for this in srfsh: |
| 18:30 |
dbwells |
request open-ils.circ open-ils.circ.fleshed.retrieve.authoritative <some precat circ id here> |
| 18:31 |
dbwells |
Particularly the "mvr" member of the top hash. |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:56 |
|
jaswinder joined #evergreen |
| 20:20 |
|
beanjammin joined #evergreen |
| 20:29 |
|
jaswinder joined #evergreen |
| 06:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:51 |
|
jvwoolf joined #evergreen |
| 07:50 |
|
rjackson_isl joined #evergreen |
| 07:50 |
|
rjackson_isl_ joined #evergreen |
| 12:45 |
dbs |
Down to 14 commits, not including tpac template variations. Much cleaner. |
| 12:46 |
Dyrcona |
dbs++ |
| 12:46 |
Dyrcona |
It's good to squash commit every now and then, but I suppose you made new ones? |
| 12:47 |
Dyrcona |
Is there a way to test EDI translator with the template_output from an event? |
| 12:48 |
Dyrcona |
I ask because we're getting this in email from EDI pusher: ERROR: attempt_translation failed for event 77147623, PO 22586, template_output 26832945 |
| 12:48 |
Dyrcona |
I have a suspicion what is wrong, but I'd like to confirm it. |
| 12:53 |
|
mmorgan joined #evergreen |
| 15:29 |
JBoyer |
s hard to say when the split showed up |
| 15:29 |
Bmagic |
ah, that explains why my grep command turned up bubkis |
| 15:40 |
|
kmlussier joined #evergreen |
| 15:49 |
kmlussier |
I was playing around with stop words on a test system. I was able to successfully configure postgres so that it doesn't index any words in my stopword dictionary. However, if a user enters the stopword, search doesn't ignore it. |
| 15:49 |
kmlussier |
Am I correct in assuming that development would be needed to get search to ignore any stop words entered as part of the query? |
| 15:50 |
kmlussier |
Also, I don't really want to implement stop words on a live system, so there's no need to tell me why I shouldn't use them. I'm just trying to see how it works. :) |
| 15:56 |
Dyrcona |
heh. |
| 15:58 |
dbs |
kmlussier: when you say "search doesn't ignore it", you mean something like the Perl code doesn't strip it out before it gets passed on to the SQL SELECT statement? |
| 15:59 |
kmlussier |
dbs: Yes, I guess so. |
| 16:02 |
dbs |
The reason we ignored searches for "canada" was because of the broad search timeout issue |
| 16:02 |
Dyrcona |
Yeah, that makes sense. |
| 16:03 |
berick |
kmlussier: have you confirmed having the stop word in the search affects the search? |
| 16:03 |
kmlussier |
berick: Yes, this is my test search - http://mlnc1.noblenet.org/eg/opac/results?query=girl+on+a+train&qtype=keyword&fi%3Asearch_format=&locg=1&detail_record_view=0 |
| 16:04 |
kmlussier |
Right now, the only words being indexed in the metabib title table are 'girl train' |
| 16:04 |
Dyrcona |
Nifty! |
| 16:05 |
Dyrcona |
"girl train" finds it. |
| 16:05 |
dbs |
huh. that's unexpected. |
| 16:05 |
Dyrcona |
"girl on a train" or "girl on the train" do not. |
| 16:05 |
kmlussier |
Dyrcona: Yes, so in that sense, I've actually made search worse by adding the stopword dictionaries. |
| 16:05 |
* dbs |
hasn't looked at the search code for a while but wonders if it's the relevancy test for phrase similarity |
| 16:06 |
Dyrcona |
Well, there's reason #1 not to use stop words. :P |
| 16:06 |
Dyrcona |
Don't mind me. :) |
| 16:06 |
dbs |
Yeah, there's something else going on there |
| 17:23 |
jeff |
It fails because the disk is too small to contain the unreasonably large swap partition it has decided to create. |
| 17:58 |
* jeffdavis |
learns the hard way that forcing a reingest on an unmodified existing record does not modify vis_attr_vector |
| 18:05 |
|
jvwoolf joined #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:35 |
stephengwills |
for future surfers: I dropped back to ubuntu 14.04 (Trusty) and the opensrf-2.4.2 installed perfectly. |
| 20:21 |
|
stephengwills left #evergreen |
| 20:33 |
|
jaswinder joined #evergreen |
| 00:37 |
|
beanjammin joined #evergreen |
| 04:17 |
|
jaswinder joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:07 |
|
jaswinder joined #evergreen |
| 07:20 |
|
rjackson_isl joined #evergreen |
| 07:46 |
|
dbwells_ joined #evergreen |
| 09:52 |
* dbwells |
doesn't know where "%paging" is coming from :) |
| 09:52 |
Dyrcona |
It's in an example on the first link you shared. |
| 09:52 |
Dyrcona |
Probably left over code? |
| 09:53 |
Dyrcona |
I *think* it would actually work if done like that, but I'd have to test. |
| 09:53 |
dbwells |
Ah, thanks. Yeah, not quite enough context there. |
| 09:54 |
jaswinder |
I see |
| 09:55 |
dbwells |
Yes, Dyrcona is right, a few lines before that in Account.pm you will find: my %paging = ($limit or $offset) ? (limit => $limit, offset => $offset) : (); |
| 10:39 |
* dbwells |
is not having a good connection day |
| 10:42 |
pastebot |
"dbwells" at 64.57.241.14 pasted "join filter attempt for jaswinder" (20 lines) at http://paste.evergreen-ils.org/2423 |
| 10:42 |
|
dwgreen joined #evergreen |
| 10:43 |
dbwells |
jaswinder: I usually need to do some fiddling with complex cstore/pcrud/json queries before I get them right, but that paste is a first draft. |
| 10:43 |
dbwells |
It is easiest to test such things iteratively in srfsh, I think. |
| 10:47 |
dbwells |
jaswinder: also, just to be clear, $my_home is just a made up variable for your '?' |
| 10:49 |
jaswinder |
yes |
| 11:03 |
jaswinder |
I just looked through the code to find any reference where I can filter the query by linked tables. Is there an example somewhere? |
| 11:04 |
dbwells |
jaswinder: Does my paste not work? It should be doing that. |
| 13:12 |
JBoyer |
both |
| 13:15 |
|
Christineb joined #evergreen |
| 13:20 |
|
beanjammin joined #evergreen |
| 13:22 |
* mmorgan |
is not seeing deleted bibs in staff client search results on a 3.0.3 test system. |
| 13:24 |
JBoyer |
I've pulled out the query sent to the db to look it over, nothing looks terribly out of place. no source on the bib, no vis_attr_vector, etc. |
| 13:28 |
JBoyer |
I suppose it's related to the 250K+ entries in metabib.record_attr_vector_list that point to deleted bibs. :/ |
| 13:38 |
|
jaswinder joined #evergreen |
| 14:55 |
jaswinder |
Okay, that worked. Thanks! |
| 14:56 |
dbwells |
jaswinder: and with that, off to another meeting! |
| 15:35 |
|
khuckins joined #evergreen |
| 15:57 |
* mmorgan |
has been looking for the best way to test hold policies. |
| 15:57 |
mmorgan |
I've been using the database function action.hold_request_permit_test("pickup_ou" integer, "request_ou" integer, "match_item" bigint, "match_user" integer, "match_requestor" integer) to test, is there a better approach? |
| 16:05 |
Dyrcona |
mmorgan: I intended to write a little something to make it easier, but never got around to doing so. |
| 16:06 |
mmorgan |
:) |
| 16:07 |
Dyrcona |
That seems to be the better function to use. |
| 16:10 |
Dyrcona |
Yeah, it should give your true/false, which matchpoint that came from, and a message as to why it failed. |
| 16:12 |
mmorgan |
Yes, for the false ones, the third element I've been getting is config.hold_matrix_test.holdable. |
| 16:12 |
Dyrcona |
That means the matrix blocked it. |
| 16:14 |
mmorgan |
Is it just testing the matrix? Does it take into account holdable flags on copies and locations, and things like boundaries? |
| 16:15 |
mmorgan |
I'm testing the policies, so it's doing what I want. Just curious about the other factors. |
| 16:15 |
Dyrcona |
It does. |
| 16:15 |
Dyrcona |
It tests everything since it is the main function used when placing a hold. |
| 16:15 |
mmorgan |
Ok, good to know! |
| 16:15 |
Dyrcona |
It can return more than 1 row. |
| 16:16 |
mmorgan |
Howso? |
| 16:22 |
mmorgan |
I'm getting item.holdable for the third element now that I've set a holdable flag to false, but still one row. It's serving my purpose at any rate! |
| 16:22 |
mmorgan |
Dyrcona++ |
| 16:23 |
Dyrcona |
It should return two rows if I understand it correctly. |
| 16:30 |
pinesol_green |
[evergreen|Dan Wells] Touch up release notes for 3.0.7 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=dc62e8f> |
| 16:30 |
pinesol_green |
[evergreen|Dan Wells] Touch up release notes for 3.1.1 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fad94c1> |
| 16:44 |
pinesol_green |
[evergreen|Dan Wells] Forward-port upgrades notes from 3.1.0 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2ac8fdd> |
| 17:01 |
|
mmorgan left #evergreen |
| 17:17 |
|
alynn26 joined #evergreen |
| 17:30 |
|
stephengwills joined #evergreen |
| 17:30 |
|
jvwoolf left #evergreen |
| 18:25 |
|
stephengwills joined #evergreen |
| 18:26 |
|
dbwells_ joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:38 |
|
jaswinder joined #evergreen |
| 20:29 |
|
jaswinder joined #evergreen |
| 20:37 |
|
stephengwills joined #evergreen |
| 18:03 |
|
jaswinder joined #evergreen |
| 18:06 |
|
jaswinder joined #evergreen |
| 18:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:37 |
jeffdavis |
On a 3.1.0 test server, workstation reg fails to load, console log shows "Uncaught (in promise) DOMException: Quota exceeded." errors referencing upup.sw.min.js and then some uncaught event errors apparently related to a missing IndexedDB database - anyone seen this? |
| 18:37 |
jeffdavis |
web client workstation registration, that is |
| 18:40 |
jeffdavis |
actually I'm seeing it on the login page before workstation registration too |
| 19:20 |
dbwells |
jeffdavis: from the release tarball, or git branch? |
| 19:22 |
dbwells |
jeffdavis: Actually, I was thinking of something else, so that might be interesting, but won't change my answer for now :) |
| 19:23 |
dbwells |
Yes, we have seen that, but haven't isolated it yet. It is browser/workstation specific (that is, it is only happening for one staff member here). |
