From mark at msapiro.net  Wed Apr  1 17:03:33 2009
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 1 Apr 2009 08:03:33 -0700
Subject: [Mailman-Developers] Inserting content to an html message
	(aka:unsubscribe link).
In-Reply-To: <49D21E14.8020604@lingnu.com>
Message-ID: <PC1870200904010803330687478a7b50@msapiro>

Asaf wrote:
>
>Is anyone working on the subject ?


As far as I know, no one is working on inserting headers/footers/etc
into HTML message bodies.


>can anyone suggest approaches, I'm pretty new to mailman's code


If you just set msg_footer with the desired information, it won't be
inserted in the HTML body, but it will be appended to the message as
an additional text/plain part and should be displayed by MUAs (mail
clients).

If you want to actually add the footer in the HTML, see the FAQ at
<http://wiki.list.org/x/84A9> to get an idea of the problems involved
in doing this.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From barry at list.org  Thu Apr  2 16:30:31 2009
From: barry at list.org (Barry Warsaw)
Date: Thu, 2 Apr 2009 09:30:31 -0500
Subject: [Mailman-Developers] Wiki maintenance
Message-ID: <14364D62-0475-4220-87E9-46E691799C05@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Please note that our hosting provider will be conducting some schedule  
maintenance on our wiki instance.  Thus wiki.list.org will be  
unavailable starting at 0900 UTC Saturday April 4, for "a few hours".

Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAknUzAgACgkQ2YZpQepbvXGKbgCfc9ZOQD4TzaZyr8sc6ygIic0G
tuYAn1B2m+B+Lh6NwIkTNDOetn814Piu
=7o8K
-----END PGP SIGNATURE-----

From brad at python.org  Thu Apr  2 19:02:59 2009
From: brad at python.org (Brad Knowles)
Date: Thu, 02 Apr 2009 12:02:59 -0500
Subject: [Mailman-Developers] [Mailman-Users] Wiki maintenance
In-Reply-To: <14364D62-0475-4220-87E9-46E691799C05@list.org>
References: <14364D62-0475-4220-87E9-46E691799C05@list.org>
Message-ID: <49D4EFC3.6030207@python.org>

Barry Warsaw wrote:

> Please note that our hosting provider will be conducting some schedule 
> maintenance on our wiki instance.  Thus wiki.list.org will be 
> unavailable starting at 0900 UTC Saturday April 4, for "a few hours".

So says the FLUFL, so shall it be.

-- 
Brad Knowles <brad at python.org>
Member of the Python.org Postmaster Team & Co-Moderator of the
mailman-users and mailman-developers mailing lists

From terri at zone12.com  Thu Apr  2 20:58:26 2009
From: terri at zone12.com (Terri Oda)
Date: Thu, 02 Apr 2009 14:58:26 -0400
Subject: [Mailman-Developers] Putting the FAQ link in with error
	messages?
In-Reply-To: <20090329192430.GA31678691@CIS.FU-Berlin.DE>
References: <49CEF4AE.7030801@zone12.com>
	<20090329192430.GA31678691@CIS.FU-Berlin.DE>
Message-ID: <49D50AD2.5060300@zone12.com>

Barry Warsaw wrote:
 > This is a very interesting idea.  When you say "error messages" do you
 > mean e.g. Python tracebacks and such?  In that case, we may not have to
 > worry about translators, for example we don't translate log messages.

I had tracebacks in mind.  If those are the easiest things to do, let's 
start there. :)

 > It would mean going through various exceptions that Mailman raises and
 > adding information to tie it to a FAQ entry (or as you point out, more
 > easily just the top wiki link).

Again, in the spirit of making this as easy as possible, let's just try 
to get the top wiki / doc link in there.  For one, it's less likely to 
change.

 >Tougher would be to attach FAQ links to
 > exceptions that Python throws that percolate up to the top interpreter
 > loop.  Still, it's a really interesting idea to pursue, and it would
 > make for a neat general Python facility.

I'm curious to take a look myself, but I know I likely won't get to this 
'till the end of the month, so if anyone else is curious, don't feel 
you'll be stepping on my toes!

Gero Eggers wrote:
> I'd like to throw in the idea of not using a wiki URL, but a more
> generic one that is http-redirected to the current, software-specific URL.
> 
> example:
> output URL: http://www.list.org/faq/4.36  
> redirect to: -> http://wiki.list.org/pages/viewpage.action?pageId=4030705

I think the best URL for now would be having http://list.org/doc be 
something equivalent to what I have on http://wiki.list.org/display/DOC/Home

I do like the idea of making the FAQ have short links like that, though. 
  The ones generated by the wiki aren't as easy to guess at.  I imagine 
it  wouldn't be hard to write a script...

Maybe I should take another stab at modernizing and reorganizing the web 
site? ;) [1]

  Terri


[1] http://terri.zone12.com/mm-website/

From adam-mailman at amyl.org.uk  Mon Apr  6 15:52:12 2009
From: adam-mailman at amyl.org.uk (Adam McGreggor)
Date: Mon, 6 Apr 2009 14:52:12 +0100
Subject: [Mailman-Developers] X-List-Post-Archive-URI: ?
Message-ID: <20090406135212.GF18880@amyl.org.uk>

I'm wondering how easy it would be to inject (before delivery, but
having gone through/during processing by Mailman) an header based
something around X-List-Post-Archive-URI: -- the idea being a unique URI
(permalinkable) for each message, for each list, that has archiving
enabled.

My initial thought is to use the message's Message-ID as the header to
use, prefixed with URI-to-list-archive:

e.g., for Message-ID: <20090406133924.GE18880 at amyl.org.uk> sent to the
list 'hummm' and lists.example.org, using pipermail (and a public
archive): 

X-List-Post-Arhive-URI: <http://lists.example.org/pipermail/hummm/20090406133924.GE18880 at amyl.org.uk>

Admitedly, these aren't the shortest URIs, but there are services for
shrinking those.

The reason I'm thinking of this is because I can't always be bothered
hunting through the web-archive to send a link to a list-post: shoving
it in the headers would be quite useful, I'd imagine.

Any thoughts from others on
    (a) stupidity/value
    (b) ease of doing; 
    (c) desire from other list-admins/list-users; 
    (d) being bothered to code it
?

-- 
``Many people would sooner die than think. In fact, they do.''
  (Bertrand Russell)

From mark at msapiro.net  Mon Apr  6 16:33:43 2009
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 6 Apr 2009 07:33:43 -0700
Subject: [Mailman-Developers] X-List-Post-Archive-URI: ?
In-Reply-To: <20090406135212.GF18880@amyl.org.uk>
Message-ID: <PC1870200904060733430171284d3a96@msapiro>

Adam McGreggor wrote:

>I'm wondering how easy it would be to inject (before delivery, but
>having gone through/during processing by Mailman) an header based
>something around X-List-Post-Archive-URI: -- the idea being a unique URI
>(permalinkable) for each message, for each list, that has archiving
>enabled.


This is being worked on for Mailman 3. See the wiki page at
<http://wiki.list.org/x/yQAM>.

This would not be easy to do in Mailman 2.2. It won't happen there, at
least not if I have to do it ;)

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From adam-mailman at amyl.org.uk  Mon Apr  6 16:37:30 2009
From: adam-mailman at amyl.org.uk (Adam McGreggor)
Date: Mon, 6 Apr 2009 15:37:30 +0100
Subject: [Mailman-Developers] X-List-Post-Archive-URI: ?
In-Reply-To: <PC1870200904060733430171284d3a96@msapiro>
References: <20090406135212.GF18880@amyl.org.uk>
	<PC1870200904060733430171284d3a96@msapiro>
Message-ID: <20090406143729.GH18880@amyl.org.uk>

On Mon, Apr 06, 2009 at 07:33:43AM -0700, Mark Sapiro wrote:
> Adam McGreggor wrote:
> 
> >I'm wondering how easy it would be to inject (before delivery, but
> >having gone through/during processing by Mailman) an header based
> >something around X-List-Post-Archive-URI: -- the idea being a unique URI
> >(permalinkable) for each message, for each list, that has archiving
> >enabled.
> 
> 
> This is being worked on for Mailman 3. See the wiki page at
> <http://wiki.list.org/x/yQAM>.

Ahhh, hadn't seen that page. Nor did I think to search. myBad!

> This would not be easy to do in Mailman 2.2. It won't happen there, at
> least not if I have to do it ;)

Oh, I wasn't expecting it in MM2x: I probably should have said that,
actually!


-- 
To an optimist, the glass is half full.
To a pessimist, the glass is half empty.
To an engineer, the glass is twice as big as it needs to be.

From barry at list.org  Mon Apr  6 20:29:39 2009
From: barry at list.org (Barry Warsaw)
Date: Mon, 6 Apr 2009 14:29:39 -0400
Subject: [Mailman-Developers] [Mailman-Users] Wiki maintenance
In-Reply-To: <49D4EFC3.6030207@python.org>
References: <14364D62-0475-4220-87E9-46E691799C05@list.org>
	<49D4EFC3.6030207@python.org>
Message-ID: <F7E23624-56F7-44C9-8B1E-6C42650D0A88@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 2, 2009, at 1:02 PM, Brad Knowles wrote:

> Barry Warsaw wrote:
>
>> Please note that our hosting provider will be conducting some  
>> schedule maintenance on our wiki instance.  Thus wiki.list.org will  
>> be unavailable starting at 0900 UTC Saturday April 4, for "a few  
>> hours".
>
> So says the FLUFL, so shall it be.

Just wait to you see "from __future__ import barry_as_FLUFL" littered  
all over the Mailman code :)

Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAknaShMACgkQ2YZpQepbvXED2QCghsgkh+wH4pOEt9P/YL1U35Md
f/IAnj0nNimXrC5RLCe3pJaFihihtNcK
=AObL
-----END PGP SIGNATURE-----

From skip at pobox.com  Wed Apr  8 06:49:14 2009
From: skip at pobox.com (skip at pobox.com)
Date: Tue,  7 Apr 2009 23:49:14 -0500 (CDT)
Subject: [Mailman-Developers] (no subject)
Message-ID: <20090408044914.58A10FC30FD@montanaro.dyndns.org>


From skip at pobox.com  Wed Apr  8 07:01:46 2009
From: skip at pobox.com (skip at pobox.com)
Date: Wed,  8 Apr 2009 00:01:46 -0500 (CDT)
Subject: [Mailman-Developers] Mailman+SpamBayes for Mailman 2.2
Message-ID: <20090408050146.CA7F3FC313F@montanaro.dyndns.org>

Sorry about the rather broad distribution.  A few people have inquired
recently about this code.

I *think* I successfully migrated my cron/gate_news changes to the mailman
2.2 branch.  The modified mailman2.2 branch is available here:

    bzr+ssh://smontanaro at bazaar.launchpad.net/%7Esmontanaro/mailman/SpamBayes/

(I have no idea how these strange URLs work.  You'll probably need to snip
out the "smontanaro@" bit.  What you might replace it with I have no clue or
if the protocol needs to be changed.)

The cron/gate_news file has been changed to run incoming Usenet messages
through the SpamBayes classifier.  There is also a spambayes.ini file to use
as a template.  This simple change worked wonders on the
python-list at python.org mailing list.  I still see complaints about spam from
time-to-time.  I think, "what spam?".  When I investigate I always find it's
a user on the Usenet side of the bridge who is complaining.

There is still absolutely no training support.  You will have to wrangle
that somehow else.  Either the mboxtrain or tte scripts which come with the
SpamBayes distribution should do the trick if you have some collected ham
and spam.  If you need some help, contact me offline or send email to
spambayes at python.org.

Cheers,

-- 
Skip Montanaro - skip at pobox.com - http://www.smontanaro.net/
        "XML sucks, dictionaries rock" - Dave Beazley

From barry at list.org  Wed Apr  8 13:55:35 2009
From: barry at list.org (Barry Warsaw)
Date: Wed, 8 Apr 2009 07:55:35 -0400
Subject: [Mailman-Developers] [Pydotorg] Mailman+SpamBayes for Mailman
	2.2
