[Mailman-Developers] Some improvement suggestions

The Dragon De Monsyne dragondm@nexus.Integral.org
Thu, 28 May 1998 21:06:15 -0500 (CDT)


On Thu, 28 May 1998, Ken Manheimer wrote:

> Some of the other people here at cnri are using mailman, and they've
> hit up against one small change needed.  I thought i'd mention it
> here, in case anyone gets the chance and inclination to address it.  I
> also have one other item which i would really like to do, but the
> eventuality of actually doing it may be less near than i'd like
> (especially since i'm going away for a week, and there's all that
> catch-up time on return).
> 
> The first item is the ability to edit the new-member welcome message.
> We offer list managers the ability to edit the html pages, and they
> get to see the way the magic refs (eg, <MM-List-Name>) are used on the
> template to see how they could use them for their own versions.  Well,
> there is a number of standard mail messages, including particularly
> the welcome message, that they may want to edit.  (IN FACT, two
> different groups, separately, came to me today with the need to edit
> the welcome message - for different reasons!  A sure sign...)
> 
> I think we would have to change the format substitutions, currently
> all the "%s" order dependent style, to be "%(real_name)s" dictionary
> substitutions, and otherwise do the same kind of thing we do for the
> html templates.  (Ah, i see barry's done that in some recent
> checkins.)  There is a bunch of messages, some which may benefit from
> this treatment, other might just clutter the list admins choices.

	Hmm.. Has anyone looked at doing the whole shot with Digicool's
DocumentTemplate modules? The do both html and text, and their DTML is
alot more flexible than mailan's current 'magic-tag' system. It seems a
natural.

> Along these lines, there's something much more encompassing i'd like
> to do or see done.  I'd like to extend the handling of list admin
> options and html templates so list-specific versions are only
> squirreled away in list-specific space if and when the list admin
> changes them from the default.  This way, the central administrator
> could change the template or default values, and the new value would
> show for all the lists that haven't tailored their own versions.  This
> would certainly be suitable for something like the html pages, where
> site style changes need propagation, and also for stuff like the
> forbidden posters.  It may not be suitable for some others.
> 
> This should be easy for the template files - just don't stash
> list-specific copies until an edit is made (and the edited copy
> differs), and use the default template if no list-specific one
> exists.  It'd also be good to offer a way in the edit interface to
> revert to the default version, wiping out the list-specific copy.
> 
> For the list admin options, we'd need a new field in the options data
> structure specifying the *name* of the default value, and likewise
> some way for the gui option for the list admin to explicitly revert to
> the default.  Maybe there should be some way to have a locked-in
> list-specific setting, even if it doesn't differ from the _current_
> site default.  And then all the routines that use the list admin
> options will have to mediate through a routine (or options mediator
> object) that takes the name of the option and gets the default value
> when suitable...
> 

	Hmm... Suggestion... In my UserDB module (which I' not abandoning
for various other reasons) that stored a database of User objects for each
list, I had something like this. The Mailinglist object held certain
'default' settings for users, and the User object contained oly those
settings that were changed. the User objects used the Aquisition mdule
(part of the Extention Class system) to fetch the info from the list
object if they didn't have it. 

	IMHO, I realy think mailman needs a class of persistant Server
object (one for each virtual server) to store server-specific info which
really dosen't belong in the mailinglist object. Such an object could
store defaults in the same way as my UserDB did . It could also have
methods for things like getting the list of lists.


PS Anyone thought of using mailman with Bobo? 

	-The Dragon De Monsyne