I realize Topics are not widely implemented but would love to see this
feature for the few lists who do use them. One very non-technical chat
list I'm on is almost ten years old and split off of a much older list on
the same subject. Last year I helped them move to Mailman from that
expensive service whose name I shall not mention.
Not only does this list use Topics (16 at the moment) it also allows, even
welcomes pictures and allows a few other types of attachments. However, it
is always confusing which Topic to use. Not all attachments are
pictures... Bottom line is that no matter what naming schema is used
*someone* will get confused and then gets yelled at by the current list
owner (not me, I ain't taking the job!) for posting attachments to the
wrong Topic. Not only is this embarrassing for the 'yellie', it annoys
the rest of the members seeing this same scene play out every few months.
Worst of all leads to early list owner burn out and good ones as we all
know are rather hard to find.
If message size limits could be set per topic then an impartial
reply-bot would get to be the heavy in private. If this would be too code
bloating, then having two (or perhaps three) levels of size limits with
each Topic being assigned to a level would work just as well.
Thanks.
--
William
Hi all,
I see quite a lot of fixes have accumulated since 2.1.13 was released last
december. I was wondering if a new release in the stable series is planned in
the near future. At least for Debian's schedule it would be nice to have a
2.1-release sometime this summer.
Cheers,
Thijs
Hi all,
I have recently been working on a small REST client library for mailman3 [1]. The purpose of this library is to make it easier for UI developers to access MM3's new REST API. The library will also be used in the MM django UI which is currently being built.
Anna Granudd (who is working on the MM django UI as well as the client) and I have been discussing how this library could access and edit mailing list settings - which is not only a question of how the library itself should work, but also what resources should be exposed by the API under which URL.
Both the client and the API are still work in progress, so we thought we ask for opinions on how things could be done.
For example: At the moment an API request to /3.0/lists/listname(a)example.org exposes only some basic list information. Would it be a good idea to let this URL expose more list details (i.e. all list settings) or would it be better to have a different URL for that? (Something like /3.0/lists/listname(a)example.com/settings).
Why a different URL for the settings? Obviously the first option (one URL for all list details) would be simpler and, as a developer, you would have all information at hand with only one call. Wether you use that info to build a detailed settings page or just a small list info page wouldn't matter.
On the other hand there are quite a lot of DB fields for every list and that means quite a bit of traffic every time you access them through the API. That's why it could make sense to use different URLs.
So if we went for the latter option: Why not go even further and access the settings field by field? Or in smaller groups, i.e.:
/3.0/lists/listname(a)example.com/settings/archiving
Thanks for your thoughts!
Florian
[1] https://code.launchpad.net/~flo-fuchs/mailman/restclient/+merge/28522
--
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
Heckmannufer 2 Telefon +49 30 3013 6756
10997 Berlin Mobil +49 176 2064 0812
Amtsgericht München Partnerschaftsregister PR 563e
Due to maintenance - we replace our VM host and migrate from XEN to KVM -
mailman.state-of-mind.de will not be available until Friday, July 16th EBD.
p@rick
--
state of mind
Digitale Kommunikation
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
[Sorry I'm late... didn't notice this list is set to reply to sender instead
of the whole list.]
In model/docs/users.txt, it says "Users are entities that represent people.
A user has a real name and a password.... " As yet (rev 6869), none of the
methods provided in the class User itself make use of that password.
LDAP and OpenID are fairly common situations where using Mailman's own
username/password is not helpful. I know that one of my major challenges
with MM2 was whacking it upside the head hard enough that I could use the
AASV's membership database instead of Mailman's users to control access (it
sort of half works) and list membership (still using the import script :-(
).
An extensible plug-in architecture would be really useful here, I think. You
could even have a plug-in that determines what plug-in to hand-off to -- for
environments like Ian's where some users use LDAP and some use a
stored/hashed password.
Presuming the storage mechanism isn't limiting the length of the "password"
(i.e., only 32 characters for a hex MD5 or something like that), I think
that this field could be overloaded to support a variety of uses and
plug-ins. If we used something akin to IRI/URI/URL formatting, the
authentication method used for a particular user account could be
represented right there. For example, plug-ins that come bundled with
Mailman could use the plug-in name in the method part:
openid:///myopenidusername.openidprovider.comldap://ldapserver.example.com/username
sha1:///6aafb9bd47e1a38bbb99043c638f192f89c87930
Plug-ins created apart from Mailman could be loaded via a "private" plug-in
that loads the user identified by the host.domain part of the URI to protect
against name collisions:
private://members.aasv.org/whatever_private_data_I_want_goes_here
(You could still fall back to the password field containing just a hash and
hope/presume it's an unsalted MD5 or something like that.)
For web-based authentication, there will need to be some sort of
authentication target page that can load the appropriate plug-in. In the
example of OpenID, the user might typically be redirected away from the
mailman host to the OpenID provider's page, then come back to mailman via
GET with validation information in the query.
Another issue to consider is that the "real name" attribute of the Mailman
User might better be obtained from the external authentication
service/plug-in -- such as LDAP or OpenID, (or the AASV member database).
Indeed, it seems that the essential role of the Mailman User is to provide a
root node for the collection of associated addresses and their memberships.
Having the password and real name attributes makes it a lot easier
(possible) to install and configure Mailman as a standalone application, but
they are somewhat superfluous when they can be obtained from a more
authoritative source.
Dave
--
David Brown
dave(a)aasv.org ; webmaster(a)aasv.org
-----Original Message-----
From: mailman-developers-bounces+dave=aasv.org(a)python.org
[mailto:mailman-developers-bounces+dave=aasv.org@python.org] On Behalf Of
Anna Granudd
Sent: Friday, July 09, 2010 6:12 AM
To: Mailman-developers
Subject: [Mailman-Developers] password handling in MM3
Hi,
when subscribing a user or creating a list in Mailman 3.0 we need to
implement the use of a password for security reasons. Later the same
password will be used for logging in to the settings pages. At the moment
passwords are not handled at all which is why I filed bug #600780 (see [1]).
However, we're not sure how to handle the passwords at the moment and would
like your help with ideas and possible ways to implement this, which is why
I want to start a discussion about the password handling/ login function.
What do we need to think of and how should this best be dealt with?
Thanks,
Anna
[1] https://bugs.launchpad.net/mailman/+bug/600780
_______________________________________________
Mailman-Developers mailing list
Mailman-Developers(a)python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/dave%40aasv.org
Security Policy: http://wiki.list.org/x/QIA9
Hi,
when subscribing a user or creating a list in Mailman 3.0 we need to
implement the use of a password for security reasons. Later the same
password will be used for logging in to the settings pages. At the moment
passwords are not handled at all which is why I filed bug #600780 (see [1]).
However, we're not sure how to handle the passwords at the moment and would
like your help with ideas and possible ways to implement this, which is why
I want to start a discussion about the password handling/ login function.
What do we need to think of and how should this best be dealt with?
Thanks,
Anna
[1] https://bugs.launchpad.net/mailman/+bug/600780
Hi,
I'm currently working on the (Django) views for the Mailman 3.0 UI. I looked
at what mock-ups were made in the wiki, [1], and realized that so far there
are no mock-ups for the user settings page. Therefore, I was wondering if
anybody has any thoughts on what to think of when designing this page and
how you would like it to look like. We could start with using the old user
settings page design from older versions of Mailman and just "freshing it
up" a bit or we could make a complete redesign but it would be nice to get
some peoples' opinions on what you want before starting (although just
writing your thoughts down and emailing them works as well, if you don't
feel like creating mock-ups).
Thanks,
Anna
[1] http://wiki.list.org/display/DEV/Web+UI+Mockups