In-Reply-To: <20090408050146.CA7F3FC313F@montanaro.dyndns.org>
References: <20090408050146.CA7F3FC313F@montanaro.dyndns.org>
Message-ID: <031A95DC-BC5E-4C21-8E82-97A7703AD448@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 8, 2009, at 1:01 AM, skip at pobox.com wrote:

> Sorry about the rather broad distribution.  A few people have inquired
> recently about this code.
>
> I *think* I successfully migrated my cron/gate_news changes to the  
> mailman
> 2.2 branch.  The modified mailman2.2 branch is available here:
>
>    bzr+ssh://smontanaro at bazaar.launchpad.net/%7Esmontanaro/mailman/ 
> SpamBayes/

Probably better to use:

lp:~smontanaro/mailman/SpamBayes

and let bzr figure the rest out.

> (I have no idea how these strange URLs work.  You'll probably need  
> to snip
> out the "smontanaro@" bit.  What you might replace it with I have no  
> clue or
> if the protocol needs to be changed.)
>
> The cron/gate_news file has been changed to run incoming Usenet  
> messages
> through the SpamBayes classifier.  There is also a spambayes.ini  
> file to use
> as a template.  This simple change worked wonders on the
> python-list at python.org mailing list.  I still see complaints about  
> spam from
> time-to-time.  I think, "what spam?".  When I investigate I always  
> find it's
> a user on the Usenet side of the bridge who is complaining.
>
> There is still absolutely no training support.  You will have to  
> wrangle
> that somehow else.  Either the mboxtrain or tte scripts which come  
> with the
> SpamBayes distribution should do the trick if you have some  
> collected ham
> and spam.  If you need some help, contact me offline or send email to
> spambayes at python.org.

This is very cool, thanks Skip.  Let's try to coordinate to finish the  
port to Mailman 3.

Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAknckLcACgkQ2YZpQepbvXFVYACguHtxJ6/TCAfnRpBw/Tu3EOJP
1LcAoJud9tiXwiJhdlIPP3u0ZnBZshN0
=IhHY
-----END PGP SIGNATURE-----

From CNulk at scu.edu  Tue Apr  7 18:22:01 2009
From: CNulk at scu.edu (C Nulk)
Date: Tue, 07 Apr 2009 09:22:01 -0700
Subject: [Mailman-Developers] Mailman and Extend.py
Message-ID: <49DB7DA9.4060103@scu.edu>

Hello,

I have recently implemented the LDAPMembership adapter.  It provides
some good functionality in creating the list membership.  However, the
concept is there to provide access to one or more lists of email
addresses (list membership is essentially a list of email addresses).  I
would like to use the LDAP functionality in other areas which require or
use a list of email addresses (e.g. accept_these_nonmembers,
hold_these_nonmembers, etc).

I have looked at the F.A.Q. on custom handlers and read the MailList.py
file (under __init__) to see the 'extend.py' file being loaded.

Can someone better explain how loading the 'extend.py' file incorporates
the files code and how the 'def extend' function is called?  If I can
understand how it works, perhaps, a solution to adding multiple LDAP
search queries can be added to the extend.py file and used in other
places in Mailman.

Thanks,
Chris

P.S. When explaining, please realize I am moving from knowing absolutely
nothing about Python to knowing next to nothing. :):)

From mark at msapiro.net  Fri Apr 10 05:17:36 2009
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 9 Apr 2009 20:17:36 -0700
Subject: [Mailman-Developers] Mailman and Extend.py
In-Reply-To: <49DB7DA9.4060103@scu.edu>
Message-ID: <PC18702009040920173605626eb61d56@msapiro>

C Nulk wrote:
>
>I have recently implemented the LDAPMembership adapter.  It provides
>some good functionality in creating the list membership.  However, the
>concept is there to provide access to one or more lists of email
>addresses (list membership is essentially a list of email addresses).  I
>would like to use the LDAP functionality in other areas which require or
>use a list of email addresses (e.g. accept_these_nonmembers,
>hold_these_nonmembers, etc).
>
>I have looked at the F.A.Q. on custom handlers and read the MailList.py
>file (under __init__) to see the 'extend.py' file being loaded.
>
>Can someone better explain how loading the 'extend.py' file incorporates
>the files code and how the 'def extend' function is called?  If I can
>understand how it works, perhaps, a solution to adding multiple LDAP
>search queries can be added to the extend.py file and used in other
>places in Mailman.


Chris,

The extend.py mechanism as you use it basically just replaces the
default mamber adaptor OLDStyleMembertships.py with LDAPMemberships.py
for any list that has the extend.py file in it's lists/LISTNAME/
directory. In addition, it defines a few attributes which may or may
not be list-specific which allow LDAPMemberships.py to get to the
appropriate LDAP database.

If you've read the __init__ method in MailList.py, you've seen
everything there is to see about extend.py. It gets called there and
there only when the list is instantiated and sets the lists
._memberadaptor attribute to LDAPMemberships.

>From then on, whenever a member adaptor method is called for that list,
the method that is called is the one defined in LDAPMemberships.py.

So, for example, if your Mailman version is 2.1.10 or later so that it
supports the @LISTNAME entry in *_these_nonmembers, and you put say
@list2 in accept_these_nonmembers of list1, list1's processing of a
non-member post will call list2's isMember() method to see if the
poster is a member of list2, and if list2 already uses
LDAPMemberships, that's it - it's isMember() method will use its LDAP
database.

See the matches_p function in Mailman/Handlers/Moderate.py for more
detail.

I hope this helps. If you still have questions, keep asking.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From bg at boatskipper.com  Sat Apr 11 06:03:01 2009
From: bg at boatskipper.com (Capt Bruce Gregory)
Date: Sat, 11 Apr 2009 00:03:01 -0400
Subject: [Mailman-Developers] Inserting users names as signature of message
Message-ID: <003e01c9ba5a$6920ccb0$3b626610$@com>

I hope this is on topic and hopefully not a question that has been hashed
and rehashed but:

 

I need a way to append the full name box string of each user to the end of
each message they post.

 

Is this something that is easily attainable?

 

Thank You,

Bruce Gregory, neophyte list administrator 


From vince at wlcr.net  Sat Apr 11 18:24:54 2009
From: vince at wlcr.net (vince at wlcr.net)
Date: Sat, 11 Apr 2009 12:24:54 -0400
Subject: [Mailman-Developers] Detailed Flowchart
Message-ID: <C332DB529B6047078797A625A3C6DCA5@L520>

Where can I get a detailed flowchart of the mailman system?

Thanks!

From mark at msapiro.net  Mon Apr 13 21:42:02 2009
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 13 Apr 2009 12:42:02 -0700
Subject: [Mailman-Developers] Inserting users names as signature of
	message
In-Reply-To: <003e01c9ba5a$6920ccb0$3b626610$@com>
Message-ID: <PC187020090413124202046807fca9d6@msapiro>

Capt Bruce Gregory wrote:
>
>I need a way to append the full name box string of each user to the end of
>each message they post.


You could modify the process() function Mailman/Handlers/Decorate.py to
add the poster's name to the replacements. For example, near the
beginning of this function we have

    d = {}
    if msgdata.get('personalize'):

You could make that

    d = {}
    for sender in msg.get_senders():
        if mlist.isMember(sender):
            d['poster_name'] = mlist.getMemberName(sender)
            break
    if msgdata.get('personalize'):

Then you could use %(poster_name)s as a replacement in msg_footer.

This will work for messages, but the individual messages in digests
will still be "unsigned".

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From mark at msapiro.net  Mon Apr 13 21:50:40 2009
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 13 Apr 2009 12:50:40 -0700
Subject: [Mailman-Developers] Inserting users names as signature
	ofmessage
In-Reply-To: <PC187020090413124202046807fca9d6@msapiro>
Message-ID: <PC187020090413125040081223eb5c14@msapiro>

Mark Sapiro wrote:

>You could make that
>
>    d = {}
>    for sender in msg.get_senders():
>        if mlist.isMember(sender):
>            d['poster_name'] = mlist.getMemberName(sender)
>            break
>    if msgdata.get('personalize'):
>
>Then you could use %(poster_name)s as a replacement in msg_footer.


Better still, make it

>    d = {'poster_name': ''}
>    for sender in msg.get_senders():
>        if mlist.isMember(sender):
>            d['poster_name'] = mlist.getMemberName(sender)
>            break
>    if msgdata.get('personalize'):

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From CNulk at scu.edu  Mon Apr 13 22:20:17 2009
From: CNulk at scu.edu (C Nulk)
Date: Mon, 13 Apr 2009 13:20:17 -0700
Subject: [Mailman-Developers] Mailman and Extend.py
In-Reply-To: <PC18702009040920173605626eb61d56@msapiro>
References: <PC18702009040920173605626eb61d56@msapiro>
Message-ID: <49E39E81.9000505@scu.edu>

Thank you for replying Mark.

Mark Sapiro wrote:
> C Nulk wrote:
>> I have recently implemented the LDAPMembership adapter.  It provides
>> some good functionality in creating the list membership.  However, the
>> concept is there to provide access to one or more lists of email
>> addresses (list membership is essentially a list of email addresses).  I
>> would like to use the LDAP functionality in other areas which require or
>> use a list of email addresses (e.g. accept_these_nonmembers,
>> hold_these_nonmembers, etc).
>>
>> I have looked at the F.A.Q. on custom handlers and read the MailList.py
>> file (under __init__) to see the 'extend.py' file being loaded.
>>
>> Can someone better explain how loading the 'extend.py' file incorporates
>> the files code and how the 'def extend' function is called?  If I can
>> understand how it works, perhaps, a solution to adding multiple LDAP
>> search queries can be added to the extend.py file and used in other
>> places in Mailman.
> 
> 
> Chris,
> 
> The extend.py mechanism as you use it basically just replaces the
> default mamber adaptor OLDStyleMembertships.py with LDAPMemberships.py
> for any list that has the extend.py file in it's lists/LISTNAME/
> directory. In addition, it defines a few attributes which may or may
> not be list-specific which allow LDAPMemberships.py to get to the
> appropriate LDAP database.
> 
> If you've read the __init__ method in MailList.py, you've seen
> everything there is to see about extend.py. It gets called there and
> there only when the list is instantiated and sets the lists
> ._memberadaptor attribute to LDAPMemberships.
> 

While I waited, I did do some reading/researching on __init__ which lead
me to reading about __getattr__ and getattr.  If I understand correctly,
the LDAPMemberships uses them to get the isMember() and getMembers()
methods among others.

> From then on, whenever a member adaptor method is called for that list,
> the method that is called is the one defined in LDAPMemberships.py.
> 
> So, for example, if your Mailman version is 2.1.10 or later so that it
> supports the @LISTNAME entry in *_these_nonmembers, and you put say
> @list2 in accept_these_nonmembers of list1, list1's processing of a
> non-member post will call list2's isMember() method to see if the
> poster is a member of list2, and if list2 already uses
> LDAPMemberships, that's it - it's isMember() method will use its LDAP
> database.

Unfortunately, I am stuck at v2.1.9 for now.

> 
> See the matches_p function in Mailman/Handlers/Moderate.py for more
> detail.

I did look at Mailman/Handlers/Moderate.py, specifically the matches_p
function.  What I envisioned doing was to modify the matches_p function
to single out "ldap" entries similar to the regex entries.  Then for
each "ldap" entry, call an LDAP2Dict function (to be written) which
returns a dictionary of email addresses, then check if the sender was in
the returned dictionary.

The changes made to LDAPMemberships.py would help since you explained to
me that one of your changes was to make members a dictionary.  The
getMembers() method would essentially return that dictionary.

The key would be the changes to extend.py so everything works.

> 
> I hope this helps. If you still have questions, keep asking.
> 

It has helped.  I have made some changes to Mailman/Handlers/Moderate.py
and Utils.py (to add the LDAP2Dict function).  Let me know if you would
like to see what I came up with and I can send the diffs and
explaination to you off-list.  You may have a better way to implement
what I am doing.  Well, actually, you probably do have a better way. :)

Thanks,
Chris

From mark at msapiro.net  Tue Apr 14 01:05:56 2009
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 13 Apr 2009 16:05:56 -0700
Subject: [Mailman-Developers] Mailman and Extend.py
In-Reply-To: <49E39E81.9000505@scu.edu>
Message-ID: <PC18702009041316055607650b5af0f5@msapiro>

