On Feb 27, 2016, at 02:02 PM, Stephen J. Turnbull wrote:
I hope we haven't propagated this rather user-unfriendly interface (the convention of accepting both regexps and literals, distinguishing by "^" in column 0) to Mailman 3.
Sadly, it's true.
Mostly this is historical since we've essentially just ported the data and code from Mailman 2. It was implemented this way because of the limitations for data modeling, and the unsophisticated web ui in MM2.
We could do better in MM3, both because we can model the data better, we can expose the distinction in REST, and Postorius could expose the difference in a much better web ui.
Here's a rough sketch of what you'd have to do in the core to make this change. As always merge requests are welcome!
IBan would need to have a flag which indicate whether the email is a literal
address or a pattern. I don't think it's worth having two separate
interfaces/models, but we might want to rename email to something more
generic (pattern would be fine, with the understanding that is_regexp=False
means the pattern is a literal). You'll need to change a bunch of checks and
what-not in the ban management code.
This also shows up in AcceptableAliases, so a similar change would have to be made to IAcceptableAlias, the various model implementation bits of that interface, and the implicit_dest.py rule.
The REST API for these would probably need some additional work, but that can't easily be done. The trickiest part would be if IBan.email is renamed, in which case you'd probably want to continue to accept the old data format for the 3.0 API (and translate it into the new model layer), but only accept the new data format in the 3.1 API. There are examples of how to do API-version differentiation.
It's still used in the *_these_nonmember checks (moderation.py rule), but as these are legacy facilities from Mailman 2, I'm not sure they need to change. Eventually, we want to remove these settings anyway, since all the functionality is implemented differently and better in MM3 already.
Another odd use of this is in the withlist subcommand.
(It's also used in the wsgiref/falcon plumbing layer, but since that's all internal implementation details, nothing here needs to change.)
You'd need to handle database migrations and documentation updates too, along with a robust test suite, but there's nothing intractable about any of this.
Cheers, -Barry