Hi Barry,
bwarsaw(a)users.sourceforge.net wrote:
> Revision: 8184
> http://svn.sourceforge.net/mailman/?rev=8184&view=rev
> Author: bwarsaw
> Date: 2007-03-29 22:09:36 -0700 (Thu, 29 Mar 2007)
>
> Log Message:
> -----------
> api_lock(): When locking the MailList object, tell the SQLAlchemy session to
> expire the object. This way, when the MailList attributes are next accessed,
> the ORM will reload them from the database, getting any new values possibly
> set in other processes.
>
> This works better than trying to use always_refresh=True on the mapper, or
> trying to do a reload() because both of those approaches blow away locks. I'm
> not sure why this, but I suspect that it's because the identity map is handing
> us back a different object, rather than invalidating the object's attributes.
>
> Modified Paths:
> --------------
> trunk/mailman/Mailman/database/dbcontext.py
> trunk/mailman/Mailman/testing/test_handlers.py
>
> Modified: trunk/mailman/Mailman/database/dbcontext.py
> ===================================================================
> --- trunk/mailman/Mailman/database/dbcontext.py 2007-03-27 06:35:12 UTC (rev 8183)
> +++ trunk/mailman/Mailman/database/dbcontext.py 2007-03-30 05:09:36 UTC (rev 8184)
> @@ -129,6 +129,7 @@
>
> # Higher level interface
> def api_lock(self, mlist):
> + self.session.expire(mlist)
> # Don't try to re-lock a list
> if mlist.fqdn_listname in self._mlist_txns:
> return
>
Wow! Fix is so simple.
I've done a test with this using two terminals:
terminal A terminal B
$ bin/withlist test $ bin/withlist test
>>> m.description
u''
>>> m.Lock()
>>> m.description = 'test'
>>> m.Save()
>>> m.Load()
>>> m.description
u''
>>> m.Unlock()
>>> m.Lock()
>>> m.description
u'test'
Mere Load() can't refresh the list attributes but needs Lock() to get
them. A few problem remains like decorating the message where
OutgoingRunner is used. This runner don't update the database so it
doesn't use Lock() but only Load(). We should fix them to use Lock()
(and Unlock()) to reload data.
--
Tokio Kikuchi, tkikuchi(a)is.kochi-u.ac.jp
http://weather.is.kochi-u.ac.jp/
Hi Barry,
Since we at Japanese universities are in Spring vacation, I started
testing 2.2 code on my PC. What is curious about the LMTP/HTTP
interfaces with SQLAlchemy based database is that changes commited in
LMTP/HTTP sessions cannot be reflected on the other sessions. If I
subscribe an address via HTTP then it cannot be unsubscribed from LMTP
and vise versa, until I restart the runners. Perhaps we need a reload
mechanism but I don't know how to implement it.
Other than that, I think I've checked with i18n plain text message
deliveries for both regular and digest. Still to go are mime multipart
messages and archives.
I've also added a comment on Testing Mailman 2.2 wiki page how to test
run the 2.2 code.
Cheers,
--
Tokio Kikuchi, tkikuchi(a)is.kochi-u.ac.jp
http://weather.is.kochi-u.ac.jp/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Tokio,
Thanks for the patches, and especially the test cases! I have a
couple of questions for you.
I noticed that current trunk is failing three tests:
test_no_multipart_mixed_charset
test_scrub_image
test_scrub_text
Can you check to see if those are failing for you?
Also I was wondering about the latest change to passwords.py:
On Mar 24, 2007, at 10:57 PM, tkikuchi(a)users.sourceforge.net wrote:
> Modified: trunk/mailman/Mailman/passwords.py
> ===================================================================
> --- trunk/mailman/Mailman/passwords.py 2007-03-24 06:01:35 UTC (rev
> 8180)
> +++ trunk/mailman/Mailman/passwords.py 2007-03-25 02:57:18 UTC (rev
> 8181)
> @@ -240,6 +240,9 @@
> scheme = scheme_parts[0].lower()
> scheme_enum = _SCHEMES_BY_TAG.get(scheme, _DEFAULT_SCHEME)
> scheme_class = _SCHEMES_BY_ENUM[scheme_enum]
> + if isinstance(rest_group, unicode):
> + # decode() fails. (challenge is from database)
> + rest_group = str(rest_group)
> return scheme_class.check_response(rest_group, response,
> *scheme_parts[1:])
Earlier, I was using s.encode('utf-8') to ensure that we had an 8-bit
string for the hash function. I'm wondering if you prefer str()
over .encode('utf-8') here and if so, what the reason is?
Cheers,
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRghtRXEjvBPtnXfVAQJAXQP/enWB9iOvVDJ6B+k3ggN32EjszSH4XvKU
lY9A6gomMIdE+gIivNtbBx6ziv6w2AvYkV2fBC3sc5ooyZGQesjl5gpeZ53AwCyF
HF9bVQuW72L9TxvWIYOO+wnADr97YyYSU/rNHT7GPua5Z+1SnwF5FQknFtpVFZdO
yqzwK5b5C5E=
=moCg
-----END PGP SIGNATURE-----
I have been working on a fix for the problem of Mailman's dropping
format=flowed from Content-Type: headers. There is a bug report and a
patch at
<https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1495122&group_…>.
The patch to Scrubber.py has just been revised (revised patch is
attached to the above tracker item).
Scrubber would throw an exception when processing a message with no
text/plain part. If you are using a prior version of this patch,
please get the current version to avoid this problem.
--
Mark Sapiro <msapiro(a)value.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mar 20, 2007, at 7:13 PM, msapiro(a)users.sourceforge.net wrote:
> Revision: 8169
> http://svn.sourceforge.net/mailman/?rev=8169&view=rev
> Author: msapiro
> Date: 2007-03-20 16:13:26 -0700 (Tue, 20 Mar 2007)
>
> Log Message:
> -----------
> - Fixed a bug in OldStyleMemberships.addNewMember that allowed
> adding an address
> with upper case in the domain if the local part was all lower case.
> - Changed the semantics of OldStyleMemberships.changeMemberAddress
> os that
> in the case of a straightforward address change, i.e. nodelete = 0,
> delivery status and time are preserved if BYUSER or BYADMIN.
>
> Modified Paths:
> --------------
> trunk/mailman/Mailman/OldStyleMemberships.py
Thanks for fixing this Mark. For the change on the trunk, do you
think we can get test cases in there for these two bugs? (Probably
test_membership.py is a good place to add them.)
Cheers,
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRgE7S3EjvBPtnXfVAQLpSgP/XO+95FBO1yabTt5/L+76JLM3xX0PyqvP
Xc2Wob4tJUdFBq9ibP8OXnfFXR3eZxjVEdMTMHMwJ6L96y53sbBgnwyVALh+A3T7
oK/Isqlw8ThITN8UgQB2tTYekaA4O5Ay5lNxW0Pyhd1v8pangK9NO6Q/2ZkdJtQI
fsTT0nJXNJE=
=TnNK
-----END PGP SIGNATURE-----
This link may be of interest to the Mailman dev team.
-------- Forwarded Message --------
From: Kiss Gabor (Bitman) <kissg(a)ssg.ki.iif.hu>
To: fmouse(a)fmp.com
Subject: A work based on your nmzproc
Date: Mon, 19 Mar 2007 13:17:35 +0100 (CET)
Hi Lindsay,
Maybe you are interested in this document.
http://bakacsin.ki.iif.hu/~kissg/project/mailman+namazu/
Regards
Gabor
Hi all,
here's finally my next proposal for a less broken but yet very useful
reply-to-munging:
- Motivation
Non-technical users (generally) love defaults. They don't wanna have to
choose between three different kind of reply buttons. And no-way they want
to change their MUA they just got painfully used to (or even their mail
address, as most of them are using webmail providers), just because of a
stupid mailing list. So there's a user base who are mostly using webmailers
and Outlook, and who just want to press "Reply" as they usually do, no
matter if there is even a "Reply-To-All" button right next to it.
Although this is a big pain for us geeks, I think a great software like
Mailman should offer options (not default behavior) to serve such a user
base. That's why I think, that Mailman should offer an option to set the
default behavior of the standard reply button. The question what the default
behavior of the reply button should be has to be discussed in each lists
user base, Mailman should offer the choice. Many list admins are very
thankful, if they don't have to educate their users.
- Proposed solution
There is no RFC-way to set the default address for replies. The Reply-To
header _replaces_ the From address in replies, which is something else than
setting a default. That's why setting the Reply-To completely hides the From
address (regarding replies) and therefore abusing it as a default breaks the
reply-to-all function for instance, as it doesn't include the From address
neither (which is correct, as long as the Reply-To address is an
_replacement_ for the From address). Since there is no other way but to
abuse the Reply-To header to control the default reply behavior,
reply-to-munging has to take care of the From address too.
There are four possible default reply targets that I consider as useful and
should be offered at least as a list-wide option. (If individual mails are
sent out, like with VERP, a per-user option is the best of course.)
1. Author
2. List
3. All recipients and author
4. Explicit address
And this is, what I propose that Mailman should do in these cases:
ad 1) Author is the "default default target" ;-). So no munging needed at
all, no problems.
ad 2) If Reply-To is already set, it is removed. Reply-To is set to the
lists address. The old Reply-To or - if not existing - the From address is
checked if it is a list member. If not, it is added as a "fake Cc" to the Cc
header, in order to make the reply-to-all function work.
ad 3) If Reply-To is already set, it is removed. Reply-To is set to:
- the lists address,
- all addresses in To/Cc headers, that are no list members, and
- the old Reply-To or - if not existing - the From address, if not a list
member
ad 4) If Reply-To is already set, it is removed. Reply-To is set to the
explicit address. The old Reply-To or - if not existing - the From address
is checked if it is a list member. If not, it is added as a "fake Cc" to the
Cc header, in order to make the reply-to-all function work.
Of course, with option 2-4 you still lose the reply-to-author function, but
at least for 2 and 4 in exchange for a new function, which a standard MUA
with just a reply and reply-to-all button doesn't offer.
Example: Me and two colleagues are the management board of a local radio
station. We use Mailman as a "Deluxe-Alias" for both communication among us
and as Alias for people who want to contact us. So a lot of mails on this
list come from non-members. In these cases I either want to answer only to
the list (my colleagues) or to the author and the list, but _never_ to the
author alone. So it's obvious that in this case we would like to have the
reply button going to the list, and reply-to-all going to all (including the
author, what at the moment doesn't work). We want the default going to the
list, not only because of our MUAs (Thunderbird, Mutt, Webmailer) only Mutt
supports reply-to-list, but also because we want the default reply to be the
least dangerous, which in our case is the list. Funnily enough, the mutt
user wants the most, that the normal reply is going to the list. ;-)
I hope I could make clear my ideas and point of view.
Cheers,
Sven
Hi,
as many of you probably would agree, whether you munge the Reply-To headers
or not, both ways are not perfect. Just today I had a hard time again, as
I'm not happy with both options, and finally came up with some ideas how the
situation could be improved, about which I would like to read your comments:
1) Receiver clean-up (if Reply-To munging is NOT used)
One of the problems not using Reply-To munging is, that by using the
reply-to-all function of MUAs the list of receivers tends to accumulate. As
in open lists the users cannot know, if an address is part of the list, they
cannot just delete them without risking to drop people from the discussion.
So what about an option to clean-up the receivers list in Mailman, that is
Mailman removes all To/CC addresses which are members of the list?
2) Add non-member-senders to Reply-To (if Reply-To munging IS used)
One of the annoying things using Reply-To munging in open lists is, that you
cannot easily include external authors in replies, whether you are using
reply-to or reply-to-all in your MUA. It would be nice, if the sender could
be added to the Reply-To addresses in the case, that the sender is not a
member of the list, so that replies automatically go to the list AND the
author. (Of course, this should be done only, if the sender didn't set his
own Reply-To header already.)
3) Add sender to Reply-To (if Reply-To munging IS used)
As an variation to the proposal 2) it also would be nice to have the sender
in general be added to the Reply-To header. That would make replies behave
similar as the reply-to-all in case of no Reply-To munging. This makes it
easier to reply only to the author, and not the whole list, by just deleting
the list address while replying. Because you can also have address
accumulation in that case, if users use the reply-to-all function, you could
combine this option with the "receiver clean-up" option from proposal 1).
As proposal 3) doesn't need to know the member status of addresses, you can
also easily implement it in the MTA, therefore it is the least important one.
What do you think about that? (With some help I can also try to implement
this on my own, if there are chances to include it into the official Mailman.)
Cheers,
Sven