| Time |
Nick |
Message |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:18 |
|
rjackson_isl_hom joined #evergreen |
| 08:06 |
|
rfrasur joined #evergreen |
| 08:41 |
|
mantis1 joined #evergreen |
| 08:44 |
|
mmorgan joined #evergreen |
| 08:52 |
|
Dyrcona joined #evergreen |
| 08:52 |
|
Keith-isl joined #evergreen |
| 09:08 |
|
Keith-isl joined #evergreen |
| 09:34 |
|
jvwoolf joined #evergreen |
| 09:41 |
|
BAMkubasa joined #evergreen |
| 09:44 |
BAMkubasa |
I'm trying to play around with AuthorizeNet for the first time and in Evergreen one of the settings is "AuthorizeNet server" which I'm not seeing referenced in their testing guide. I do see something for the api test, but that doesn't seem to be what I'm looking for. Can any of you have a look in your history for the "AuthorizeNet server" setting |
| 09:44 |
BAMkubasa |
and see what you were using when you were testing the initial connection? |
| 09:51 |
Dyrcona |
BAMkubasa: Six years ago, we had "test.authorize.net". It may have changed. We've switched credit card processors twice since then. |
| 09:51 |
Dyrcona |
Or, maybe only once. Authorizent may have been #2. |
| 09:52 |
rfrasur |
Whilst there are attendant eyes. Anyone know what "pre-fetch all holds" does? I've checked the docs and did a little launchpad search, but not finding anything. (might need to go way back in the docs though) |
| 09:56 |
Dyrcona |
rfrasur: Not off the top of my head. |
| 09:58 |
BAMkubasa |
Thanks Dyrcona, will try that |
| 09:58 |
rfrasur |
lol, good. Thank you. |
| 10:12 |
csharp_ |
rfrasur: from the inline code docs from that // If set, all holds are fetched on grid load and sorting/paging all |
| 10:12 |
|
collum joined #evergreen |
| 10:12 |
csharp_ |
// happens in the client. If false, sorting and paging occur on |
| 10:12 |
csharp_ |
// the server. |
| 10:12 |
csharp_ |
The UI displays the total holds count and includes a org unit selector. |
| 10:12 |
csharp_ |
It pre-fetches all holds, partly to display the full count, but also |
| 10:12 |
csharp_ |
based on the assumption that a pull list will typically be used all or |
| 10:12 |
csharp_ |
none. |
| 10:12 |
mantis1 |
Let's say you log into a browser and it keeps asking to register a workstation, doesn't produce a list in the dropdown, but when you re-register and log in, all your workstations are in the login form. thoughts? |
| 10:13 |
csharp_ |
(from the commit message from commit 26e587b6eb55822b45331c2345b1b434c8afd1f9 |
| 10:13 |
csharp_ |
mantis1: clear cache? cookies? hatch? |
| 10:21 |
mantis1 |
csharp: yeah all that and still the same issue |
| 10:21 |
csharp_ |
anything in the browser console? |
| 10:23 |
rfrasur |
csharp_++ |
| 10:27 |
mantis1 |
csharp++ I'll give it a shot |
| 10:40 |
|
JBoyer joined #evergreen |
| 11:02 |
Dyrcona |
Q for the devs. Is it possible to do a "nulls last" in the order_by of a JSON query? |
| 11:06 |
Dyrcona |
I suppose in my specific case, I can add a condition on the field being not null, since I don't wan the ones that are null. |
| 11:12 |
Bmagic |
csharp_: how long has the evergreen mailing list been configured to have a "FROM" header to have the list email address? We run mailman, and it's configured to use the sender email address. |
| 11:16 |
Dyrcona |
Bmagic: It's recommended to use the mailing list or some variation in the From because of anti-spam tools. |
| 11:16 |
Dyrcona |
Also, to answer my own question: Apparently you can't add "nulls first/nulls last" to an order by. |
| 11:17 |
Dyrcona |
At least, it doesn't look possible after going through oils_sql.c. |
| 11:17 |
Bmagic |
Do you have link to a supporting article? Ours has been this way for a really long time, and I'm not sure why Justin originally made this setting. |
| 11:18 |
Dyrcona |
Bmagic: I think it depends. The envelope sender, i.e. not the one in the From: header definitely needs to be the list. I'm too busy to do your research for you. :) |
| 11:19 |
* Dyrcona |
has to figure out the better way to do a "column is not null." |
| 11:19 |
Bmagic |
ha! No worries. I've searched around for an answer yesterday. It does make sense based upon what I've seen how spam blockers behave. |
| 11:20 |
* Dyrcona |
will miss the dev meeting this afternoon. |
| 11:31 |
|
Keith-isl joined #evergreen |
| 11:42 |
Dyrcona |
It looks like {"field":{"<>":null}} will work, or in perl: {field => {'<>' => undef}} |
| 11:43 |
Dyrcona |
Also, I may add a Lp bug to add null first/nulls last to oils_sql.c. I think I see how to do it. |
| 12:10 |
jeff |
Bmagic: https://wiki.list.org/DEV/DMARC should give you a good starting point. |
| 12:10 |
Bmagic |
jeff++ |
| 12:12 |
jeff |
Bmagic: the tipping point was around 2014 when Yahoo! started publishing a strict DMARC policy which resulted in emails from Yahoo! Mail users relayed through most mailing lists to be rejected by some/many list subscribers' mail systems. This then caused those subscribers to be unsubscribed because mail to their address was bouncing, etc. Some early bits with (now very out of date) mitigations here: |
| 12:12 |
jeff |
https://wiki.list.org/DOC/What%20can%20I%20do%20about%20members%20being%20unsubscribed%20by%20bounces%20of%20Yahoo%20user%27s%20posts%20for%20DMARC%20policy%20reasons%3F |
| 12:12 |
Bmagic |
wow! thanks |
| 12:14 |
|
Keith-isl joined #evergreen |
| 12:14 |
Bmagic |
jeff++ # exactly what I was looking for |
| 13:18 |
|
collum joined #evergreen |
| 14:23 |
|
tlittle joined #evergreen |
| 14:27 |
mmorgan |
mantis1: That workstation issue sounds familiar. I found duplicate entries for the same workstation in c:\ProgramData\Hatch\<server>\eg.workstation.all. Removing the dup fixed it. |
| 14:30 |
JBoyer |
Dev meeting in ~30! |
| 14:31 |
mantis1 |
mmorgan++ |
| 14:45 |
|
shulabear joined #evergreen |
| 14:50 |
csharp_ |
The Meeting of the Devs |
| 14:57 |
|
sandbergja joined #evergreen |
| 14:59 |
|
terranm joined #evergreen |
| 15:00 |
JBoyer |
Ding! |
| 15:00 |
JBoyer |
#startmeeting 2022-03-08 - Developer Meeting |
| 15:00 |
pinesol |
Meeting started Tue Mar 8 15:00:11 2022 US/Eastern. The chair is JBoyer. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 15:00 |
pinesol |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 15:00 |
pinesol |
The meeting name has been set to '2022_03_08___developer_meeting' |
| 15:00 |
JBoyer |
#info Agenda at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2022-03-08 |
| 15:00 |
JBoyer |
#topic Introductions |
| 15:00 |
JBoyer |
#info JBoyer = Jason Boyer, EOLI |
| 15:00 |
abowling |
#info abowling = Adam Bowling, Emerald Data Networks |
| 15:00 |
JBoyer |
Whois <you lot> |
| 15:00 |
phasefx |
#info phasefx = Jason Etheridge, EOLI |
| 15:00 |
dluch |
#info dluch = Debbie Luchenbill, MOBIUS |
| 15:00 |
mmorgan |
#info mmorgan = Michele Morgan, NOBLE |
| 15:00 |
csharp_ |
#info csharp = Chris Sharp, GPLS |
| 15:00 |
sandbergja |
#info sandbergja = Jane Sandberg, Evergreen enthusiast |
| 15:00 |
collum |
#info collum = Garry Collum, KCPL |
| 15:01 |
shulabear |
#info shulabear = Shula Link, GCHRL in GAPines |
| 15:01 |
csharp_ |
sandbergja++ |
| 15:01 |
berick |
#info berick Bill Erickson, KCLS |
| 15:01 |
shulabear |
sandbergja++ |
| 15:01 |
csharp_ |
@who is an Evergreen enthusiast? |
| 15:01 |
mmorgan |
sandbergja++ |
| 15:01 |
pinesol |
is an Evergreen enthusiast. |
| 15:01 |
csharp_ |
pinesol: nah |
| 15:01 |
pinesol |
csharp_: uh huh.. please tell me more about that |
| 15:01 |
dluch |
Yay! Hi, sandbergja!! |
| 15:02 |
JBoyer |
sandbergja++ |
| 15:02 |
sandbergja |
heya! |
| 15:02 |
JBoyer |
Ok, people can feel free to #info-up as they arrive. |
| 15:02 |
terranm |
#info terranm Terran McCanna, PINES |
| 15:02 |
JBoyer |
Lots of placeholders today, so lets skip ahead a little. |
| 15:03 |
JBoyer |
#topic Documentation |
| 15:03 |
JBoyer |
#info Minutes from March 3 meeting can be found here: https://wiki.evergreen-ils.org/doku.php?id=evergreen-docs:dig_meetings |
| 15:03 |
JBoyer |
#info We are updating and reorganizing the official docs and are going to need devs to check over some of the documentation for installation, configuration/customization, etc. to make sure it's complete and correct. So please keep an eye out for those asks! |
| 15:03 |
JBoyer |
DIG folks, anything to add to those? |
| 15:03 |
dluch |
Nope! |
| 15:03 |
|
smorrison joined #evergreen |
| 15:03 |
JBoyer |
dluch++ |
| 15:03 |
sandbergja |
dluch++ |
| 15:04 |
sandbergja |
dig++ |
| 15:04 |
JBoyer |
#topic Launchpad Status - snapshots |
| 15:04 |
JBoyer |
#info Open Bugs - 2683 |
| 15:04 |
JBoyer |
#info Pullrequests - 115 |
| 15:04 |
JBoyer |
#info Signedoff - 44 |
| 15:04 |
JBoyer |
#topic Launchpad Status - Updates |
| 15:04 |
JBoyer |
v |
| 15:04 |
JBoyer |
#info Bugs Added - 35 |
| 15:04 |
JBoyer |
#info Pullrequest tag Added - 17 |
| 15:04 |
JBoyer |
#info Signedoff tag Added - 5 |
| 15:04 |
JBoyer |
#info Fix Committed - 10 |
| 15:04 |
JBoyer |
And finally on to |
| 15:04 |
JBoyer |
#topic New Business |
| 15:04 |
JBoyer |
#info LP 1787968 - How to track down errors for files that look like they should work |
| 15:04 |
pinesol |
Launchpad bug 1787968 in Evergreen "Wishlist: Cover image uploader" [Wishlist,Confirmed] https://launchpad.net/bugs/1787968 - Assigned to Michele Morgan (mmorgan) |
| 15:05 |
JBoyer |
mmorgan ? |
| 15:05 |
mmorgan |
This is looking really good, but some uploads fail inexplicably |
| 15:05 |
mmorgan |
Just looking for clues to figure out why. |
| 15:05 |
JBoyer |
I ... think I opened the wrong bug then |
| 15:06 |
mmorgan |
Can't find anything logged on the server. |
| 15:06 |
phasefx |
mmorgan: do you have nginx in front of everything? |
| 15:06 |
mmorgan |
phasefx: no, I don't |
| 15:07 |
csharp_ |
mmorgan: be sure to check the stderr logs in /openils/var/log too |
| 15:07 |
phasefx |
k. I've seen file limits enforced in nginx cause problems |
| 15:07 |
JBoyer |
OH! I have had some fun with this on my personal instance. :/ In my case POSTs are being redirected with 301's, which then turns them into GETs which doesn't get it. |
| 15:07 |
* mmorgan |
has checked the stderr logs and haven't seen anything there |
| 15:07 |
csharp_ |
oh yeah, could be similar to the request size thing we hit where ejabberd croks? |
| 15:08 |
csharp_ |
er... croaks |
| 15:08 |
JBoyer |
mmorgan, do you have any proxy setup or do both apache and websocketd listen live on the external IP? |
| 15:09 |
mmorgan |
JBoyer: no proxy involved |
| 15:09 |
JBoyer |
Because I think apache can have an upload size limit but I don't know what the default is. |
| 15:09 |
phasefx |
it's sad, but my debugging method of choice would be to sprinkle log output througout the code and see what spits out last |
| 15:09 |
mmorgan |
Wouldn't it be logged somewhere if a limit were hit? |
| 15:10 |
JBoyer |
Maybe. It's hard to say, and definitely wouldn't hit OpenSRF / Evergreen logs. |
| 15:11 |
shulabear |
I want to say I've seen those pop in the apache logs when I've had them, but don't quote me on that. |
| 15:11 |
JBoyer |
If you're using the Evergreen rsyslog config it could be in the apache logs, otherwise probably in /var/log/apache2/* |
| 15:11 |
csharp_ |
mmorgan: look into wireshark/tshark or tcpdump as the upload is happening |
| 15:12 |
phasefx |
mmorgan: the uploads that cause problems are consistent? send me a link to a file and I can look later |
| 15:12 |
csharp_ |
(on the receiving server) |
| 15:12 |
phasefx |
I can at least confirm or rule out whether it's the file or the environment |
| 15:13 |
mmorgan |
phasefx: Yes, the failures are consistent. |
| 15:13 |
* mmorgan |
will provide a link |
| 15:13 |
phasefx |
mmorgan++ |
| 15:14 |
mmorgan |
So basically turn up logging to the max and scour every log, will give that a try. |
| 15:14 |
phasefx |
transparent proxy (this file is a virus) |
| 15:15 |
csharp_ |
mmorgan: that was marginally useful for me - those logs are super dense |
| 15:15 |
csharp_ |
unless this is on a low-traffic server |
| 15:15 |
* phasefx |
can't tell you how many times leaving the log details up has caused him to run out of disk space :) |
| 15:16 |
csharp_ |
oh yea |
| 15:16 |
mmorgan |
test server, so should be ok :) |
| 15:16 |
mmorgan |
Thanks for the tips! |
| 15:16 |
JBoyer |
mmorgan++ |
| 15:16 |
JBoyer |
phasefx++ |
| 15:17 |
JBoyer |
csharp_++ |
| 15:17 |
mmorgan |
phasefx++ |
| 15:17 |
JBoyer |
Ok, any other new business or last minute bolts of inspiration lightning? |
| 15:17 |
mmorgan |
csharp_++ |
| 15:17 |
csharp_ |
👍 |
| 15:17 |
shulabear |
csharp_++ |
| 15:17 |
shulabear |
mmorgan++ |
| 15:17 |
shulabear |
phasefx++ |
| 15:18 |
jeffdavis |
one thing about the cover uploader since we're talking about it |
| 15:18 |
* rfrasur |
gets her ears all atune. |
| 15:18 |
jeffdavis |
it will basically require multi-server environments to use an NFS share for cover images |
| 15:19 |
jeffdavis |
IIRC if the connection to the NFS server hangs it will cause OPAC pages with cover images to fail to load |
| 15:19 |
jeffdavis |
I haven't had a chance to reproduce this yet but wanted to flag it early |
| 15:20 |
phasefx |
could do less real-time and more klunky stuff, but yeah |
| 15:21 |
jeffdavis |
I don't think it should block the new feature from being committed or anything, just something to look out for once the feature goes in |
| 15:21 |
* mmorgan |
also has one more comment |
| 15:21 |
phasefx |
but the problem space should be explored already for a given installation with regards to reports |
| 15:22 |
mmorgan |
On my test server, I had to create the directories for the cover images, so thought mention of that should go in release notes. |
| 15:22 |
JBoyer |
Yeah, that's worth documenting since I think this is the one use of shared space that could cause patron-facing problems. (Though I don't know what happens if the existing custom covers stuff isn't repsonding) |
| 15:23 |
jeffdavis |
anyway I'll test more and file a bug when I can |
| 15:24 |
phasefx |
jeffdavis++ |
| 15:24 |
mmorgan |
jeffdavis++ |
| 15:24 |
JBoyer |
mmorgan, I forgot the vandelay settings had an effect here, make sure that your importer directory isn't /tmp, because that doesn't work on more recent Ubuntu and Debian releases. |
| 15:25 |
JBoyer |
Something like /openils/var/data/vandelay is a good alternative (that would also need to be created) |
| 15:25 |
JBoyer |
Speaking of, we should change that in the example config because /tmp doesn't work on single-server installs anymore etiehr. |
| 15:25 |
mmorgan |
JBoyer: Good thought, but that's not the issue. Many files upload just fine. |
| 15:25 |
JBoyer |
Ah, well. |
| 15:26 |
mmorgan |
May have something to do with files that have been manipulated. |
| 15:27 |
mmorgan |
But they still fit the specs re size and type |
| 15:27 |
JBoyer |
Hmm, possibly something abut metadata tags that the perl modules don't like. |
| 15:27 |
JBoyer |
Anyway, things to consider once this meeting is wrapped. |
| 15:27 |
JBoyer |
#topic Announcements |
| 15:27 |
JBoyer |
#info Next Meeting is April 12, 2022 |
| 15:28 |
JBoyer |
#endmeeting |
| 15:28 |
pinesol |
Meeting ended Tue Mar 8 15:28:06 2022 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 15:28 |
pinesol |
Minutes: http://evergreen-ils.org/meetings/evergreen/2022/evergreen.2022-03-08-15.00.html |
| 15:28 |
pinesol |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2022/evergreen.2022-03-08-15.00.txt |
| 15:28 |
pinesol |
Log: http://evergreen-ils.org/meetings/evergreen/2022/evergreen.2022-03-08-15.00.log.html |
| 15:28 |
Bmagic |
JBoyer++ |
| 15:28 |
abowling |
JBoyer++ |
| 15:28 |
shulabear |
JBoyer++ |
| 15:28 |
mmorgan |
JBoyer++ |
| 15:28 |
jeffdavis |
short and sweet :) |
| 15:28 |
JBoyer |
My favorite kind of meeting! |
| 15:29 |
Bmagic |
hear hear! |
| 15:29 |
Bmagic |
and (here here) |
| 15:29 |
dluch |
JBoyer++ |
| 15:29 |
phasefx |
JBoyer++ |
| 16:02 |
jeff |
we automatically print hold pull lists to printers at most of our libraries. in the earliest implementation, we used HP ePrint "email a PDF to this special email address and your printer will print it" |
| 16:03 |
jeff |
it was reliable except when it wasn't, so we've since transitioned most libraries to the (slightly more ancient but far more reliable) "send this PDF to the printer via FTP" method. |
| 16:04 |
jeff |
this week, two of our departments who were still set up to use the HP ePrint method reported that their hold pull list hadn't printed, but "this" was in the printer instead. |
| 16:05 |
jeff |
the "this" was a printed email indicating that HP had placed a spam filter in front of a bunch of their email addresses, INCLUDING the ones for the ePrint service. It helpfully explained that "The following messages, addressed to you, are currently on hold:" and explained that if you wanted to receive the "LIB-SHORT Department Holds Pull List" email you could click "Release" (or "Block", or "Permit")... |
| 16:06 |
jeff |
it was clearly not something that they had meant to intercept HP ePrint print jobs, and was quite amusing to picture "clicking" on a link on the printed page, etc... anyway, the "Get support or give us feedback." link was similarly useless. :-) |
| 16:06 |
jeff |
"Thank you for keeping HP information safe!" |
| 17:12 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:41 |
|
ejk joined #evergreen |
| 18:41 |
|
jeffdavis joined #evergreen |
| 18:41 |
|
eby joined #evergreen |
| 22:22 |
|
JBoyer joined #evergreen |