C Nulk wrote:
>
>While I waited, I did do some reading/researching on __init__ which lead
>me to reading about __getattr__ and getattr.  If I understand correctly,
>the LDAPMemberships uses them to get the isMember() and getMembers()
>methods among others.


Not exactly. Since the MemberAdaptor is replaceable, it can't simply be
a super class of the MailList class. Thus, it's methods are not in the
name space of the MailList object so we need an __getattr__ method to
access them from whatever class is assigned as the list's
_memberadaptor. So when you reference a method such as
mlist.isMember() that is not directly in the name space of the mlist
instance so mlist.__getattr__('isMember') is called (behind the
scenes) and it finds mlist._memberadaptor.isMember() and returns that.

This is true whether _memberadaptor is the default OldStyleMemberships
class or the LDAPMemberships class or something else. The only thing
that is specific to LDAPMemberships is the fact that the list's
extend.py module assigned LDAPMemberships to _memberadaptor.


>> From then on, whenever a member adaptor method is called for that list,
>> the method that is called is the one defined in LDAPMemberships.py.
>> 
>> So, for example, if your Mailman version is 2.1.10 or later so that it
>> supports the @LISTNAME entry in *_these_nonmembers, and you put say
>> @list2 in accept_these_nonmembers of list1, list1's processing of a
>> non-member post will call list2's isMember() method to see if the
>> poster is a member of list2, and if list2 already uses
>> LDAPMemberships, that's it - it's isMember() method will use its LDAP
>> database.
>
>Unfortunately, I am stuck at v2.1.9 for now.
>
>> 
>> See the matches_p function in Mailman/Handlers/Moderate.py for more
>> detail.
>
>I did look at Mailman/Handlers/Moderate.py, specifically the matches_p
>function.  What I envisioned doing was to modify the matches_p function
>to single out "ldap" entries similar to the regex entries.  Then for
>each "ldap" entry, call an LDAP2Dict function (to be written) which
>returns a dictionary of email addresses, then check if the sender was in
>the returned dictionary.


That would work, but if this dictionary could be equated to the
membership of some list, it seems to me that it would be easier to
just backport the @listname feature to 2.1.9. You can find the
original patch at
<http://sourceforge.net/tracker/?func=detail&aid=1220144&group_id=103&atid=300103>.
The 2.1.10 implementation is a bit more elaborate, but the SourceForge
patch should be sufficient for your purpose.

Note that there is nothing magic about the dictionary in

    plainaddrs = [addr for addr in nonmembers if not
                                   addr.startswith('^')]
    addrdict = Utils.List2Dict(plainaddrs, foldcase=1)
    if addrdict.has_key(sender):
        return 1

This could just as easily have been spelled

    plainaddrs = [addr.lower() for addr in nonmembers if not
                                   addr.startswith('^')]
    if sender in plainaddrs:
        return 1


>The changes made to LDAPMemberships.py would help since you explained to
>me that one of your changes was to make members a dictionary.  The
>getMembers() method would essentially return that dictionary.


No. getMembers() MUST return a list or everything breaks.


>The key would be the changes to extend.py so everything works.


If you are accessing some LDAP directly (not via the @list construct)
in the matches_p function, extend.py has nothing to do with it.


>> 
>> I hope this helps. If you still have questions, keep asking.
>> 
>
>It has helped.  I have made some changes to Mailman/Handlers/Moderate.py
>and Utils.py (to add the LDAP2Dict function).  Let me know if you would
>like to see what I came up with and I can send the diffs and
>explaination to you off-list.  You may have a better way to implement
>what I am doing.  Well, actually, you probably do have a better way. :)


See my remarks above.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From jenred at gmail.com  Tue Apr 14 01:24:29 2009
From: jenred at gmail.com (Jennifer Redman)
Date: Mon, 13 Apr 2009 16:24:29 -0700
Subject: [Mailman-Developers] Systers Custom Mailman Extensions and GSoC
	projects
Message-ID: <93f118f0904131624g7920f251mc2a4be683f8c879b@mail.gmail.com>

Hello!

So I posted many months ago about Systers (http://systers.org) and our
implementation of dynamic sublists for Mailman.  We finally managed to get
everything into source control:  http://launchpad.net/systers and ported to
Mailman 2.1.10.   (I apologize for our Launchpad organization -- it's on my
list to straighten things out a bit including a new patch set and a better
versioning scheme.)

To implement the dlist options, we needed to add on a separate database --
we are currently using Postgresql, unfortunately at this time the code
contains raw sql calls.

The good news is that Systers was accepted into the GSoC and one of our
projects is building out the ORM layer for the dlist functionality.  We
received an overwhelming number of applications and are just now reaching
the final stages of ranking students and proposals.

You can see our idea's page here:

http://systers.org/systers-soc

One of our requirements for the ORM project is compatibility with MM3 (we
originally recommended using SQL Alchemy, but are now asking for STORM since
it appears that is what MM3 is using.)

With that in mind, and since our projects all have a Mailman focus are there
any active developers who would be willing to join our dev list and/or
potentially act as "armchair-mentors" --  just being available to answer any
specific questions about Mailman and perhaps help introduce our students to
the Mailman development community in a kind and gentle manner?  If so would
you please email me off-list (jenred at gmail.com) and tell me a little bit
about your background -- (if you are interested in being an informal
mentor)?

Features that are included in our MM customizations:

1) Dynamic sublists (the ability to unsubscribe from individual discussion
threads)
2) Alternate email address - users can enter in multiple email addresses (as
opposed to being done at the admin level)
3) Essay requirement for mailing list application and approval

At this point our documentation is part of a larger set of complete system
installation, we will make better installation directions available over the
next week or so if anyone is interested in using some of the above features
(in tandem with the Launchpad re-org, and patch making).

Features hopefully coming soon:

1) Using an ORM for Database Abstraction (for dlist functionality)
2) Storing application essays for future review
3) Using the MM user data for 3rd party application authentication
(potentially OpenID and OpenLDAP)

One of our priorities is to make sure we are doing things in ways that are
compatible with MM3 and MM upstream in general, so any suggestions are
welcome.

Thanks,
Jen

From CNulk at scu.edu  Tue Apr 14 19:54:26 2009
From: CNulk at scu.edu (C Nulk)
Date: Tue, 14 Apr 2009 10:54:26 -0700
Subject: [Mailman-Developers] Mailman and Extend.py
In-Reply-To: <PC18702009041316055607650b5af0f5@msapiro>
References: <PC18702009041316055607650b5af0f5@msapiro>
Message-ID: <49E4CDD2.3060203@scu.edu>



Mark Sapiro wrote:
> C Nulk wrote:
>> While I waited, I did do some reading/researching on __init__ which lead
>> me to reading about __getattr__ and getattr.  If I understand correctly,
>> the LDAPMemberships uses them to get the isMember() and getMembers()
>> methods among others.
> 
> 
> Not exactly. Since the MemberAdaptor is replaceable, it can't simply be
> a super class of the MailList class. Thus, it's methods are not in the
> name space of the MailList object so we need an __getattr__ method to
> access them from whatever class is assigned as the list's
> _memberadaptor. So when you reference a method such as
> mlist.isMember() that is not directly in the name space of the mlist
> instance so mlist.__getattr__('isMember') is called (behind the
> scenes) and it finds mlist._memberadaptor.isMember() and returns that.

Sorry about that.  Your explanation is what I understood was the correct
action(s) for the interaction between MailList and the MemberAdaptor.  I
just way to short in my explanation.

> 
> This is true whether _memberadaptor is the default OldStyleMemberships
> class or the LDAPMemberships class or something else. The only thing
> that is specific to LDAPMemberships is the fact that the list's
> extend.py module assigned LDAPMemberships to _memberadaptor.
> 
> 
>>> From then on, whenever a member adaptor method is called for that list,
>>> the method that is called is the one defined in LDAPMemberships.py.
>>>
>>> So, for example, if your Mailman version is 2.1.10 or later so that it
>>> supports the @LISTNAME entry in *_these_nonmembers, and you put say
>>> @list2 in accept_these_nonmembers of list1, list1's processing of a
>>> non-member post will call list2's isMember() method to see if the
>>> poster is a member of list2, and if list2 already uses
>>> LDAPMemberships, that's it - it's isMember() method will use its LDAP
>>> database.
>> Unfortunately, I am stuck at v2.1.9 for now.
>>
>>> See the matches_p function in Mailman/Handlers/Moderate.py for more
>>> detail.
>> I did look at Mailman/Handlers/Moderate.py, specifically the matches_p
>> function.  What I envisioned doing was to modify the matches_p function
>> to single out "ldap" entries similar to the regex entries.  Then for
>> each "ldap" entry, call an LDAP2Dict function (to be written) which
>> returns a dictionary of email addresses, then check if the sender was in
>> the returned dictionary.
> 
> 
> That would work, but if this dictionary could be equated to the
> membership of some list, it seems to me that it would be easier to
> just backport the @listname feature to 2.1.9. You can find the
> original patch at
> <http://sourceforge.net/tracker/?func=detail&aid=1220144&group_id=103&atid=300103>.
> The 2.1.10 implementation is a bit more elaborate, but the SourceForge
> patch should be sufficient for your purpose.
> 
> Note that there is nothing magic about the dictionary in
> 
>     plainaddrs = [addr for addr in nonmembers if not
>                                    addr.startswith('^')]
>     addrdict = Utils.List2Dict(plainaddrs, foldcase=1)
>     if addrdict.has_key(sender):
>         return 1
> 
> This could just as easily have been spelled
> 
>     plainaddrs = [addr.lower() for addr in nonmembers if not
>                                    addr.startswith('^')]
>     if sender in plainaddrs:
>         return 1
> 

I will have to take a closer look at the patch.  And, I probably will
apply it.  From the quick glance on sourceforge, it looks like it should
work for v2.1.9.  All I should have to do is adjust the diff lines to
point to the actual locations.

Being able to use another list as a source is great.  I would still like
to try to have everything defined/set within the list itself without
cross-referencing other "management" lists.  For us, it would be easier
to manage.

> 
>> The changes made to LDAPMemberships.py would help since you explained to
>> me that one of your changes was to make members a dictionary.  The
>> getMembers() method would essentially return that dictionary.
> 
> 
> No. getMembers() MUST return a list or everything breaks.
> 

Okay.  My mistake.  Still trying to figure out Python and how things
work.  Since getMembers() returns a list, I suppose I could use the
List2Dict() function to convert the list to a dictionary to be returned
by my LDAP2Dict() function.

> 
>> The key would be the changes to extend.py so everything works.
> 
> 
> If you are accessing some LDAP directly (not via the @list construct)
> in the matches_p function, extend.py has nothing to do with it.

You will have to correct me if I am really off-base here on my
understanding.

The extend.py module defines the extend() function which appears to set
ldap (as an object of the LDAPMemberships class)
   ldap = LDAPMemberships(list)
along with additional definitions, like
   ldap.ldapsearch = "(uid=somebody)"
   ldap.ldapserver = ldap.example.net
and to tie it to the list, set the _memberadaptor to the object by
   list._memberadaptor = ldap

So when the list membership or some other method is accessed and not in
the list namespace, your explanation above applies.

My idea of changing extend.py was to add additional objects of the
LDAPMemberships class.  Say an ldap2 and ldap3 like
    ldap2 = LDAPMemberships(list)
    ldap2.ldapsearch = "(uid=person1)"
    ldap2.ldapserver = ldap2.example.net
    list.<ldap2_identifier> = ldap2
    ldap3 = LDAPMemberships(list)
    ldap3.ldapsearch = "(role=list-poster)"     # as an example
    ldap3.ldapserver = ldap3.example.net
    list.<ldap3_identifier> = ldap3

both <ldap2_identifier> and <ldap3_identifier> are similar but not the
same as the _memberadapter.  The difference is <ldap2_identifier> and
<ldap3_identifier> are specified in the accept_these_nonmembers (and the
others) lists as LDAP=<ldap2_identifier> and likewise for any other
"LDAP=" identifier.

The matches_p function (a parameter change would be needed, explained
later) can separate out the "LDAP=" items and pass to the LDAP2Dict()
function the list and ldap identifier.

