[Mailman-Developers] Features requested...
Mon, 15 Nov 1999 17:28:55 -0600 (CST)
I have a several ideas for features that may be of interest. Their
implementation would certainly be to my benefit. I've listed them below.
FYI, I'm testing out Mailman as a replacement for my campus' existing
Majordomo setup. If I can just get a few issued resolved, I think the
transition will go easily.
1) Please add an option so subscribers can elect to show only the username
part of their e-mail address in the subscriber list instead of the whole
thing (regardless of the @->" at " conversion).
2) In the section of the listinfo page where a user can subscribe to the
list in question, please add another radio-button option for "Conceal
yourself from subscriber list?" if the list's subscriber list can be seen
by the list members or the public. I'm somewhat of an anti-spam nut so I
don't like having my e-mail address publically visible in any form.
3) Allow the system-wide admin to disable the mail->news and news->mail
gatewaying for the whole system and/or for selected lists. (I've got some
list admins that want to use this, but I *really* don't want to see that
kind of traffic on my server. Not to mention the liability issues...)
4) On the membership management admin page, please setup a mechanism for
large lists to limit the display of user options to X number of users per
page. It's a killer to try to admin large lists from slow machines with
limited memory. (ex, took me a long time and a lot of swapping to load the
page for a 3000 member list)
5) Please setup a means by which a user can specify what additional
addresses he/she posts from other than their subscription address. (For
example, my campus has a mail aliasing system so that all public addresses
have the form "firstname.lastname@example.org" or similar. But the address
they post from may be "email@example.com" or similar. This becomes a
problem for lists that have member_posting_only turned on.)
6) Please setup a mechanism for a pre-made set of options to be used
as defaults when creating new lists. For instance, on our campus, we have
a form that prospective list owners fill out to request a new list. On
this form, we have the following options for them to "check" that
determine how their list is initially setup.:
Archived list (Duh)
Closed list (Subscriptions requests must be approved list list owner.
Otherwise list is "Open" and anyone may subscribe.)
Secured list (Only list members may post to the list)
Moderated list (list owner must approve all posts to the list)
Announcement (List will be used for outgoing announcements only. Implies
moderated and secured.)
I don't mind creating files with all of the configuration options and
their default config values. I just need a snippet of code to read the
values in and use those as defaults when creating the list. And then,
perhaps if I combined that with #7 below, I could get it to automatically
import the configuration of a previous majordomo list... (I don't know how
either of these would work with the idea to create lists from a site admin
page, tho. Perhaps the site admin could choose from a pull-down menu of
option pre-sets or pre-existing majordomo lists when creating a mailman
7) If anyone has written a withlist module that can read in the values in
an existing Majordomo 1.94 config file and update the corrosponding values
in a Mailman list's config db, I'd be ever so greatful to get a copy. This
would make transitioning to mailman *so* much easier than having to do
each list by hand through the web interface.
8) The <body> tag is not currently setup right for error pages.
9) Please build-in the option for individual list owners to filter binary
attachments. (I think something like this is already in the works, but I'd
like it to be a per-list option settable by the list owner.)
10) In the pipermail archives, please do the following:
- move the archives to http://host/mailman/archives/listname or provide
a redirect from there to http://host/pipermail/listname.
- implelement a link for users to reply to posts in an archive by using
a mailto: URL to open up a mailer window from their browser. Or
perhaps make this optional on a per-list basis.
(Note: this might break threading if a specific "In-Reply-to" header
can't be added)
- in threaded view:
(a) add links at the bottom of each post to go back to the previous
thread and forward to the next.
(b) perhaps setup a mode where a user could see all the threads
expanded on one page (as it is now) or see all the thread titles
on one page and clicking them expands the thread into a new page.
Lastly, I'd like to note that, while I understand most of what's
going on in the code, I don't have time ATM to sit down and really learn
Python. Hence, I don't have the expertise to go about making most of
these modifications myself. I do, however, plan to sit down and learn
Python as well as possible over the holiday break. So perhaps I can pitch
in directly during the new year.
Thank-you for your attention. I look forward to hearing from anyone
who can help! ;-)
~ Rick Niess ~
.oooO "Man with closed Oooo. Rick C. Niess
( ) mouth gathers ( ) University of Southern Miss.
\ ( no foot!" ) / firstname.lastname@example.org