On Sep 11, 2015, at 04:25 PM, Aurelien Bompard wrote:
>If you want to look at it :
>https://gitlab.com/abompard/mailman/commits/import-header-matches
I took a brief look, and I think you're heading in the right direction. I'll
do a more details review once the mp is up[*].
>In the code and in
> You're right that model classes should never be imported outside mailman/model
> although there are a few violations of this rule. It's less hard-and-fast for
> tests since sometimes that's just the most convenient way to handle it.
> [...]
Great explanation, thanks.
I'll send a merge request
OK, I have something that follows these requirements (except the
site-defaults + site-config thing, currently site-wide checks take
precedence).
If you want to look at it :
https://gitlab.com/abompard/mailman/commits/import-header-matches
If you have some time Barry, I'd like your review on some
> It's probably going to require a separate table foreign
> keyed to the mailing list which contain a list of regexps and their actions,
Yeah, it's currently a python list pickled into the header_matches
field of a mailinglist, we can do better :-)
> Then this has to be exposed through the REST
On Sep 10, 2015, at 11:33 AM, Aurelien Bompard wrote:
>> It's probably going to require a separate table foreign
>> keyed to the mailing list which contain a list of regexps and their actions,
>
>Yeah, it's currently a python list pickled into the header_matches
>field of a mailinglist, we can do
Aurelien Bompard writes:
> Hmm, do you think so? I would have thought that list settings
> should take precedence, since they are the most precise. A list
> could decide to not filter the spam and deal with it in their own
> manner (holding it instead of discarding it).
That makes sense when
On Sep 08, 2015, at 09:38 AM, Aurelien Bompard wrote:
>And if we're going to change this system, I'd suggest going all the way to
>rule-specific actions, to ease migrations and give more flexibility to list
>admins.
I agree, and I think it's a good idea to go all the way to rule-specific
Hey all!
I'm hitting another issue in my migration from 2.1 to 3.x. In 2.1,
there was an option called "header_filter_rules" used mainly for spam
control, and advertised as such in the CGIs. These rules contained a
regex and an action to take on a match : defer, approve, reject,
discard,
