Barry Warsaw writes: > It's likely that the permissions would only be enforced in > Postorius, although we can think about how the core would enforce > the permissions.
I don't insist on core enforcement, though I think it desirable. I do ask that this functionality not be called "permission" if core doesn't enforce it. (Details in earlier reply to Harshit.) > One other thing to think about is whether some styles will be > allowed or disallowed for various domains or mailing lists. I think this would be very convenient, but could be handled purely as visibility control (after all, you can reconstruct any style attribute by attribute unless prohibited in mm_cfg.py, but that's instance-wide anyway). Eg, a dotted name would be used as a str.endswidth filter, and the convention would be to name styles according to List-Id, with multiple styles or versions being "subdomains" of List-Id. The domains example.net (season to taste) and distribution.list.org would be special, corresponding to anonymous styles and the GNU Mailman distribution, respectively. So typical names of styles would be xemacs-beta.xemacs.org = style used for xemacs-b...@xemacs.org v2.honeypot.xemacs.org = rev 2 of style used for honey...@xemacs.org spam-fierce.example.net = a style containing spam filter configuration, but the admin doesn't want the name to give away which lists use it anonymous.distribution.list.org = Mark's recommendation for anonymous list configuration announce.distribution.list.org = Mark's recommendation for anouncement list configuration and typical filters would be .xemacs.org .example.net .distribution.list.org with the default being empty. Both style naming UI and available style lists could suppress the filter, and the convention would make it easy to copy a list's style. The special treatment of example.net is pretty clearly over-engineering, but the information leakage that motivates it represents the only reason I can think of for worrying about availability of styles. Since endswidth would be used to filter, you wouldn't have to break at dots, but I think that would be intuitive to users. The whole scheme is probably over-engineered, but maybe somebody can bend it into something that's not too horrible. :-) The main advantage to it is that each list would implicitly name its own configuration. You would only need to explicitly choose a name when you want something more generally descriptive, but hopefully most generic styles will be in the Mailman distribution. > I think at the very least, some segregation based on domain would > be useful. I do agree with that. Steve _______________________________________________ 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