The LDAP2Dict() function would use getattr(list, ldap-identifier) to
locate the appropriate object of LDAPMemberships class.

So, for ldap2_identifier passed to LDAP2Dict(),  getattr(list,
ldap2_identifier) would return
   list.ldap2_identifier

Since I know that list.ldap2_identifier is an object with the
getMembers() method, I should be able to get the "members" of the ldap2
search.  And given that getMembers() returns a list, I can convert to a
dictionary or possibly use List2Dict() to return the dictionary.

I do know that the list is not passed to the matches_p() function.  For
this to work, it would be added to the parameter list so the list can be
passed to the LDAP2Dict() function.

> 
> 
>>> I hope this helps. If you still have questions, keep asking.
>>>
>> It has helped.  I have made some changes to Mailman/Handlers/Moderate.py
>> and Utils.py (to add the LDAP2Dict function).  Let me know if you would
>> like to see what I came up with and I can send the diffs and
>> explaination to you off-list.  You may have a better way to implement
>> what I am doing.  Well, actually, you probably do have a better way. :)
> 
> 
> See my remarks above.
> 

I hope my explanations help you figure out what I am trying to do.  The
diffs may help you understand what I am trying to do.

I appreciate the help.

Thank you,
Chris

From mark at msapiro.net  Tue Apr 14 21:58:26 2009
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 14 Apr 2009 12:58:26 -0700
Subject: [Mailman-Developers] Mailman and Extend.py
In-Reply-To: <49E4CDD2.3060203@scu.edu>
Message-ID: <PC187020090414125826070346a67099@msapiro>

C Nulk wrote:
>
>I will have to take a closer look at the patch.  And, I probably will
>apply it.  From the quick glance on sourceforge, it looks like it should
>work for v2.1.9.  All I should have to do is adjust the diff lines to
>point to the actual locations.


That's correct.


>Being able to use another list as a source is great.  I would still like
>to try to have everything defined/set within the list itself without
>cross-referencing other "management" lists.  For us, it would be easier
>to manage.


That's your decision, but I think it complicates things. See below.


>
>You will have to correct me if I am really off-base here on my
>understanding.
>
>The extend.py module defines the extend() function which appears to set
>ldap (as an object of the LDAPMemberships class)
>   ldap = LDAPMemberships(list)
>along with additional definitions, like
>   ldap.ldapsearch = "(uid=somebody)"
>   ldap.ldapserver = ldap.example.net
>and to tie it to the list, set the _memberadaptor to the object by
>   list._memberadaptor = ldap


Yes.


>So when the list membership or some other method is accessed and not in
>the list namespace, your explanation above applies.
>
>My idea of changing extend.py was to add additional objects of the
>LDAPMemberships class.  Say an ldap2 and ldap3 like
>    ldap2 = LDAPMemberships(list)
>    ldap2.ldapsearch = "(uid=person1)"
>    ldap2.ldapserver = ldap2.example.net
>    list.<ldap2_identifier> = ldap2
>    ldap3 = LDAPMemberships(list)
>    ldap3.ldapsearch = "(role=list-poster)"     # as an example
>    ldap3.ldapserver = ldap3.example.net
>    list.<ldap3_identifier> = ldap3
>
>both <ldap2_identifier> and <ldap3_identifier> are similar but not the
>same as the _memberadapter.  The difference is <ldap2_identifier> and
><ldap3_identifier> are specified in the accept_these_nonmembers (and the
>others) lists as LDAP=<ldap2_identifier> and likewise for any other
>"LDAP=" identifier.


Consider the following instead.

Create a list named say posters with it's own extend.py with settings
like
    ldap = LDAPMemberships(list)
    ldap.ldapsearch = "(role=list-poster)"     # as an example
    ldap.ldapserver = ldap3.example.net
    list._memberadaptor = ldap
etc.

Then all you need do is install the patch and put @posters in the
original list's accept_these_nonmembers. You would also want to set
the 'posters' list with attributes like

archive = No
advertised = No
default_member_moderation = Yes
member_moderation_action = Discard
generic_nonmember_action = Discard

so people wouldn't be aware of it and posts would not be accepted.

That way, the different LDAP functions would be defined for different
"pseudo lists" and you wouldn't need any Mailman modifications other
than installing a feature that's already implemented in current
versions.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From CNulk at scu.edu  Tue Apr 14 22:39:32 2009
From: CNulk at scu.edu (C Nulk)
Date: Tue, 14 Apr 2009 13:39:32 -0700
Subject: [Mailman-Developers] Mailman and Extend.py
In-Reply-To: <PC187020090414125826070346a67099@msapiro>
References: <PC187020090414125826070346a67099@msapiro>
Message-ID: <49E4F484.9010400@scu.edu>

Mark Sapiro wrote:
> 
> Consider the following instead.
> 
> Create a list named say posters with it's own extend.py with settings
> like
>     ldap = LDAPMemberships(list)
>     ldap.ldapsearch = "(role=list-poster)"     # as an example
>     ldap.ldapserver = ldap3.example.net
>     list._memberadaptor = ldap
> etc.
> 
> Then all you need do is install the patch and put @posters in the
> original list's accept_these_nonmembers. You would also want to set
> the 'posters' list with attributes like
> 
> archive = No
> advertised = No
> default_member_moderation = Yes
> member_moderation_action = Discard
> generic_nonmember_action = Discard
> 
> so people wouldn't be aware of it and posts would not be accepted.
> 
> That way, the different LDAP functions would be defined for different
> "pseudo lists" and you wouldn't need any Mailman modifications other
> than installing a feature that's already implemented in current
> versions.
> 

Okay, okay, you've beaten me down. :):):)  I do see your point.  It is
an additional management issue I wanted to avoid with the unadvertised
lists.

Will this @list method also work for the other parameters/options that
have a list of email addresses (like owner, moderator, ban_list, ...) or
just the *_these_nonmembers options?

It probably sounds silly to do but if those options also take the @list
method, I can set up several of my lists so all the options (with email
address lists) are based out of ldap and have our system for creating
accounts out of our HR system build the ldap entries, resulting minimal
list management (for me at least :):))  The ban_list would not be an
ldap list but in theory it could.

If not, I guess I will have to live with it. :)

Thanks,
Chris

From mark at msapiro.net  Tue Apr 14 23:06:28 2009
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 14 Apr 2009 14:06:28 -0700
Subject: [Mailman-Developers] Mailman and Extend.py
In-Reply-To: <49E4F484.9010400@scu.edu>
Message-ID: <PC18702009041414062807818feeb329@msapiro>

C Nulk wrote:
>
>Okay, okay, you've beaten me down. :):):)  I do see your point.  It is
>an additional management issue I wanted to avoid with the unadvertised
>lists.
>
>Will this @list method also work for the other parameters/options that
>have a list of email addresses (like owner, moderator, ban_list, ...) or
>just the *_these_nonmembers options?


It only works for *_these_nonmembers. It could be implemented for
owner/moderator/etc, but these are more difficult as owner and
moderator are referred to in more than one place.

Note that Mailman 3 will support a true back-end database for list
membership and other roles. At that time, this will all become much
easier.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From CNulk at scu.edu  Tue Apr 14 23:28:41 2009
From: CNulk at scu.edu (C Nulk)
Date: Tue, 14 Apr 2009 14:28:41 -0700
Subject: [Mailman-Developers] Mailman and Extend.py
In-Reply-To: <PC18702009041414062807818feeb329@msapiro>
References: <PC18702009041414062807818feeb329@msapiro>
Message-ID: <49E50009.4050903@scu.edu>

Mark Sapiro wrote:
> C Nulk wrote:
>>
>> Will this @list method also work for the other parameters/options that
>> have a list of email addresses (like owner, moderator, ban_list, ...) or
>> just the *_these_nonmembers options?
> 
> 
> It only works for *_these_nonmembers. It could be implemented for
> owner/moderator/etc, but these are more difficult as owner and
> moderator are referred to in more than one place.
> 
> Note that Mailman 3 will support a true back-end database for list
> membership and other roles. At that time, this will all become much
> easier.
> 

I figured as much.  And thank you for answering my next question about
Mailman 3.  Is there documentation somewhere I can read how to configure
MM3 for using LDAP or any other back-end database?

Now back to the patch.

Thanks again,
Chris

From barry at python.org  Wed Apr 15 00:23:43 2009
From: barry at python.org (Barry Warsaw)
Date: Tue, 14 Apr 2009 18:23:43 -0400
Subject: [Mailman-Developers] Mailman and Extend.py
In-Reply-To: <49E50009.4050903@scu.edu>
References: <PC18702009041414062807818feeb329@msapiro>
	<49E50009.4050903@scu.edu>
Message-ID: <BAA3DC3A-8EFD-4005-BA7B-FB8757D78232@python.org>

On Apr 14, 2009, at 5:28 PM, C Nulk wrote:

> I figured as much.  And thank you for answering my next question about
> Mailman 3.  Is there documentation somewhere I can read how to  
> configure
> MM3 for using LDAP or any other back-end database?

Yes and no.  There are lots of doctests in the MM3 code, which  
primarily serve as documentation.  Navigating around to find the  
information you want may take some time as there's no overview.  There  
are currently no doctests describing how to use different backends,  
but the basic idea is that MM3 is strongly component based, using Zope  
style interfaces.  If you can provide different implementations of the  
backends for core objects (mostly in the mailman/database package),  
then the rest of Mailman will just work.

Integrating different RDBMS should be pretty trivial.  If Storm  
supports it, then it's just changing a URL in a config file.  For an  
LDAP backend, it will take some additional implementation work to  
write different implementations of IMailingList and such that don't do  
SQL queries to gather the necessary information.

I'd be happy to help anybody who's interesting in building out an LDAP  
backend.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 304 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20090414/36230d92/attachment.pgp>

From CNulk at scu.edu  Thu Apr 16 23:05:04 2009
From: CNulk at scu.edu (C Nulk)
Date: Thu, 16 Apr 2009 14:05:04 -0700
Subject: [Mailman-Developers] Mailman and Extend.py
In-Reply-To: <BAA3DC3A-8EFD-4005-BA7B-FB8757D78232@python.org>
References: <PC18702009041414062807818feeb329@msapiro>
	<49E50009.4050903@scu.edu>
	<BAA3DC3A-8EFD-4005-BA7B-FB8757D78232@python.org>
Message-ID: <49E79D80.1060007@scu.edu>

Hello Barry,

Thank you for responding.  A quick question, will MM3 also support the
@list funtionality, both for the 4 *_these_nonmembers options and the
owner, moderator, and the ban_list options?

Barry Warsaw wrote:
> On Apr 14, 2009, at 5:28 PM, C Nulk wrote:
> 
>> I figured as much.  And thank you for answering my next question about
>> Mailman 3.  Is there documentation somewhere I can read how to configure
>> MM3 for using LDAP or any other back-end database?
> 
> Yes and no.  There are lots of doctests in the MM3 code, which primarily
> serve as documentation.  Navigating around to find the information you
> want may take some time as there's no overview.  There are currently no
> doctests describing how to use different backends, but the basic idea is
> that MM3 is strongly component based, using Zope style interfaces.  If
> you can provide different implementations of the backends for core
> objects (mostly in the mailman/database package), then the rest of
> Mailman will just work.
> 

While I have heard about Zope, I am not familiar with it.

> Integrating different RDBMS should be pretty trivial.  If Storm supports
> it, then it's just changing a URL in a config file.  For an LDAP
> backend, it will take some additional implementation work to write
> different implementations of IMailingList and such that don't do SQL
> queries to gather the necessary information.
> 

I am also not familiar with Storm.  I am guessing it is the Storm from
http://storm.canonical.com.  I did take a quick look at it but I suffer
from several handicaps - main one being I know extremely little Python.
Just ask Mark Sapiro about that :):).  I also looked to see if there was
an URL type interface for LDAP.  There is however it would be primary be
an anonymous bind to a LDAP service.  Most if not all places will not
allow anonymous binds which can update/change their LDAP information.  I
just don't know enough about Storm to say whether or not the DN bind can
be worked in.

The current LDAPMembership.py get the LDAP data.  It might be possible
to use the ideas there to implement LDAP in Storm.

