| Time |
Nick |
Message |
| 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 |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:43 |
mmorgan |
gmcharlt++ abowling++ |
| 09:17 |
|
Dyrcona joined #evergreen |
| 09:31 |
|
jvwoolf joined #evergreen |
| 09:44 |
Dyrcona |
Just pasting this here. Maybe someone will have a look? https://docs.evergreen-ils.org/eg/docs/3.6/ |
| 10:58 |
|
awitter 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 |
| 13:53 |
Dyrcona |
Related to that, it would be good use display fields all the time. We have tickets in our local ticketing system open about titles and other things appearing different when there is or isn't a query string. |
| 13:58 |
|
sandbergja joined #evergreen |
| 14:12 |
|
alynn26 joined #evergreen |
| 14:33 |
JBoyer |
dev meeting in 30, spread the werd, assemble the herd. |
| 14:41 |
csharp |
JBoyer++ |
| 14:41 |
csharp |
I may miss part/all of the meeting - dealing with some aging parent issues |
| 14:43 |
JBoyer |
csharp, hoping things go well for you / them. |
| 14:43 |
|
nfBurton joined #evergreen |
| 14:44 |
csharp |
JBoyer: thanks! |
| 15:01 |
* JBoyer |
flicks a bell, forgeting how much that can hurt your fingers |
| 15:01 |
JBoyer |
HAI |
| 15:01 |
JBoyer |
#startmeeting 2021-04-13 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2021-04-13 |
| 15:01 |
pinesol |
Meeting started Tue Apr 13 15:01:41 2021 US/Eastern. The chair is JBoyer. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 15:01 |
pinesol |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 15:01 |
|
Topic for #evergreen is now (Meeting topic: 2021-04-13 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2021-04-13) |
| 15:01 |
pinesol |
The meeting name has been set to '2021_04_13___developer_meeting__agenda_available_at_https___wiki_evergreen_ils_org_doku_php_id_dev_meetings_2021_04_13' |
| 15:01 |
JBoyer |
#topic Introductions |
| 15:01 |
|
Topic for #evergreen is now Introductions (Meeting topic: 2021-04-13 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2021-04-13) |
| 15:01 |
JBoyer |
Explain yourselves. |
| 15:02 |
rhamby |
#info rhamby = Rogan Hamby, equinoxOLI |
| 15:02 |
abowling |
#info abowling = Adam Bowling, Emerald Data Networks |
| 15:02 |
JBoyer |
#info JBoyer = Jason Boyer, equinoxOLI |
| 15:02 |
gmcharlt |
#info gmcharlt = Galen Charlton, equinoxOLI. |
| 15:02 |
phasefx |
#info phasefx = Jason Etheridge, equinoxOLI |
| 15:02 |
gmcharlt |
To explain myself, several billion years ago... |
| 15:02 |
miker |
#info miker = Mike Rylander, EOLI, intermittent today |
| 15:02 |
JBoyer |
When a proton and an electron cool below a certain temperature... |
| 15:03 |
mmorgan |
#info mmorgan = Michele Morgan, NOBLE |
| 15:03 |
Dyrcona |
#info Dyrcona = Jason Stephenson, CWMARS |
| 15:03 |
rhamby |
when a gluon and a quark spin just right ... |
| 15:03 |
JBoyer |
That's amore? |
| 15:03 |
phasefx |
life is strange |
| 15:03 |
miker |
(intermittently available, not intermittently me) |
| 15:03 |
csharp |
#info csharp = Chris Sharp, GPLS |
| 15:04 |
csharp |
@who is miker, really? |
| 15:04 |
pinesol |
phasefx is miker, really. |
| 15:04 |
rhamby |
miker: schrodinger's mike, you're both here and not until we ping you? |
| 15:04 |
miker |
my wave function has collapsed |
| 15:04 |
* phasefx |
channels his inner miker |
| 15:04 |
csharp |
phasefx++ |
| 15:05 |
JBoyer |
ok, as people continue to arrive they can info in, and apparently treat us to a quantum mechanical quotable, if that's the way the wave collapses. |
| 15:05 |
JBoyer |
#topic Action Items from Last Meeting |
| 15:05 |
|
Topic for #evergreen is now Action Items from Last Meeting (Meeting topic: 2021-04-13 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2021-04-13) |
| 15:05 |
JBoyer |
#info Dyrcona to start documenting where Dojo and XUL are still required so they can be completely removed. |
| 15:05 |
JBoyer |
I took a look at the doc and I'm hoping some chunks of that just need a cursory glance before being discarded because they've been reimplemented in Angular(/JS). |
| 15:06 |
Dyrcona |
Well, I think there's a lot of work to do to remove Dojo. |
| 15:06 |
JBoyer |
And I was also searching for an LP bug to drop it in but either I've been launched pad, or we don't have one yet. (Not the same as removing dojo from the opac for replacement with jQ) |
| 15:07 |
Dyrcona |
I don't think there is a Lp bug, yet. |
| 15:08 |
JBoyer |
#action JBoyer will file a bug about laying dojo and xul to rest, Viking style |
| 15:09 |
JBoyer |
But seeing your mention of it in some eg2 bits does imply that it will be a little more sleuthing than I was initially hoping |
| 15:09 |
Dyrcona |
Yeah, it may not actually be used in eg2. I just noted that dojo is loaded in a file or two. |
| 15:09 |
JBoyer |
Here's hoping. |
| 15:09 |
JBoyer |
Does anyone want to take an action to get a collab branch started to strip both of those out? |
| 15:10 |
jeff |
sure, I'll give it a go. |
| 15:10 |
JBoyer |
I'm hopeful the xul cleanup will largely be removing one half of a conditional but I have many irrational and unrealistic desires. |
| 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:15 |
berick |
#info berick = Bill Erickson, KCLS |
| 15:15 |
gmcharlt |
would we be OK with an approach that started off nibbling the problem with a lot of ducks^W small commits |
| 15:16 |
Dyrcona |
What I'm trying to say is that it isn't just removing Dojo. Whole subsystmes, like Ovedrive integration, need to be implemented over again. |
| 15:17 |
JBoyer |
Given my experience with the autocomplete branch that didn't get updated for 3.7 I'd be fine with small bites, yeah. Where you thinking small commits on jeff's collab branch or keeping track of a lot of small-ish branches in a single bug, or something else entirely gmcharlt ? |
| 15:18 |
jeff |
I think the XUL removal may be easier than the Dojo removal, and could be its own branch, but we shall see! I think (and Dyrcona's research appears to confirm!) that Dojo is more... intertwined. |
| 15:18 |
gmcharlt |
off the top of my head, one central bug linking to a bunch of smaller bugs |
| 15:18 |
JBoyer |
That's probably more managable. |
| 15:19 |
JBoyer |
In that case jeff, getting started on the xul branch might be the best way to make some headway for now. |
| 15:19 |
JBoyer |
Though I suspect there may be a place here or there that stuck a fake XUL object in the dom for simplicity, I have to think that was rare. |
| 15:20 |
phasefx |
good ole xulG |
| 15:21 |
JBoyer |
I can try to put together a small collection of bugs based on Dyrcona's doc, though I'm certain we'll have more to add later. |
| 15:21 |
JBoyer |
Would anyone like to see what |
| 15:21 |
jeff |
sounds good! |
| 15:22 |
JBoyer |
the low hanging Dojo fruit may be? Possibly the Bootstrap opac since it's fairly new? |
| 15:22 |
JBoyer |
jeff++ |
| 15:22 |
gmcharlt |
yeah, establishing a firewall there would be good |
| 15:23 |
JBoyer |
I think jQ might already be among the dependencies, that would certainly help with replacement. |
| 15:25 |
JBoyer |
Perhaps this will become a regular topic so we don't lose track of things. |
| 15:25 |
JBoyer |
Any other dojo / xul thoughts before moving on? |
| 15:26 |
jeff |
I can create a pair of bugs for Dojo and XUL removal, and start a XUL removal collab branch, and if JBoyer wants to start some Dojo removal bugs tied to the main Dojo removal bug using Dyrcona's doc/research, is that a good start? |
| 15:26 |
JBoyer |
jeff, Sounds good to me. |
| 15:26 |
JBoyer |
Dyrcona++ |
| 15:27 |
JBoyer |
Thanks for puting that together |
| 15:27 |
jeff |
Dyrcona++ |
| 15:27 |
JBoyer |
ok |
| 15:27 |
JBoyer |
#topic Evergreen Release Updates |
| 15:27 |
|
Topic for #evergreen is now Evergreen Release Updates (Meeting topic: 2021-04-13 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2021-04-13) |
| 15:28 |
JBoyer |
I know the plan is that 3.7.0 drops tomorrow, but I'm also seeing concerns in the scrollback, how do things look? |
| 15:30 |
* mmorgan |
has concerns about bug 1923225 |
| 15:30 |
pinesol |
Launchpad bug 1923225 in Evergreen "ISBN display includes code in traditional catalogue" [Undecided,Confirmed] https://launchpad.net/bugs/1923225 |
| 15:30 |
gmcharlt |
I will tackle that bug, though for the purpose of the release, I do view strictly as a cosmetic bug |
| 15:31 |
gmcharlt |
certainly not ideal, and definitely needs to be fixed by the time of the regular maintenance releases |
| 15:31 |
gmcharlt |
but not IMO a 3.7.0-blocker |
| 15:32 |
gmcharlt |
(long run: I do strongly feel that the search API should move away from embedding HTML in its output in favor of returning a data structure that the TT templates can use to put together the markup for highlights) |
| 15:33 |
|
mantis left #evergreen |
| 15:33 |
JBoyer |
That certainly sounds good, and would stop this from being a game of highlight whack-a-mole |
| 15:34 |
jeffdavis |
just want to mention bug 1918362 - it will be a good load/performance improvement, but I *think* not release-critical |
| 15:34 |
pinesol |
Launchpad bug 1918362 in Evergreen 3.6 "Unchanged workstation settings are re-applied on every checkin" [Medium,Confirmed] https://launchpad.net/bugs/1918362 |
| 15:35 |
jeffdavis |
I can commit it post-release if we don't want to slip it in |
| 15:35 |
JBoyer |
By this point in the timeline I'd expect it to be an early 3.7.1 inclusion |
| 15:36 |
JBoyer |
(and backports, etc.) |
| 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 |
@JBoyer probably; maybe a failure to retrieve the dependency |
| 15:40 |
pinesol |
phasefx: git diff origin/hamster Fleshing children complete |
| 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 |
| 15:43 |
|
Topic for #evergreen is now New Business (Meeting topic: 2021-04-13 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2021-04-13) |
| 15:43 |
JBoyer |
#info Our current mailman settings can cause DMARC (dmarc.org) failures |
| 15:43 |
JBoyer |
Taking the temp of the room here, since I'd like to change our settings to set the list itself as the From: address and move the original sender to Reply-To to help with both SPF and DKIM (we could add DKIM to the outgoing messages in that case to also help things look good to email providers but that's a separate thing) |
| 15:44 |
JBoyer |
This came up because a library had asked me why they got a DMARC quarantine report for a post made to one of the evergreen lists. |
| 15:44 |
gmcharlt |
is list-as-sender and reply-to default to the list an option? |
| 15:45 |
jeff |
+1 to adjusting Mailman to the current email landscape/reality |
| 15:45 |
JBoyer |
gmcharlt, I believe it's an option so long as we don't mind losing the original posters email. |
| 15:46 |
Dyrcona |
That is the recommended set up these days. |
| 15:46 |
JBoyer |
This page has the available options: https://wiki.list.org/DEV/DMARC |
| 15:47 |
JBoyer |
Well, looking at that page again I'm not sure there is a From == Reply-To == List option |
| 15:47 |
JBoyer |
Munge From was my preferred optoin |
| 15:48 |
gmcharlt |
hmm, reply-to = list address,sender address appears to be supported by RC5322. not sure about mailman |
| 15:48 |
gmcharlt |
(to articulate my concern: reply-to=only-sender risks atomizing the discussion) |
| 15:49 |
jeff |
generally the "reply all" option in your MUA replies to the sender (via Reply-To) and the list (as an address in the To that isn't seen by your MUA as "you"). |
| 15:49 |
JBoyer |
And having just checked that's the same way it works today, unless I reply-all it only goes to the poster. |
| 15:49 |
jeff |
and the "reply (not to all)" replies to the sender (via Reply-To). |
| 15:49 |
JBoyer |
Unless my mail client is doing something "smart" |
| 15:50 |
gmcharlt |
well, in that case, if it's not an actual change in effect, I withdraw my concern |
| 15:50 |
jeff |
in the MUA in front of me (Gmail), the behavior is identical between a current-config Evergreen list and another list that does the Fron-munge + Reply-To for original sender. |
| 15:50 |
jeff |
reply-all goes to list + sender, reply goes to sender only. |
| 15:51 |
JBoyer |
ok, I'll coordinate with csharp and send out a heads-up just so everyone knows whats up. |
| 15:51 |
Dyrcona |
In Thunderbird, Reply goes to the sender, then there's also a Reply to list option. |
| 15:51 |
JBoyer |
(I say csharp, but whoever can make that change is fine with me, I just know it's not me.) |
| 15:52 |
jeff |
I have seen the occasional case where someone's address book had gotten populated with "John Smith via list-name <list example.org>" and they compose a message to "John Smith" and end up sending it to the list, but I'm not sure which MUA is the frequent offender there. |
| 15:52 |
abowling |
JBoyer: we *might* have access to that box, too |
| 15:52 |
JBoyer |
Possibly, it's PINES |
| 15:52 |
abowling |
but sign-off/involvement of csharp will be requisite, nonetheless |
| 15:53 |
JBoyer |
Who may already be out for the afternoon, so I'll just work with him directly. |
| 15:53 |
gmcharlt |
I have access as well |
| 15:53 |
|
JBoyer left #evergreen |
| 15:53 |
|
JBoyer joined #evergreen |
| 15:53 |
JBoyer |
Ah, been a while since the stupidest keyboard shortcut in all of editing has bitten me. |
| 15:53 |
abowling |
leaving your own meeting is sort of a d move |
| 15:53 |
gmcharlt |
but yeah, should be done with at least csharp's ackowledge foreknowlege |
| 15:53 |
jeff |
"And like that – poof – he's gone!" |
| 15:53 |
abowling |
gmcharlt++ |
| 15:54 |
JBoyer |
"Email's fixed!" - Mic drop. |
| 15:54 |
JBoyer |
abowling++ gmcharlt++ |
| 15:54 |
Dyrcona |
:) |
| 15:54 |
JBoyer |
#action JBoyer will work with csharp to update mailman settings and make an announcement to the lists ahead of time. |
| 15:55 |
abowling |
that, or total baller |
| 15:56 |
JBoyer |
And I may see if there's a simple way to get both addresses in Reply-To, but I suspect that might take some template editing or something (if that's even possible, I really don't know.) |
| 15:56 |
gmcharlt |
might also be overkill |
| 15:56 |
jeff |
that would remove the easy ability for a user to reply not-to-all. |
| 15:57 |
JBoyer |
Mmm, true. And we do seem to have decent traffic as-is. |
| 15:57 |
JBoyer |
Huzzah! I'm already done. |
| 15:57 |
jeff |
(and is the general case of "reply-to munging considered harmful") |
| 15:58 |
jeff |
with DMARC/DKIM it's more "reply-to munging an unfortunate but mostly-tolerable necessity" :-P |
| 15:58 |
JBoyer |
Since I don't see that anyone has sneakily added to the agenda since I typed up my script or bailed on my own meeting, if there's nothing left I'll throw out the next meeting and we can call it a day. |
| 15:59 |
Dyrcona |
JBoyer++ |
| 15:59 |
JBoyer |
jeff, yeah, I wondered if one possibility was just spreading more DKIM around, but not if we modify Subject:, so here we are. :) |
| 15:59 |
abowling |
JBoyer++ |
| 15:59 |
JBoyer |
#topic Announcements |
| 15:59 |
|
Topic for #evergreen is now Announcements (Meeting topic: 2021-04-13 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2021-04-13) |
| 15:59 |
* csharp |
appears, reads scrollback frantically |
| 15:59 |
JBoyer |
#info Next meeting is May 11, 2021 |
| 15:59 |
JBoyer |
YOU GOT SO MANY ACTIONS |
| 15:59 |
JBoyer |
#endmeeting |
| 15:59 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org | Can't speak? Make sure your nickname is registered and that you are identified to freenode services: https://freenode.net/kb/answer/registration |
| 15:59 |
pinesol |
Meeting ended Tue Apr 13 15:59:38 2021 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 15:59 |
pinesol |
Minutes: http://evergreen-ils.org/meetings/evergreen/2021/evergreen.2021-04-13-15.01.html |
| 15:59 |
pinesol |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2021/evergreen.2021-04-13-15.01.txt |
| 15:59 |
pinesol |
Log: http://evergreen-ils.org/meetings/evergreen/2021/evergreen.2021-04-13-15.01.log.html |
| 15:59 |
JBoyer |
Fun place the end the logs. |
| 15:59 |
csharp |
JBoyer++ |
| 15:59 |
phasefx |
JBoyer++ |
| 15:59 |
jeffdavis |
No time for csharp to protest, either. :) |
| 15:59 |
abowling |
csharp: you've got to remove xul, dojo, and fix the mail server |
| 16:00 |
abowling |
that's all we came up for you |
| 16:00 |
csharp |
aww dayum |
| 16:00 |
JBoyer |
Thanks everybody |
| 16:00 |
jeffdavis |
JBoyer++ |
| 16:00 |
jeffdavis |
release_team++ |
| 16:00 |
abowling |
JBoyer++ |
| 16:00 |
mmorgan |
JBoyer++ |
| 16:00 |
csharp |
we also need to migrate the list server from its current home to an 18.04 box that's been sitting there for almost 2 years :-) |
| 16:01 |
csharp |
but today is not that day |
| 16:01 |
jeff |
JBoyer: there's no practical[1] way that I know of to preserve a From: header that includes an address at a domain that has implemented DMARC in anything other than the (mostly pointless) p=none fashion. |
| 16:01 |
JBoyer |
I thought something like that happened recently, when some of the names changed? |
| 16:02 |
jeff |
(well, and have the resulting message not be rejected/quarantined) |
| 16:02 |
JBoyer |
Something I had read lead me to think that if you don't touch anything that will break the DKIM signature that DMARC considers that enough to not worry about the SPF failure. But messing with the subject absolutely breaks that. |
| 16:03 |
JBoyer |
But most of my "How is list formed?" learning has taken place primarily in the last couple days, so who knows if I'm remembering that right. |
| 16:05 |
jeff |
ah. if you come across that again, i'd be interested to see it. |
| 16:10 |
jeff |
JBoyer: might be identifier alignment, which apparently breaks not only with subject changes but also body changes like list footers. |
| 16:11 |
JBoyer |
Ah, that rings a bell. And yeah, not so helpful. "You can do all the things list servers do, but you can't tell anyone you're a list, or how to reply or how to leave. Good luck!" |
| 16:12 |
gmcharlt |
the Hotel California scheme of mailing lists |
| 16:12 |
JBoyer |
So you can do one thing, and only in a way that will make people mad at you. |
| 16:12 |
JBoyer |
gmcharlt++ |
| 16:12 |
Dyrcona |
Right, you basically can't run a discussion mailing list unless you host it at Gmail and everyone on it has a Gmail account. :) |
| 16:14 |
JBoyer |
One workaround I saw was to give everyone unique addresses at the list domain, which now that I think about it is how GMail did / does some things if you signup with a non-gmail google account. Something like JBoyer%equinoxOLI.orglist.evergreen-ils.org |
| 16:15 |
JBoyer |
It's not necessarily a good idea, but one I saw somewhere. |
| 16:20 |
gmcharlt |
csharp: noting that I think concretely the change amounts to Privacy options => Sender filters => dmarc_moderation_action to Munge From |
| 16:21 |
gmcharlt |
and maybe also General => from_is_list => Munge From |
| 16:21 |
Dyrcona |
Considering that almost all of the messages that I receive trigger DKIM_INVALID in SpamAssassin, I consider DKIM to be useless. |
| 16:25 |
|
sandbergja joined #evergreen |
| 16:27 |
JBoyer |
gmcharlt, csharp I don't know if you want to change both. The way I read that page dmarc_moderation_action supersedes from_is_list. It looks like from_is_list is only considered if dmarc_moderation_action is Accept. |
| 16:27 |
JBoyer |
(Where dma=Accept means do nothing) |
| 16:28 |
gmcharlt |
JBoyer: quite possibly. from_is_list might be more of a consistency thing (wrap all from addessses, but that might be hobgoblin consistency) |
| 16:29 |
JBoyer |
Well, fil was the first stab at addressing it in 2.1.16, and dma is the more fleshed out feature to address it from 2.1.18. |
| 16:29 |
gmcharlt |
yeah |
| 16:29 |
gmcharlt |
(and to confirm, we're on 2.1.18) |
| 16:30 |
JBoyer |
What I'm assuming is that they set it up the way they did so that if you had already set f_i_l in the past you could do nothing post 2.1.18 and it wouldn't surprise the admin. |
| 16:50 |
|
jihpringle joined #evergreen |
| 16:58 |
|
jvwoolf left #evergreen |
| 16:59 |
* miker |
appears, like a virtual particle created near the event horizon of a black hole who's partner was pulled in |
| 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 |
| 19:15 |
|
Cocopuff2018 joined #evergreen |
| 19:20 |
|
jvwoolf joined #evergreen |
| 19:22 |
jeffdavis |
fixed now, again, I hope (bug 1923225) |
| 19:22 |
pinesol |
Launchpad bug 1923225 in Evergreen "ISBN display includes code in traditional catalogue" [Undecided,Confirmed] https://launchpad.net/bugs/1923225 |
| 19:28 |
|
nfBurton joined #evergreen |
| 19:33 |
|
sandbergja joined #evergreen |
| 22:51 |
|
nfBurton joined #evergreen |
| 23:19 |
|
jvwoolf joined #evergreen |
| 23:20 |
|
sandbergja joined #evergreen |
