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 _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9