> I'd be happy to help anybody who's interesting in building out an LDAP
> backend.

My poor knowledge of Python most likely leaves me out with respect to
developing, however, I would be happy to be involved in contributing
ideas towards the development.

One idea I did have is about keeping unsubscribe information.  Since an
LDAP query will always return every entry matching the query, someone
that wishes to unsubscribe cannot because their entry is included in the
query.  If whatever mechanism is used to track a given list member's
config settings (mod, ack, nomail, etc) also includes whether the person
unsubscribed or not, then whenever the getMembers()/isMember() or
equivalent functions are called, the query results minus the
unsubscribed is checked/validated/etc. depending on the function.

Sorry if the above sounds like gibberish.  Could really figure out how
to say it better.

Thanks again,

Chris

From mark at msapiro.net  Fri Apr 17 00:24:42 2009
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 16 Apr 2009 15:24:42 -0700
Subject: [Mailman-Developers] Mailman and Extend.py
In-Reply-To: <49E79D80.1060007@scu.edu>
Message-ID: <PC1870200904161524420781b212dcf7@msapiro>

C Nulk wrote:
>
>Thank you for responding.  A quick question, will MM3 also support the
>@list funtionality, both for the 4 *_these_nonmembers options and the
>owner, moderator, and the ban_list options?


I have a few remarks about this. The @listname feature was implemented
in Mailman 2.1/2.2 after they diverged from 3.0 so it's not in 3.0 at
this moment. It probably will be if it makes sense to do so.

However, for your situation, the whole notion of a member adaptor per
se goes away in 3.0 and is replaced by the backend database interface,
so this may not be that significant.

Regarding owner and moderator, my understanding (Barry will correct me)
is that these roles are defined in the back-end rather than being list
attributes per se so I think your question becomes moot at least for
owner and moderator.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From CNulk at scu.edu  Fri Apr 17 18:53:30 2009
From: CNulk at scu.edu (Chris Nulk)
Date: Fri, 17 Apr 2009 09:53:30 -0700
Subject: [Mailman-Developers] Mailman and Extend.py
References: <49E8517D020000500000698D@gwia1.scu.edu>
	<49E8519A0200005000006990@gwia1.scu.edu>
Message-ID: <49E85192.C780.0050.0@scu.edu>

Mark Sapiro wrote:
> C Nulk wrote:
>> Thank you for responding.  A quick question, will MM3 also support the
>> @list funtionality, both for the 4 *_these_nonmembers options and the
>> owner, moderator, and the ban_list options?
> 
> 
> I have a few remarks about this. The @listname feature was implemented
> in Mailman 2.1/2.2 after they diverged from 3.0 so it's not in 3.0 at
> this moment. It probably will be if it makes sense to do so.

Thank you for the info Mark.

> 
> However, for your situation, the whole notion of a member adaptor per
> se goes away in 3.0 and is replaced by the backend database interface,
> so this may not be that significant.

Okay.  I understand.

> 
> Regarding owner and moderator, my understanding (Barry will correct me)
> is that these roles are defined in the back-end rather than being list
> attributes per se so I think your question becomes moot at least for
> owner and moderator.
> 

Don't have a problem with a backend database for deriving/managing the
members of a list, whether it be MySQL, Postgresql, LDAP, or anything
else.  Clearly makes sense to me.

It was just for the other "list of email addresses" options I was
curious about.  If they are defined by a backend database, am I
restricted to the same backend database as I am using for members list?
 Or, can I use a different backend for each of the "list of email
addresses" options whether it be LDAP, MySQL, Postgresql, etc. or any
combination of the mix?


Now, about an LDAP interface to MM3 (or possibly making the MM2 more
complete), is anyone interested in what ideas I have thought about?  If
so, a new thread should probably be started.

Thanks,
Chris



From barry at python.org  Sat Apr 18 00:25:09 2009
From: barry at python.org (Barry Warsaw)
Date: Fri, 17 Apr 2009 18:25:09 -0400
Subject: [Mailman-Developers] Mailman and Extend.py
In-Reply-To: <49E79D80.1060007@scu.edu>
References: <PC18702009041414062807818feeb329@msapiro>
	<49E50009.4050903@scu.edu>
	<BAA3DC3A-8EFD-4005-BA7B-FB8757D78232@python.org>
	<49E79D80.1060007@scu.edu>
Message-ID: <411EFEDE-148D-4ACD-BCAC-4AA85824F641@python.org>

On Apr 16, 2009, at 5:05 PM, C Nulk wrote:

> Hello Barry,
>
> Thank you for responding.  A quick question, will MM3 also support the
> @list funtionality, both for the 4 *_these_nonmembers options and the
> owner, moderator, and the ban_list options?

Well, not exactly.  It should be possible to get the same  
functionality, but it will have to be done differently.  For example,  
the *_these_nonmember attributes are gone.

> Barry Warsaw wrote:
>> On Apr 14, 2009, at 5:28 PM, C Nulk wrote:
>>
>>> I figured as much.  And thank you for answering my next question  
>>> about
>>> Mailman 3.  Is there documentation somewhere I can read how to  
>>> configure
>>> MM3 for using LDAP or any other back-end database?
>>
>> Yes and no.  There are lots of doctests in the MM3 code, which  
>> primarily
>> serve as documentation.  Navigating around to find the information  
>> you
>> want may take some time as there's no overview.  There are  
>> currently no
>> doctests describing how to use different backends, but the basic  
>> idea is
>> that MM3 is strongly component based, using Zope style interfaces.   
>> If
>> you can provide different implementations of the backends for core
>> objects (mostly in the mailman/database package), then the rest of
>> Mailman will just work.
>>
>
> While I have heard about Zope, I am not familiar with it.

You don't really need to know much about Zope to understand  
zope.interfaces.  Really, just think of these as a formal way to  
specify interfaces to components.  The package originated in the Zope  
world which is why it lives in the 'zope' namespace.

>> Integrating different RDBMS should be pretty trivial.  If Storm  
>> supports
>> it, then it's just changing a URL in a config file.  For an LDAP
>> backend, it will take some additional implementation work to write
>> different implementations of IMailingList and such that don't do SQL
>> queries to gather the necessary information.
>>
>
> I am also not familiar with Storm.  I am guessing it is the Storm from
> http://storm.canonical.com.

Yep.

> I did take a quick look at it but I suffer
> from several handicaps - main one being I know extremely little  
> Python.
> Just ask Mark Sapiro about that :):).

;)

> I also looked to see if there was
> an URL type interface for LDAP.  There is however it would be  
> primary be
> an anonymous bind to a LDAP service.  Most if not all places will not
> allow anonymous binds which can update/change their LDAP  
> information.  I
> just don't know enough about Storm to say whether or not the DN bind  
> can
> be worked in.
>
> The current LDAPMembership.py get the LDAP data.  It might be possible
> to use the ideas there to implement LDAP in Storm.

I don't think LDAP is a good fit for Storm, which really wants to be  
talking to a relational database via SQL.  The bad news is that using  
Storm is the easy way to hook MM3 up to a different backend.  The good  
news is that (hopefully) that's not necessary to use LDAP for  your  
user data.  I think you would need to re-implement things like the  
UserManager, but this is mostly uncharted waters.

>
>> I'd be happy to help anybody who's interesting in building out an  
>> LDAP
>> backend.
>
> My poor knowledge of Python most likely leaves me out with respect to
> developing, however, I would be happy to be involved in contributing
> ideas towards the development.
>
> One idea I did have is about keeping unsubscribe information.  Since  
> an
> LDAP query will always return every entry matching the query, someone
> that wishes to unsubscribe cannot because their entry is included in  
> the
> query.  If whatever mechanism is used to track a given list member's
> config settings (mod, ack, nomail, etc) also includes whether the  
> person
> unsubscribed or not, then whenever the getMembers()/isMember() or
> equivalent functions are called, the query results minus the
> unsubscribed is checked/validated/etc. depending on the function.
>
> Sorry if the above sounds like gibberish.  Could really figure out how
> to say it better.

I think I see what you're saying.  You really want to split user data  
across LDAP and say a relational database.  While I think it could be  
done (and probably /should/ be doable), it will take some clever model- 
layer programming to make it work.  I don't have a clear picture in my  
mind about how to do that right now, but it's worth an interested  
developer to take a look at it.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 304 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20090417/9d878fff/attachment.pgp>

From barry at list.org  Sat Apr 18 00:27:51 2009
From: barry at list.org (Barry Warsaw)
Date: Fri, 17 Apr 2009 18:27:51 -0400
Subject: [Mailman-Developers] Mailman and Extend.py
In-Reply-To: <PC1870200904161524420781b212dcf7@msapiro>
References: <PC1870200904161524420781b212dcf7@msapiro>
Message-ID: <396AF717-6D1A-4940-94E7-56785DFE5420@list.org>

On Apr 16, 2009, at 6:24 PM, Mark Sapiro wrote:

> Regarding owner and moderator, my understanding (Barry will correct  
> me)
> is that these roles are defined in the back-end rather than being list
> attributes per se so I think your question becomes moot at least for
> owner and moderator.

Yes, 'member', 'moderator', and 'owner' are roles defined in the  
member interface and used in the roster interfaces.  They aren't tied  
to users directly.  In fact, they're actually tied to addresses (which  
are tied to users) and a single address/user can play multiple roles.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20090417/41150493/attachment.pgp>

From barry at python.org  Sat Apr 18 00:32:18 2009
From: barry at python.org (Barry Warsaw)
Date: Fri, 17 Apr 2009 18:32:18 -0400
Subject: [Mailman-Developers] Mailman and Extend.py
In-Reply-To: <49E85192.C780.0050.0@scu.edu>
References: <49E8517D020000500000698D@gwia1.scu.edu>
	<49E8519A0200005000006990@gwia1.scu.edu>
	<49E85192.C780.0050.0@scu.edu>
Message-ID: <62264D21-0654-42A0-B473-7F75813C9CD5@python.org>

On Apr 17, 2009, at 12:53 PM, Chris Nulk wrote:

> It was just for the other "list of email addresses" options I was
> curious about.  If they are defined by a backend database, am I
> restricted to the same backend database as I am using for members  
> list?
> Or, can I use a different backend for each of the "list of email
> addresses" options whether it be LDAP, MySQL, Postgresql, etc. or any
> combination of the mix?

In thinking about this a bit more, for MM3, you might in fact be able  
to get away with just re-implementing the roster layer.  It's rosters  
that tell mailing lists two important facts: 1) who gets to post to a  
mailing list and 2) who gets delivery of posted messages.  Rosters are  
really just queries, they have no persistent storage themselves.  So  
while I still think it would take some clever programming, it should  
be possible to keep user information in the RDBMS and provide for  
subscription information by LDAP.

> Now, about an LDAP interface to MM3 (or possibly making the MM2 more
> complete), is anyone interested in what ideas I have thought about?   
> If
> so, a new thread should probably be started.

Sure, I'd like to hear it because I think this will be an interesting  
use case.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 304 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20090417/65052583/attachment.pgp>

From CNulk at scu.edu  Sat Apr 18 00:58:43 2009
From: CNulk at scu.edu (C Nulk)
Date: Fri, 17 Apr 2009 15:58:43 -0700
Subject: [Mailman-Developers] Mailman and Extend.py
In-Reply-To: <411EFEDE-148D-4ACD-BCAC-4AA85824F641@python.org>
References: <PC18702009041414062807818feeb329@msapiro>	<49E50009.4050903@scu.edu>	<BAA3DC3A-8EFD-4005-BA7B-FB8757D78232@python.org>	<49E79D80.1060007@scu.edu>
	<411EFEDE-148D-4ACD-BCAC-4AA85824F641@python.org>
Message-ID: <49E909A3.8090706@scu.edu>

Barry Warsaw wrote:
>> I also looked to see if there was
>> an URL type interface for LDAP.  There is however it would be primary be
>> an anonymous bind to a LDAP service.  Most if not all places will not
>> allow anonymous binds which can update/change their LDAP information.  I
>> just don't know enough about Storm to say whether or not the DN bind can
>> be worked in.
>>
>> The current LDAPMembership.py get the LDAP data.  It might be possible
>> to use the ideas there to implement LDAP in Storm.
> 
> I don't think LDAP is a good fit for Storm, which really wants to be
> talking to a relational database via SQL.  The bad news is that using
> Storm is the easy way to hook MM3 up to a different backend.  The good
> news is that (hopefully) that's not necessary to use LDAP for  your user
> data.  I think you would need to re-implement things like the
> UserManager, but this is mostly uncharted waters.
> 

