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@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
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)
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
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. :):)
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
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(a)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
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
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@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(a)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(a)python.org.
Cheers,
--
Skip Montanaro - skip(a)pobox.com - http://www.smontanaro.net/
"XML sucks, dictionaries rock" - Dave Beazley
