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.
Mailman-Developers mailing list
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 

Security Policy: http://wiki.list.org/x/QIA9

Reply via email to