As I walked to the train station last night, I came to the same
conclusion.  Since LDAP is not relational, Storm would need to make
exceptions for LDAP.  Definitely not a good fit.

>>
>>> I'd be happy to help anybody who's interesting in building out an LDAP
>>> backend.
>>
>> My poor knowledge of Python most likely leaves me out with respect to
>> developing, however, I would be happy to be involved in contributing
>> ideas towards the development.
>>
>> One idea I did have is about keeping unsubscribe information.  Since an
>> LDAP query will always return every entry matching the query, someone
>> that wishes to unsubscribe cannot because their entry is included in the
>> query.  If whatever mechanism is used to track a given list member's
>> config settings (mod, ack, nomail, etc) also includes whether the person
>> unsubscribed or not, then whenever the getMembers()/isMember() or
>> equivalent functions are called, the query results minus the
>> unsubscribed is checked/validated/etc. depending on the function.
>>
>> Sorry if the above sounds like gibberish.  Could really figure out how
>> to say it better.
> 
> I think I see what you're saying.  You really want to split user data
> across LDAP and say a relational database.  While I think it could be
> done (and probably /should/ be doable), it will take some clever
> model-layer programming to make it work.  I don't have a clear picture
> in my mind about how to do that right now, but it's worth an interested
> developer to take a look at it.
> 
> -Barry
> 

Well, not really splitting up the data between LDAP and a relational DB
because you will end up with sync problems at some point in time.  It
was more of adding/modifing text attribute values in LDAP.  I will
explain it more fully next week when I start a new thread (I just saw
your responses and I need to close up and head for the train).

Chris

From CNulk at scu.edu  Sat Apr 18 01:02:11 2009
From: CNulk at scu.edu (C Nulk)
Date: Fri, 17 Apr 2009 16:02:11 -0700
Subject: [Mailman-Developers] Mailman and Extend.py
In-Reply-To: <62264D21-0654-42A0-B473-7F75813C9CD5@python.org>
References: <49E8517D020000500000698D@gwia1.scu.edu>
	<49E8519A0200005000006990@gwia1.scu.edu>
	<49E85192.C780.0050.0@scu.edu>
	<62264D21-0654-42A0-B473-7F75813C9CD5@python.org>
Message-ID: <49E90A73.9060006@scu.edu>

Barry Warsaw wrote:
> On Apr 17, 2009, at 12:53 PM, Chris Nulk wrote:
> 
>> It was just for the other "list of email addresses" options I was
>> curious about.  If they are defined by a backend database, am I
>> restricted to the same backend database as I am using for members list?
>> Or, can I use a different backend for each of the "list of email
>> addresses" options whether it be LDAP, MySQL, Postgresql, etc. or any
>> combination of the mix?
> 
> In thinking about this a bit more, for MM3, you might in fact be able to
> get away with just re-implementing the roster layer.  It's rosters that
> tell mailing lists two important facts: 1) who gets to post to a mailing
> list and 2) who gets delivery of posted messages.  Rosters are really
> just queries, they have no persistent storage themselves.  So while I
> still think it would take some clever programming, it should be possible
> to keep user information in the RDBMS and provide for subscription
> information by LDAP.
> 
>> Now, about an LDAP interface to MM3 (or possibly making the MM2 more
>> complete), is anyone interested in what ideas I have thought about?  If
>> so, a new thread should probably be started.
> 
> Sure, I'd like to hear it because I think this will be an interesting
> use case.
> 

Great.  I will start the new thread next week.  I will need a little
time to compose the ideas.  Hopefully, if the ideas make sense, they can
be applied to MM3 and MM2.

Thanks for your help Barry and Mark,

Chris

From phaidros at subsignal.org  Fri Apr 17 20:42:23 2009
From: phaidros at subsignal.org (phaidros)
Date: Fri, 17 Apr 2009 20:42:23 +0200
Subject: [Mailman-Developers] Patch for Bug 266263 (NNTP gatewaying trashes
	Message-IDs)
Message-ID: <1239993743.30260.136.camel@rikk>

Hi,

we have thought a while about it and needed a solution badly. We are
having several Mail2News mailing lists, which all come up with broken
threading, when cross posted messages appear. The same issues as stated
in the bug here: https://bugs.launchpad.net/mailman/+bug/266263

I have just added a patch and a description for the patch at launchpad.

This is a request for considering this patch as improvement and merging
it. A lot of mail and news administrators would be thankful for less
headaches :)

kind regards,
kloschi


-- 
With or without religion, we would have good people doing good things
and evil people doing evil things. But for good people to do evil
things, that takes religion."                   
                                                       -- Steve Weinberg


From adam-mailman at amyl.org.uk  Wed Apr 22 19:01:45 2009
From: adam-mailman at amyl.org.uk (Adam McGreggor)
Date: Wed, 22 Apr 2009 18:01:45 +0100
Subject: [Mailman-Developers] MM 2.1.12(rc2) backport for Ubuntu Hardy?
Message-ID: <20090422170145.GN26929@amyl.org.uk>

Just a quick query really (and possibly being slightly cheeky asking
here...), but have any of you guys backported Mailman 2.1.12 from the
Ubuntu Jaunty (or Debian 5) repos -> Ubuntu Hardy?

I can't seem to find anything with an internet search, and I'd rather
not repeat the efforts, if someone's already done it (as it's been quite
some time since I last backported something)

TIA.

a

-- 
``Foot-and-mouth believed to be first virus
  unable to spread through Microsoft Outlook'' (spoof headline)

From barry at python.org  Wed Apr 22 19:12:26 2009
From: barry at python.org (Barry Warsaw)
Date: Wed, 22 Apr 2009 13:12:26 -0400
Subject: [Mailman-Developers] MM 2.1.12(rc2) backport for Ubuntu Hardy?
In-Reply-To: <20090422170145.GN26929@amyl.org.uk>
References: <20090422170145.GN26929@amyl.org.uk>
Message-ID: <3E5FC409-E502-401F-8A9A-C5D0C86003F0@python.org>

On Apr 22, 2009, at 1:01 PM, Adam McGreggor wrote:

> Just a quick query really (and possibly being slightly cheeky asking
> here...), but have any of you guys backported Mailman 2.1.12 from the
> Ubuntu Jaunty (or Debian 5) repos -> Ubuntu Hardy?
>
> I can't seem to find anything with an internet search, and I'd rather
> not repeat the efforts, if someone's already done it (as it's been  
> quite
> some time since I last backported something)

I have not.  I'm not sure who's packaging Mailman for Ubuntu (I might  
be able to find someone to ask <wink>), but I could certainly see us  
providing PPAs for folks who want to run the latest and greatest.  I  
don't have much packaging-fu but if someone wants to volunteer to do  
the heavily lifting, I'd be happy to twiddle the Launchpad bits.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 304 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20090422/e2ea94e3/attachment.pgp>

From thijs at debian.org  Thu Apr 23 11:02:14 2009
From: thijs at debian.org (Thijs Kinkhorst)
Date: Thu, 23 Apr 2009 11:02:14 +0200
Subject: [Mailman-Developers] MM 2.1.12(rc2) backport for Ubuntu Hardy?
In-Reply-To: <3E5FC409-E502-401F-8A9A-C5D0C86003F0@python.org>
References: <20090422170145.GN26929@amyl.org.uk>
	<3E5FC409-E502-401F-8A9A-C5D0C86003F0@python.org>
Message-ID: <12b62555d1550c4c79de5983d798f81d.squirrel@wm.kinkhorst.nl>

On Wed, April 22, 2009 19:12, Barry Warsaw wrote:
> On Apr 22, 2009, at 1:01 PM, Adam McGreggor wrote:
>
>
>> Just a quick query really (and possibly being slightly cheeky asking
>> here...), but have any of you guys backported Mailman 2.1.12 from the
>> Ubuntu Jaunty (or Debian 5) repos -> Ubuntu Hardy?
>>
>>
>> I can't seem to find anything with an internet search, and I'd rather
>> not repeat the efforts, if someone's already done it (as it's been quite
>> some time since I last backported something)
>
> I have not.  I'm not sure who's packaging Mailman for Ubuntu (I might
> be able to find someone to ask <wink>), but I could certainly see us
> providing PPAs for folks who want to run the latest and greatest.  I don't
> have much packaging-fu but if someone wants to volunteer to do the heavily
> lifting, I'd be happy to twiddle the Launchpad bits.

Mailman in Ubuntu is essentially Mailman in Debian: the Ubuntu package is
a verbatim copy of the Debian one.

Unfortunately our maintenance team currently has the volunteer manpower to
just keep up, but not to extend its tasks, so we're not really involving
ourselves in extra backporting efforts. (BTW: if anyone on this list is
interested in improving the Debian/Ubuntu packaging of Mailman they're
welcome to join our team! Contact me to get started)

However, I don't think it should be complex to backport it, so I urge you
to just try and do it. One catch may be that in the 2.1.12-1 package
version we cleaned up a number of old compatibility/upgrading measures for
old releases, which may be relevant again if you backport it. But I think
you'll encounter it along the way if that's the case.


cheers,
Thijs


From p at state-of-mind.de  Thu Apr 23 17:16:24 2009
From: p at state-of-mind.de (Patrick Ben Koetter)
Date: Thu, 23 Apr 2009 17:16:24 +0200
Subject: [Mailman-Developers] mailman 3: webinterface: prototype (PDF)
Message-ID: <20090423151623.GH7781@state-of-mind.de>

Greetings,

following our discussions at the Pycon 2009 Mailman sprint I've come up with
first draft of a/the future mailman 3 web interface.

The interface has changed a lot. Changes follow these principles:

  * Simplify interface
  * Focus on tasks
  * Order and sort by task recurrance
  * Reduce information overflow e.g. by hiding help messages
  * Show help messages as bubbles when selected by user
  * Remove instructions on using a web from
  * Use default button texts e.g. "Save" instead of "Submit your changes"
  See also: <http://wiki.list.org/display/DEV/Rest+client>

I've come up with a paper prototype, which you can download in an annotated
PDF by clicking at "Mailman webinterface draft" at the following location:

  <http://wiki.list.org/display/DEV/Information+Architecture>

  Important
  The version you can download is _not a design_. It's a grid that creates a
  structure, puts elements we need on a (HTML) page, orders and groups them
  following the principles I've outlined above.

Please feel free to comment on it and ask questions. I've spent the last 5
days clicking the old interface, thinking and sitting before my current
proposal - I just might be blind to my own stupidity or brain dead by now. ;)

My goal is to agree on an information architecture, so we can go on and
create a design that combines functional requirements and aesthetics.

Once we've agreed on a design, we will create HTML templates and then we will
put them together with the upcoming REST client.

p at rick


-- 
state of mind
Agentur f?r Kommunikation, Design und Softwareentwicklung

http://www.state-of-mind.de

Franziskanerstra?e 15	   Telefon +49 89 3090 4664
81669 M?nchen              Telefax +49 89 3090 4666

Amtsgericht M?nchen        Partnerschaftsregister PR 563

From cmpalmer at garp.metalab.unc.edu  Thu Apr 23 07:17:26 2009
From: cmpalmer at garp.metalab.unc.edu (=?iso-8859-1?Q?Crist=F3bal?= Palmer)
Date: Thu, 23 Apr 2009 01:17:26 -0400
Subject: [Mailman-Developers] MM 2.1.12(rc2) backport for Ubuntu Hardy?
In-Reply-To: <3E5FC409-E502-401F-8A9A-C5D0C86003F0@python.org>
References: <20090422170145.GN26929@amyl.org.uk>
	<3E5FC409-E502-401F-8A9A-C5D0C86003F0@python.org>
Message-ID: <20090423051726.GO7203@garp.metalab.unc.edu>

