Public bug reported:
With the new web UI, there should be a feature to have message footers
include a link to the message in the web UI
** Affects: mailman
Importance: Undecided
Status: New
** Tags: wishlist
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1104484
Title:
Link to post in email footer
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1104484/+subscriptions
Public bug reported:
I am seeing concurrency issues when using mailman 3 in a threaded
application server.
Reading the Storm documentation it states that "Store objects are not
threadsafe. [...] Therefore, the best policy is usually to create a
Store object for each thread which needs one"
(https://storm.canonical.com/Manual#Working_with_multiple_threads)
In mailman/database/base.py:141 I see a Store being created and cached.
As recommended in the storm docs, Stores should not be cached.
** Affects: mailman
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1096812
Title:
Threading issues in mailman 3.0.0b2
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1096812/+subscriptions
Public bug reported:
If message sent to mailman not contains a text/plain message part (i.e.
only text/html), an error is raised and the message gets swallowed.
I fixed this this way in my setup:
=== modified file 'src/mailman/rules/approved.py'
--- src/mailman/rules/approved.py 2012-07-02 20:08:58 +0000
+++ src/mailman/rules/approved.py 2013-01-04 13:31:09 +0000
@@ -73,6 +73,8 @@
stripped = False
for part in typed_subpart_iterator(msg, 'text', 'plain'):
break
+ if not part:
+ return False
payload = part.get_payload(decode=True)
if payload is not None:
charset = part.get_content_charset('us-ascii')
regards, robert
** Affects: mailman
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1096066
Title:
mailman raises exception if passed message not contains text/plain
message part
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1096066/+subscriptions
Public bug reported:
During testing I encountered, that bin/mailman is not working correctly
if you supply a relative path as -C argument. For the main process the
path is converted into a absolute path during startup but the bin/master
process is getting the relative filename but maybe a different working
directory.
The attached patch fixes that behavior by supplying the generated
absolute pathname to the new process.
** Affects: mailman
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1023681
Title:
bin/mailman -C config start does not work with a relativ config path
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1023681/+subscriptions
Public bug reported:
When admin_immed_notify is Yes and subscribe_policy is approve, the
Subject: of the notice to the admin is in the user's preferred language
rather than the list's preferred language and it may not be properly RFC
2047 encoded.
** Affects: mailman
Importance: Undecided
Status: New
** Affects: mailman/2.1
Importance: Medium
Assignee: Mark Sapiro (msapiro)
Status: In Progress
** Affects: mailman/3.0
Importance: Undecided
Status: New
** Tags: mailman3
** Also affects: mailman/2.1
Importance: Undecided
Status: New
** Also affects: mailman/3.0
Importance: Undecided
Status: New
** Tags added: mailman3
** Changed in: mailman/2.1
Importance: Undecided => Medium
** Changed in: mailman/2.1
Status: New => In Progress
** Changed in: mailman/2.1
Milestone: None => 2.1.15
** Changed in: mailman/2.1
Assignee: (unassigned) => Mark Sapiro (msapiro)
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/998949
Title:
Admin notice of held subscription is not fully in list's preferred
language.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/998949/+subscriptions
Public bug reported:
The draft for archival hashes for mailman specifies 32 character, base
32 encoding. We can get away with 13 characters which expects the first
collision at around 50 billion messages. The the wikipedia charts in
their "birthday attack" article. It's not like an occasional collision
is a big deal and this is not a security issue.
** Affects: mailman
Importance: Undecided
Status: New
** Tags: mailman3
** Tags added: mailman3
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/987031
Title:
archival hashes can be shortened
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/987031/+subscriptions
Public bug reported:
I've seen this error twice while running integration tests (of our own
application) that access Mailman 3 using the API. The load on Mailman is
very light, as all requests made to the API are serial, never in
parallel. Of course the various processing queues in MM3 are separate
processes and could be doing work concurrently.
The platform is Centos 6.
Traceback (most recent call last):
File "/usr/lib64/python2.6/wsgiref/handlers.py", line 93, in run
self.result = application(self.environ, self.start_response)
File "/home/sgoss/mailman_clone/src/mailman/rest/wsgiapp.py", line 63, in __call__
config.db.commit()
File "/home/sgoss/mailman_clone/src/mailman/database/stock.py", line 70, in commit
self.store.commit()
File "/home/sgoss/phoenix-deploy/lib/python2.6/site-packages/storm-0.18-py2.6-linux-x86_64.egg/storm/store.py", line 122, in commit
self._connection.commit()
File "/home/sgoss/phoenix-deploy/lib/python2.6/site-packages/storm-0.18-py2.6-linux-x86_64.egg/storm/databases/sqlite.py", line 126, in commit
self.raw_execute("COMMIT", _end=True)
File "/home/sgoss/phoenix-deploy/lib/python2.6/site-packages/storm-0.18-py2.6-linux-x86_64.egg/storm/databases/sqlite.py", line 154, in raw_execute
return Connection.raw_execute(self, statement, params)
File "/home/sgoss/phoenix-deploy/lib/python2.6/site-packages/storm-0.18-py2.6-linux-x86_64.egg/storm/database.py", line 321, in raw_execute
self._check_disconnect(raw_cursor.execute, *args)
File "/home/sgoss/phoenix-deploy/lib/python2.6/site-packages/storm-0.18-py2.6-linux-x86_64.egg/storm/database.py", line 366, in _check_disconnect
return function(*args, **kwargs)
OperationalError: database is locked
The backend here is SQLite, which falls over very quickly under
concurrent load. If the goal here is to create a stable mailing list
server, maybe SQLite is a poor default.
** Affects: mailman
Importance: Undecided
Status: New
** Tags: mailman3
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/856004
Title:
"OperationalError: database is locked" encountered under very light
load while using REST API
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/856004/+subscriptions
Public bug reported:
Not sure what caused this error that showed up in mailman.log:
Aug 16 10:54:50 2011 (31400) Uncaught runner exception: u'foo.example.com'
Aug 16 10:54:50 2011 (31400) Traceback (most recent call last):
File "/home/sgoss/mailman_clone/src/mailman/core/runner.py", line 138, in _one_iteration
self._process_one_file(msg, msgdata)
File "/home/sgoss/mailman_clone/src/mailman/core/runner.py", line 220, in _process_one_file
keepqueued = self._dispose(mlist, msg, msgdata)
File "/home/sgoss/mailman_clone/src/mailman/runners/virgin.py", line 37, in _dispose
process(mlist, msg, msgdata, 'virgin')
File "/home/sgoss/mailman_clone/src/mailman/core/pipelines.py", line 50, in process
handler.process(mlist, msg, msgdata)
File "/home/sgoss/mailman_clone/src/mailman/pipeline/cook_headers.py", line 360, in process
process(mlist, msg, msgdata)
File "/home/sgoss/mailman_clone/src/mailman/pipeline/cook_headers.py", line 202, in process
listinfo = mlist.script_url('listinfo')
File "/home/sgoss/mailman_clone/src/mailman/model/mailinglist.py", line 243, in script_url
return urljoin(self.domain.base_url, target + '/' + self.fqdn_listname)
File "/home/sgoss/mailman_clone/src/mailman/model/mailinglist.py", line 227, in domain
return getUtility(IDomainManager)[self.mail_host]
File "/home/sgoss/mailman_clone/src/mailman/model/domain.py", line 142, in __getitem__
raise KeyError(email_host)
KeyError: u'foo.example.com'
** Affects: mailman
Importance: Undecided
Status: New
** Tags: mailman3
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/827547
Title:
KeyError in "virgin" runner.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/827547/+subscriptions
Public bug reported:
This is an feature proposal/enhancement request.
I am running standardisation groups, and often schedule conference
calls, Web meetings, etc. To invite the working group members, I add a
mailman list as an invitee to the calendar appointment on my calendar.
That way, everybody on the list gets and invitation, and also update
emails are delivered when I drag the appointment around on my calendar.
Everyone stays in sync. Nice. I don't care who of the list members
actually accepts the appointment, because the dates are fixed by other
means beforehand (e.g. doodle.com).
But of course I never see any accept/decline responses. This causes my
calendaring app to consider the appointments as "unconfirmed" since none
of the invitees has confirmed their participation. I hence have to
manually edit such appointments in order to make them show up as
"confirmed, busy".
To alleviate this. it would be awesome if mailman could optionally be
configured to automatically respond to the sender of an email containing
a calendar appointment, and accept the invitation. Maybe this could fit
in the content filtering section?
That way, mailman operated lists would confirm their attendance on
behalf of their members, and the calendar appointment on the organiser's
calendar would have the proper status.
** Affects: mailman
Importance: Undecided
Status: New
** Tags: feature-request
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1191911
Title:
[feature-request] calendar appointments support
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1191911/+subscriptions
Public bug reported:
Many large mailing lists use bracketed prefixes in subjects as a way to
filter messages into smaller buckets, allowing some subscribers to read
all mail sent to the list while allowing others to filter messages (in
their mail client) to read only the messages they are interested in.
For example, the W3C's www-style mailing list uses these tags to filter
messages based on which CSS spec they refer to. Thus, a subject line
that begins "[css3-fonts]" will be assumed to be about only the
css3-fonts spec, with a target audience of only those interested in that
particular spec and not, say, the css3-flexbox spec (whose subject lines
would be prefixed with "[css3-flexbox]").
To handle this, the Mailman archive interface would provide an option to
filter only on particular prefixes (as well as messages that don't have
any prefixes), allowing a user of the archive to use it as they
otherwise would, but filtering the output such that they only see the
messages they want to see, instead of the whole archive.
In addition, it would be helpful to allow mailing lists to automatically
prefix subject lines when the message is sent to an e-mail address using
a plus alias.
For example, sending mail to www-style+css3-fonts(a)w3.org would prefix
the subject line of the message with "[css3-fonts]" in the message sent
to subscribers and in the archive, whereas sending mail to www-
style+css3-flexbox(a)w3.org would prefix the message with
"[css3-flexbox]".
It should also be allowed to have multiple prefixes on a message, and
having such messages be treated as if they had any prefix individually.
In terms of plus aliasing, there are two ways to handle it: (1) allow
aliases to specify multiple prefixes in a plus alias using some
separator (e.g. a comma: www-style+css3-fonts,css3-flexbox(a)w3.org); or
(2) detecting and intercepting when a single message was sent to
multiple e-mail addresses with different plus aliases for a single
mailing list (e.g. sending the same e-mail to both www-
style+css3-fonts(a)w3.org and www-style+css3-flexbox(a)w3.org), treating it
as a single message with multiple subject prefixes when sent to
subscribers or stored in the archive.
Now, I understand that this is likely a huge undertaking, but I think it
would go a long way to helping users with large and diverse mailing
lists.
** Affects: mailman
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1082495
Title:
Support bracketed prefixes in subject as filters
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1082495/+subscriptions