[Mailman-Developers] Priority/status of moderated-edit and external user DB

[Barry Warsaw]

On Thu, 2003-04-24 at 21:19, Kevin McCann wrote:

> 1) External user database. I'm sure you're all aware of the desire of some
> folks to have this. I found a Wiki document somewhere on the zope.org site
> that had discussions on this but I believe it was somewhat dated. Have any
> conclusions been reached with respect to the direction here? I think I read
> talk of a Zope-specific solution. I'm wondering if this means that we're
> likely never to see a Mailman that can talk to a MySQL database. I believe
> this one feature alone would elevate Mailman significantly. How hgh of a
> priority is this to the development team and what is the status? Are there
> current discussions on this somewhere other than the list (wiki boards,
> chats, what-have-you) , and if so, may I take part?

This mailing list is the best place to discuss such things.  Wiki
gardening takes too much time. ;}

As Jeff Waugh mentions, Mailman 2.1 provides an interface through which
it does all its user access, and a MailList extension mechanism you can
use to substitute other MemberAdaptor implementations for the default
legacy one.

While the 2.1 approach is a step in the right direction (I have an
experimental BerkeleyDB-based backend checked into the cvs head), there
are a few problems with it:

- It is a pretty inefficient interface for some tasks, most notably the
admin membership management u/i.  To build this u/i it has to load the
entire user database into memory, even to display just a chunk of 30
addresses.

- The design is still list-centric.  While I believe you could implement
a backend that unifies the user database (e.g. barry at zope.com on list1
has the same user profile as barry at zope.com on list2), I want to make
this much more evident in the interface designs.  I want to invert the
focus of Mailman from being list-centric to being user-centric.

> 2) Moderated-edit. I'm running Mailman on a couple of boxes but I also have
> a few hundred lists on a box running Lyris. I want to move them but one of
> the deal breakers at the moment is moderated-edit - the ability of a
> moderator to edit a message before it goes out. I personally don't use this
> feature for the lists I am the admin of but this seems to be a very
> important feature to some. An absolute must, in fact. I'm wonderig if this
> is in the cards, is it high on the priority list, should we expect to see it
> soon?

There is kludgey support for this now, that most people are probably not
aware of: in the admindb interface, you forward the message to yourself.
Then you use whatever tools you want to edit the message and resend it
back to the list with the Approved header.  Then you delete the message
from the admindb.  Not exactly the most efficient workflow. ;)

The thing that's always held me back here is designing a useable u/i to
such a feature.  Actually doing the editing probably isn't difficult,
but I'm far from a web u/i expert.  Doing it in a way that won't get
clobbered by huge messages, be vulnerable to cross-site scripting or
other security issues, and that provides a natural editing interface, is
a big task.  I wish there was some free tool we could just bolt on to do
this -- I'm wondering if something like SquirrelMail could be
appropriated for the task?

> I understand this is a non-paying gig for Barry and others, and I understand
> there are likely a ton of other items to deal with. But knowing what the
> priority and status of these two items are would give me a realistic idea of
> when I might be able to drop the oh-so-commercial Lyris.

Hopefully the above gives some indication of the direction. I don't have
much to say at the moment about ETA for any of this stuff, except that
I'm beginning to experiment and write interfaces.

> Finally, I'm not a Python programmer (yet), mostly Perl and PHP. But if I
> can help the cause in non-Python coding ways let me know.

I'm sure Python will be easy for you to pick up <wink>.

I wonder if we can start talking about how to get the community to take
over more of the maintenance of the 2.1 branch so that I can start
concentrating on the 3.0 work?  Trying to do both in my spare time is
difficult.

-Barry