On Wed, Apr 22, 2009 at 01:12:26PM -0400, Barry Warsaw wrote:
> On Apr 22, 2009, at 1:01 PM, Adam McGreggor wrote:
>
>> Just a quick query really (and possibly being slightly cheeky asking
>> here...), but have any of you guys backported Mailman 2.1.12 from the
>> Ubuntu Jaunty (or Debian 5) repos -> Ubuntu Hardy?

Not that one yet, but I have 2.1.11-12~ppa2 here:

https://launchpad.net/~cristobalpalmer/+archive/ppa

Took me a bit of stumbling to get it done. I wouldn't mind doing it again.

> providing PPAs for folks who want to run the latest and greatest.  I  
> don't have much packaging-fu but if someone wants to volunteer to do the 
> heavily lifting, I'd be happy to twiddle the Launchpad bits.

I'm happy to volunteer, but could it please wait until after the 27th?
That's my last exam this semester. :)

Cheers,
-- 
Crist?bal Palmer
ibiblio.org systems administrator
cdla.unc.edu research assistant

From adam-mailman at amyl.org.uk  Sun Apr 26 17:16:14 2009
From: adam-mailman at amyl.org.uk (Adam McGreggor)
Date: Sun, 26 Apr 2009 16:16:14 +0100
Subject: [Mailman-Developers] MM 2.1.12(rc2) backport for Ubuntu Hardy?
In-Reply-To: <20090423051726.GO7203@garp.metalab.unc.edu>
References: <20090422170145.GN26929@amyl.org.uk>
	<3E5FC409-E502-401F-8A9A-C5D0C86003F0@python.org>
	<20090423051726.GO7203@garp.metalab.unc.edu>
Message-ID: <20090426151614.GB26929@amyl.org.uk>

On Thu, Apr 23, 2009 at 01:17:26AM -0400, Crist?bal Palmer wrote:
> On Wed, Apr 22, 2009 at 01:12:26PM -0400, Barry Warsaw wrote:
> > On Apr 22, 2009, at 1:01 PM, Adam McGreggor wrote:
> >
> >> Just a quick query really (and possibly being slightly cheeky asking
> >> here...), but have any of you guys backported Mailman 2.1.12 from the
> >> Ubuntu Jaunty (or Debian 5) repos -> Ubuntu Hardy?
> 
> Not that one yet, but I have 2.1.11-12~ppa2 here:
> 
> https://launchpad.net/~cristobalpalmer/+archive/ppa
> 
> Took me a bit of stumbling to get it done. I wouldn't mind doing it again.

Ah, that would be useful. So far, I've got as far as building a new VM
(rather than building a new chroot; I've got some other bits I want to
play with, too). If you've got any notes on building it, could you point
us/me to them?

> I'm happy to volunteer, but could it please wait until after the 27th?
> That's my last exam this semester. :)

Sure!  (and bon chance!) ;) I ~may~ have a go at building one, if I get
bored/have nothing better to do tomorrow: might be interesting to
debdiff. Saying that, it takes me ages to ever do anything.


-- 
``Vote Labour -- Sleep Tory''
  (unofficial slogan of Oswald Mosley)

From barry at list.org  Mon Apr 27 05:07:15 2009
From: barry at list.org (Barry Warsaw)
Date: Sun, 26 Apr 2009 23:07:15 -0400
Subject: [Mailman-Developers] mailman 3: webinterface: prototype (PDF)
In-Reply-To: <20090423151623.GH7781@state-of-mind.de>
References: <20090423151623.GH7781@state-of-mind.de>
Message-ID: <1D86C4CF-83A1-4574-8D8A-6BA28BBB7A56@list.org>

On Apr 23, 2009, at 11:16 AM, Patrick Ben Koetter wrote:

> following our discussions at the Pycon 2009 Mailman sprint I've come  
> up with
> first draft of a/the future mailman 3 web interface.

Patrick, thanks very much for doing this.  I think it's a good way to  
begin the discussions.

One thing that it would be good to think about is how MM3's improved  
model can make navigation and configuration easier.  For example, when  
a user is thinking about her subscriptions, she needn't be constrained  
to a list-centric view.  In MM2, certain global operations were pure  
hacks, and a user always had to see a list-centric view.  For sites  
that run many inter-related mailing lists, the user will probably want  
to get a more general view of their subscriptions and options.

On Launchpad for example, they can go to one page that shows all their  
subscriptions.  Each mailing list that they are (or may) subscribe to  
is listed on one page, and each has a pull down menu that lets the  
user unsubscribe (i.e. not subscribed), subscribe with their  
"preferred email address" (a concept not yet exposed in Mailman, but  
which could be), or subscribed with a specific address.

This is nice because they can pretty easily manage all their  
subscriptions from one page.  You could imagine other global-ish  
things on this page, like vacation settings, or default site-wide user  
options.  This page might also contain widgets for registering and  
confirming additional email addresses linked to the user account.

On the list-admin side, another thing to think about is the  
application of styles.  A style needn't be just something that can be  
applied when the list is created.  Say for example, there is a "micro- 
style" that lets them disable digests and select a standard  
personalized footer.  That might be a style available to the list  
owner on their list page.

I do like the idea of a notifications area with a list of things a  
user can do (i.e. the "3 pending").  This of course would be linked to  
task-oriented pages for addressing those things.  A user might also  
see a list of registered emails that need confirming (with a link to  
send another confirmation message).

That's all for now.
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20090426/b6bc2def/attachment.pgp>

From barry at list.org  Mon Apr 27 05:09:34 2009
From: barry at list.org (Barry Warsaw)
Date: Sun, 26 Apr 2009 23:09:34 -0400
Subject: [Mailman-Developers] MM 2.1.12(rc2) backport for Ubuntu Hardy?
In-Reply-To: <20090426151614.GB26929@amyl.org.uk>
References: <20090422170145.GN26929@amyl.org.uk>
	<3E5FC409-E502-401F-8A9A-C5D0C86003F0@python.org>
	<20090423051726.GO7203@garp.metalab.unc.edu>
	<20090426151614.GB26929@amyl.org.uk>
Message-ID: <168909C1-AE74-461B-8DDA-9C5EF7A953C3@list.org>

On Apr 26, 2009, at 11:16 AM, Adam McGreggor wrote:

> On Thu, Apr 23, 2009 at 01:17:26AM -0400, Crist?bal Palmer wrote:
>> On Wed, Apr 22, 2009 at 01:12:26PM -0400, Barry Warsaw wrote:
>>> On Apr 22, 2009, at 1:01 PM, Adam McGreggor wrote:
>>>
>>>> Just a quick query really (and possibly being slightly cheeky  
>>>> asking
>>>> here...), but have any of you guys backported Mailman 2.1.12 from  
>>>> the
>>>> Ubuntu Jaunty (or Debian 5) repos -> Ubuntu Hardy?
>>
>> Not that one yet, but I have 2.1.11-12~ppa2 here:
>>
>> https://launchpad.net/~cristobalpalmer/+archive/ppa
>>
>> Took me a bit of stumbling to get it done. I wouldn't mind doing it  
>> again.
>
> Ah, that would be useful. So far, I've got as far as building a new VM
> (rather than building a new chroot; I've got some other bits I want to
> play with, too). If you've got any notes on building it, could you  
> point
> us/me to them?
>
>> I'm happy to volunteer, but could it please wait until after the  
>> 27th?
>> That's my last exam this semester. :)
>
> Sure!  (and bon chance!) ;) I ~may~ have a go at building one, if I  
> get
> bored/have nothing better to do tomorrow: might be interesting to
> debdiff. Saying that, it takes me ages to ever do anything.

Thanks for helping out here.  Please let me know if there's anything I  
can do to help.  At some point we'll probably want to give you  
permission to create packages in an official Mailman team in  
Launchpad, whether that's ~mailman-coders or another team specifically  
for the PPAs.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20090426/a33d18d5/attachment.pgp>

From p at state-of-mind.de  Mon Apr 27 11:11:11 2009
From: p at state-of-mind.de (Patrick Ben Koetter)
Date: Mon, 27 Apr 2009 11:11:11 +0200
Subject: [Mailman-Developers] mailman 3: webinterface: prototype (PDF)
In-Reply-To: <1D86C4CF-83A1-4574-8D8A-6BA28BBB7A56@list.org>
References: <20090423151623.GH7781@state-of-mind.de>
	<1D86C4CF-83A1-4574-8D8A-6BA28BBB7A56@list.org>
Message-ID: <20090427091110.GA19288@state-of-mind.de>

* Barry Warsaw <barry at list.org>:
> On Apr 23, 2009, at 11:16 AM, Patrick Ben Koetter wrote:
>
>> following our discussions at the Pycon 2009 Mailman sprint I've come  
>> up with
>> first draft of a/the future mailman 3 web interface.
>
> Patrick, thanks very much for doing this.  I think it's a good way to  
> begin the discussions.
>
> One thing that it would be good to think about is how MM3's improved  
> model can make navigation and configuration easier.  For example, when a 
> user is thinking about her subscriptions, she needn't be constrained to a 
> list-centric view.  In MM2, certain global operations were pure hacks, 
> and a user always had to see a list-centric view.  For sites that run 
> many inter-related mailing lists, the user will probably want to get a 
> more general view of their subscriptions and options.
>
> On Launchpad for example, they can go to one page that shows all their  
> subscriptions.  Each mailing list that they are (or may) subscribe to is 
> listed on one page, and each has a pull down menu that lets the user 
> unsubscribe (i.e. not subscribed), subscribe with their "preferred email 
> address" (a concept not yet exposed in Mailman, but which could be), or 
> subscribed with a specific address.

Agreed. We discussed that at the sprint and I think the navigation structure I
have come up with allows for that:

<http://wiki.list.org/display/DEV/global+requirements#globalrequirements-NavigationStructure>

Here's the excerpt of a users navigation structure:

options
    general
    topics
    plugins
subscriptions
    subscribe
    remove
    modify
statistics
    List

A (regular) user, for example, would do this to see a list of all current
subscriptions:

        Go to top level menu item: "subscriptions"
        This will show a list of all current subscriptions that could be
        individually choosen for "unsubscription" or "modification".
        Also all subscriptions could "inherit" applicable settings from the
        currently choosen account.

If user wanted to subscribe another list a subpage would have to be choosen.
This page would list all available subscriptions. It's a separate page on
purpose to prevent information overflow if we'd put it all in one page.


What do you think? Should I comment the navigation structures? I've put a lot
of thinking into it and that is, of course, not visible. I could comment and
we'd have it easier to see where I think things should be put to.


> This is nice because they can pretty easily manage all their  
> subscriptions from one page.  You could imagine other global-ish things 
> on this page, like vacation settings, or default site-wide user options.  

Yep.

> This page might also contain widgets for registering and confirming 
> additional email addresses linked to the user account.

Agreed, but having the concept of a task-oriented navigation in mind I'd
probably put this on the users personal homepage.


> On the list-admin side, another thing to think about is the application 
> of styles.  A style needn't be just something that can be applied when 

Style as in "profile"? 

Just to think of two prototypes:

Techi-Profile
  No HTML Mail
  No Attachments

Party-Profile
  HTML Mail
  Attachments


> the list is created.  Say for example, there is a "micro-style" that lets 
> them disable digests and select a standard personalized footer.  That 
> might be a style available to the list owner on their list page.
>
> I do like the idea of a notifications area with a list of things a user 
> can do (i.e. the "3 pending").  This of course would be linked to  
> task-oriented pages for addressing those things.  A user might also see a 
> list of registered emails that need confirming (with a link to send 
> another confirmation message).

