[Mailman-Developers] Features requested...

Mon, 15 Nov 1999 22:39:01 -0500 (EST)

Sean responded to a bunch of Rick's points, and I'll just add a few
more thoughts.

>>>>> "RN" == Rick Niess <rniess@netserver3.otr.usm.edu> writes:

    RN> 1) Please add an option so subscribers can elect to show only
    RN> the username part of their e-mail address in the subscriber
    RN> list instead of the whole thing (regardless of the @->" at "
    RN> conversion).

The problem here is that we don't actually keep that information
around in the database.  This is bogus, and is something that I hope
will get fixed when we have a real User database (don't ask when ;)

    RN> 2) In the section of the listinfo page where a user can
    RN> subscribe to the list in question, please add another
    RN> radio-button option for "Conceal yourself from subscriber
    RN> list?"

I'd actually like to see more options at the subscription page, if not
all the options a user can change later (that might be too cluttered
and daunting though).

    RN> 3) Allow the system-wide admin to disable the mail->news and
    RN> news->mail gatewaying for the whole system and/or for selected
    RN> lists.

You can disable news->mail easily by shutting off the cron entry for
gate_news.  Shutting off mail->news will actually be much easier to
accomplish with the current CVS snapshot, since you can just edit out
the ToUsenet module from the message delivery pipeline.

There's a meta-issue about providing more site configuration options
via the Web, and that's definitely something I'd like to improve in
the future.

    RN> 5) Please setup a means by which a user can specify what
    RN> additional addresses he/she posts from other than their
    RN> subscription address. (For example, my campus has a mail
    RN> aliasing system so that all public addresses have the form
    RN> "firstname.lastname@usm.edu" or similar.  But the address they
    RN> post from may be "username@host.usm.edu" or similar.  This
    RN> becomes a problem for lists that have member_posting_only
    RN> turned on.)

Again, with a real User database, we could easily allow users to
subscribe multiple addresses, enabling delivery to some or all of
those addresses, and allowing postings from any of a User's known
addresses.  Very difficult to do right now unfortunately.

    RN> 6) Please setup a mechanism for a pre-made set of options to
    RN> be used as defaults when creating new lists.

I've thought about this, but haven't had time to work on it.  It
actually would be easy to do (contributions?? :).  Remember that
bin/newlist isn't magic -- it's really quite simple.  What you could
do is hack this script to include various common list "personalities",
which really just means certain list option settings, and then just
make those settings after the call to newlist.Create().

A simple hack would be to just have a bunch of classes in the newlist
script which implement these defaults, and add a command line switch
to invoke one of those classes on the newly created list.  If you want
to get fancy, you could publish an API and let folks add their own
list personalities.  newlist would try to import a module, dig a class
out, call the API method on the list object, and then Save it.

    RN> 7) If anyone has written a withlist module that can read in
    RN> the values in an existing Majordomo 1.94 config file and
    RN> update the corrosponding values in a Mailman list's config db,
    RN> I'd be ever so greatful to get a copy.

And if you do, please let me know, 'cause I'd love to add something
like this to the distribution!

    RN> 8) The <body> tag is not currently setup right for error
    RN> pages.

I don't understand; I guess you mean the driver script is broken?  Can
you give me more details?

    RN> 9) Please build-in the option for individual list owners to
    RN> filter binary attachments. (I think something like this is
    RN> already in the works, but I'd like it to be a per-list option
    RN> settable by the list owner.)

Again, while this functionality doesn't exist yet, the new message
delivery architecture could accomodate this much more easily.

    RN> 10) In the pipermail archives, please do the following:

I'd love it if someone became the Pipermail champion.  I just don't
have the wherewithal to do much development on this code.

    RN>      Lastly, I'd like to note that, while I understand most of
    RN> what's going on in the code, I don't have time ATM to sit down
    RN> and really learn Python.  Hence, I don't have the expertise to
    RN> go about making most of these modifications myself.  I do,
    RN> however, plan to sit down and learn Python as well as possible
    RN> over the holiday break.  So perhaps I can pitch in directly
    RN> during the new year.

Well Rick, it'll probably take you about a day to learn all the Python
you need to become a prolific Mailman hacker!  Just be sure to try it
/before/ you eat the turkey dinner and get all "stuffed". :)

-Barry