On Sat, Jan 03, 2009 at 02:15:42PM -0500, Barry Warsaw wrote:
Because this is still alpha software, you can have a big influence on where the code goes from here. I'm especially interested in feedback from integrators, and I welcome your contribution.
[...]
Please feel free to discuss Mailman 3 development on the mailman- developers mailing list. You can submit branches and bugs to the Launchpad bug tracker at https://bugs.launchpad.net/mailman
Looks like the preference for feature requests (going by launchpad, and the list archive) is here...
in which case, I'm wondering how possible it would be for something along the lines of the following to be implemented (my python is ridiculously lousy; were I to write something like this, it would probably be a webform, some perl, mysql, cron, and bash interacting with add_members (i'm not really pro the idea of piping things to wrappers, as has been mooted in the past on -users &c).
Here's the proposal --
I'd like a third level of password authentication to be
added to allow those with said password to be able to
access the 'subscribe members' web form
(admin/foo/members/add, currently), and that alone:
*without* being able to see the existing list of list-members,
and for tertiary-admin actions (for lack of better phrase) to
be logged in the usual fashion.Perhaps a little explanation, we in this case is a privacy campaign, and we'd like our local-level co-ordinators to be able to add the email addresses of their local supporters to their lists, but not
(a) change any of the settings, or
(b) see the list of subscribers once inputted.The hopeful outcome will be that we can let these local-co-ords do this, via an "official" mechanism, rather than home-bru. It's safe to assume that the email addressess have been given in good faith, and consent to be subscribed has been given.
Behind the scenes, it would be useful if unable to subscribe notifications were sent to $LIST-OWNER (or just logged), but for only non-validating addys to be printed on-screen (quite often we see no SLD/TLD), with a note along the lines "for privacy reasons, we're only going to tell you of the successes" when the password is that of the 3ry-user (but the admin user gets to see all, as current)
What would also be nice is for something like bin/change_pw to handle the password creation/modification, and to mail the 3ry-admin with the password and URI, along with some other (template) blurb.
Any thoughts? Would this be possible to build? Could it be included. please?