Yes. They have to functions:
1. Notify user if (!) attention is required (hide otherways...)
2. Provide quick-/deeplink into the lower navigation levels without having the
   user click through tons of navigation levels (or even worse clicking through
   the whole site because they don't remember where it was).


> That's all for now.

We will start working on design May, 1st. Minor changes to pages and elements
are possible. I'd like to avoid major changes after that - the effort of
redoing design is immense.

Think we can get the discussion to a point of "let's start design" 'til then?

p at rick


-- 
state of mind
Agentur f?r Kommunikation, Design und Softwareentwicklung

http://www.state-of-mind.de

Franziskanerstra?e 15	   Telefon +49 89 3090 4664
81669 M?nchen              Telefax +49 89 3090 4666

Amtsgericht M?nchen        Partnerschaftsregister PR 563

From barry at list.org  Mon Apr 27 14:11:42 2009
From: barry at list.org (Barry Warsaw)
Date: Mon, 27 Apr 2009 08:11:42 -0400
Subject: [Mailman-Developers] mailman 3: webinterface: prototype (PDF)
In-Reply-To: <20090427091110.GA19288@state-of-mind.de>
References: <20090423151623.GH7781@state-of-mind.de>
	<1D86C4CF-83A1-4574-8D8A-6BA28BBB7A56@list.org>
	<20090427091110.GA19288@state-of-mind.de>
Message-ID: <80DE1576-55D9-4BA6-9555-10AA086818C0@list.org>

On Apr 27, 2009, at 5:11 AM, Patrick Ben Koetter wrote:

> Agreed. We discussed that at the sprint and I think the navigation  
> structure I
> have come up with allows for that:
>
> <http://wiki.list.org/display/DEV/global+requirements#globalrequirements-NavigationStructure 
> >
>
> Here's the excerpt of a users navigation structure:
>
> options
>    general
>    topics
>    plugins
> subscriptions
>    subscribe
>    remove
>    modify
> statistics
>    List
>
> A (regular) user, for example, would do this to see a list of all  
> current
> subscriptions:
>
>        Go to top level menu item: "subscriptions"
>        This will show a list of all current subscriptions that could  
> be
>        individually choosen for "unsubscription" or "modification".
>        Also all subscriptions could "inherit" applicable settings  
> from the
>        currently choosen account.
>
> If user wanted to subscribe another list a subpage would have to be  
> choosen.
> This page would list all available subscriptions. It's a separate  
> page on
> purpose to prevent information overflow if we'd put it all in one  
> page.
>
>
> What do you think? Should I comment the navigation structures? I've  
> put a lot
> of thinking into it and that is, of course, not visible. I could  
> comment and
> we'd have it easier to see where I think things should be put to.

That does sound good.  Comments, or some other way to capture your  
thinking behind it, would be good.

>> This is nice because they can pretty easily manage all their
>> subscriptions from one page.  You could imagine other global-ish  
>> things
>> on this page, like vacation settings, or default site-wide user  
>> options.
>
> Yep.
>
>> This page might also contain widgets for registering and confirming
>> additional email addresses linked to the user account.
>
> Agreed, but having the concept of a task-oriented navigation in mind  
> I'd
> probably put this on the users personal homepage.

Agreed.

>> On the list-admin side, another thing to think about is the  
>> application
>> of styles.  A style needn't be just something that can be applied  
>> when
>
> Style as in "profile"?
>
> Just to think of two prototypes:
>
> Techi-Profile
>  No HTML Mail
>  No Attachments
>
> Party-Profile
>  HTML Mail
>  Attachments

In a sense.  Technically, a "list style" is just a named collection of  
list variable settings, so it could be anything.  The plan is to allow  
site admins (and maybe list admins) create new styles, which would be  
applied by name.

>> the list is created.  Say for example, there is a "micro-style"  
>> that lets
>> them disable digests and select a standard personalized footer.  That
>> might be a style available to the list owner on their list page.
>>
>> I do like the idea of a notifications area with a list of things a  
>> user
>> can do (i.e. the "3 pending").  This of course would be linked to
>> task-oriented pages for addressing those things.  A user might also  
>> see a
>> list of registered emails that need confirming (with a link to send
>> another confirmation message).
>
> Yes. They have to functions:
> 1. Notify user if (!) attention is required (hide otherways...)
> 2. Provide quick-/deeplink into the lower navigation levels without  
> having the
>   user click through tons of navigation levels (or even worse  
> clicking through
>   the whole site because they don't remember where it was).

+1

>> That's all for now.
>
> We will start working on design May, 1st. Minor changes to pages and  
> elements
> are possible. I'd like to avoid major changes after that - the  
> effort of
> redoing design is immense.
>
> Think we can get the discussion to a point of "let's start design"  
> 'til then?

I think so.  I'll be largely unavailable the second half of May.  In  
the meantime, I'm still working on the REST infrastructure.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20090427/9460a67a/attachment.pgp>

From terri at zone12.com  Mon Apr 27 18:10:30 2009
From: terri at zone12.com (Terri Oda)
Date: Mon, 27 Apr 2009 12:10:30 -0400
Subject: [Mailman-Developers] mailman 3: webinterface: prototype (PDF)
In-Reply-To: <20090427091110.GA19288@state-of-mind.de>
References: <20090423151623.GH7781@state-of-mind.de>	<1D86C4CF-83A1-4574-8D8A-6BA28BBB7A56@list.org>
	<20090427091110.GA19288@state-of-mind.de>
Message-ID: <49F5D8F6.102@zone12.com>

> What do you think? Should I comment the navigation structures? I've put a lot
> of thinking into it and that is, of course, not visible. I could comment and
> we'd have it easier to see where I think things should be put to.

I love how you've put all this thought into a better structure here. 
But no matter how much thought goes into it, someone's gonna have 
trouble finding stuff in a tree that big...

Can we add a search box for options?  It might not be necessary on the 
smaller pages, but the full admin/owner interface looks like it's still 
going to be sufficiently busy that it could help.

> We will start working on design May, 1st. Minor changes to pages and elements
> are possible. I'd like to avoid major changes after that - the effort of
> redoing design is immense.

Can we please please please do some user testing on the initial designs 
before they get set in stone?  Ideally, I think we'd want to do this at 
the point where there's a clickthrough prototype.  Then we could sit 
some people down and ask them to do some tasks, and see how long it 
takes/where they go wrong.  Plus we could get general impressions on 
usability from the mailman-users list.

  Terri

From barry at list.org  Mon Apr 27 18:27:35 2009
From: barry at list.org (Barry Warsaw)
Date: Mon, 27 Apr 2009 12:27:35 -0400
Subject: [Mailman-Developers] mailman 3: webinterface: prototype (PDF)
In-Reply-To: <49F5D8F6.102@zone12.com>
References: <20090423151623.GH7781@state-of-mind.de>	<1D86C4CF-83A1-4574-8D8A-6BA28BBB7A56@list.org>
	<20090427091110.GA19288@state-of-mind.de> <49F5D8F6.102@zone12.com>
Message-ID: <A9F7266E-F2F0-45D4-9648-BF4D4B37CD71@list.org>

On Apr 27, 2009, at 12:10 PM, Terri Oda wrote:

> Can we add a search box for options?  It might not be necessary on  
> the smaller pages, but the full admin/owner interface looks like  
> it's still going to be sufficiently busy that it could help.
>
>> We will start working on design May, 1st. Minor changes to pages  
>> and elements
>> are possible. I'd like to avoid major changes after that - the  
>> effort of
>> redoing design is immense.
>
> Can we please please please do some user testing on the initial  
> designs before they get set in stone?  Ideally, I think we'd want to  
> do this at the point where there's a clickthrough prototype.  Then  
> we could sit some people down and ask them to do some tasks, and see  
> how long it takes/where they go wrong.  Plus we could get general  
> impressions on usability from the mailman-users list.

Both are excellent suggestions Terri.  Thanks!
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20090427/e02f9a70/attachment.pgp>

From p at state-of-mind.de  Mon Apr 27 23:18:22 2009
From: p at state-of-mind.de (Patrick Ben Koetter)
Date: Mon, 27 Apr 2009 23:18:22 +0200
Subject: [Mailman-Developers] mailman 3: webinterface: prototype (PDF)
In-Reply-To: <49F5D8F6.102@zone12.com>
References: <20090423151623.GH7781@state-of-mind.de>
	<1D86C4CF-83A1-4574-8D8A-6BA28BBB7A56@list.org>
	<20090427091110.GA19288@state-of-mind.de> <49F5D8F6.102@zone12.com>
Message-ID: <20090427211822.GC5398@state-of-mind.de>

Terri,

thanks for taking the time to read my proposal and writing this email.

* Terri Oda <terri at zone12.com>:
>> What do you think? Should I comment the navigation structures? I've put a lot
>> of thinking into it and that is, of course, not visible. I could comment and
>> we'd have it easier to see where I think things should be put to.
>
> I love how you've put all this thought into a better structure here. But 
> no matter how much thought goes into it, someone's gonna have trouble 
> finding stuff in a tree that big...

Yes. For a list owner this seems acceptable to me. Those are the ones who are
willing to spend some time - they expect a certain level of complexity because
they know the software is complex.

For a regular subscriber the interface should be as simple as possible (but
not simplier or they will think we believe they are stupid ;).


> Can we add a search box for options?  It might not be necessary on the  
> smaller pages, but the full admin/owner interface looks like it's still  
> going to be sufficiently busy that it could help.

We can. But I, personally, would want to wait for usability test and see if we
can do without it simply because it makes the interface more complex.

Reason is, I have planned search boxes for several other use cases e.g.
finding a subscriber, a mail address etc.

I would rather not have two search boxes fanning out ambiguity and competing
for user attention - unless we need to.

I do believe complexity is a deliberate decision.

>> We will start working on design May, 1st. Minor changes to pages and elements
>> are possible. I'd like to avoid major changes after that - the effort of
>> redoing design is immense.
>
> Can we please please please do some user testing on the initial designs  
> before they get set in stone?  Ideally, I think we'd want to do this at  

Yes, very welcome.

> the point where there's a clickthrough prototype.  Then we could sit  
> some people down and ask them to do some tasks, and see how long it  

The test scenario affects the outcome of the test. We need to standardize the
test before we run it. I might be able to get some people from a usability lab
we work with help us. Let me check that.

> takes/where they go wrong.  Plus we could get general impressions on  
> usability from the mailman-users list.

We should also manage the change actively e.g. provide a little website that
explains why things have changed, where they have gone etc.

The goal would be to re-empower the people and give them the security back
they have accquired using the old interface over the years.

p at rick

-- 
state of mind
Agentur f?r Kommunikation, Design und Softwareentwicklung

http://www.state-of-mind.de

Franziskanerstra?e 15      Telefon +49 89 3090 4664
81669 M?nchen              Telefax +49 89 3090 4666

Amtsgericht M?nchen        Partnerschaftsregister PR 563


From p at state-of-mind.de  Wed Apr 29 23:43:11 2009
From: p at state-of-mind.de (Patrick Ben Koetter)
Date: Wed, 29 Apr 2009 23:43:11 +0200
Subject: [Mailman-Developers] mailman 3: webinterface: prototype (PDF)
In-Reply-To: <80DE1576-55D9-4BA6-9555-10AA086818C0@list.org>
References: <20090423151623.GH7781@state-of-mind.de>
	<1D86C4CF-83A1-4574-8D8A-6BA28BBB7A56@list.org>
	<20090427091110.GA19288@state-of-mind.de>
	<80DE1576-55D9-4BA6-9555-10AA086818C0@list.org>
Message-ID: <20090429214311.GC5101@state-of-mind.de>

* Barry Warsaw <barry at list.org>:
>> What do you think? Should I comment the navigation structures? I've  put a
>> lot of thinking into it and that is, of course, not visible. I could
>> comment and we'd have it easier to see where I think things should be put
>> to.
>
> That does sound good.  Comments, or some other way to capture your  
> thinking behind it, would be good.

I created a separate page for each role (admin, moderator, subscriber) and
added notes to each menu item. If you want to start with a top view, start
here:

    <http://wiki.list.org/display/DEV/global+requirements>

Then, in each subsection of "Navigation Structure" choose "See a commented
<role> navigation structure."

To jump right at it:

    administrator navigation structure
    <http://wiki.list.org/display/DEV/administrator+navigation+structure>

    moderator navigation structure
    <http://wiki.list.org/display/DEV/moderator+navigation+structure>

    subscriber navigation structure
    <http://wiki.list.org/display/DEV/subscriber+navigation+structure>


p at rick

-- 
state of mind
Agentur f?r Kommunikation, Design und Softwareentwicklung

http://www.state-of-mind.de

Franziskanerstra?e 15      Telefon +49 89 3090 4664
81669 M?nchen              Telefax +49 89 3090 4666

Amtsgericht M?nchen        Partnerschaftsregister PR 563

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20090429/b593ca6f/attachment.pgp>