On Wed, 22 Sep 1999 11:44:27 -0400 (EDT) The List Server Administrator at UNH <listadm@paradox.unh.edu> wrote:

Christopher Lindsey <lindsey@ncsa.uiuc.edu> posted (in part) a while back:

...

I would really prefer a model where the user can create a list on their own ... I personally find it easier to create a new list on the commandline, but I'd rather punt the entire job (except for aliases) to the end user. Otherwise I end up sending questions back and forth, etc...

J C Lawrence <claw@varesearch.com> followed-up (in part):

...

How about the following approach:

There is a web interface.

It allows a list to be created and configured, but does not instantiate the aliases or anything else to actually make it "live".

...

The nice thing about this approach is that it removes all the priviledged account problems, the "oh god someone hacked in and is running a warez list without me noticing" problem, and further, requires minimal changes to the current code (the admin interface would need to be touched to not publish lists "in edit").

And Darren Boyd <dboyd@its.to> chimed in:

...

I was thinking of something along these lines as well. A web page could allow a user to create a list, which doesn't get created. When they hit 'submit' mailman generates a script (sh or python or whatever) in the .../mailman/newlists/ directory. A mail is sent to the administrator who can then log into the box and run the script. The script then sets up the list and mails the owner.

This is, in effect, what we do here for setting up ListProc

lists. See:

       http://listproc.unh.edu/New-lists

Anyone is welcome to try this out -- I'll just ignore your

requests. :-)

I was thinking of something a little different:

When you create a list thru the web interface I describe above, I actually does the normal "create a list" process, creating all the relevent directories, config.db etc. The wanna-be list owner can then use the normal MailMan web interface to configure his list in the normal fashion, just like it was a fully instantiated list. As such he really is creating a list, not just filling out a description of what he wants.

The differences from a "real" list would be that no mail aliases would be created and config.db would contain a flag indicating that this is a proposed list rather than an instantiated list. The benefit of this approach is that very little would have to change in the rest of MailMan. All the normal admin and configuration interfaces would work just as per normal without a single line of source having to be touched, modulo the following exceptions:

listinfo and admin would have to be touched to either not list proposed lists, or to list them seperately from the real lists.

Not a big change for such a large feature.

-- J C Lawrence Life: http://www.kanga.nu/ Home: claw@kanga.nu ---------(*) Work (Linux/IA64): claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ...