Public bug reported:
When Postorius GETs a collection of lists from the REST API, it will in
most situations only use a subset (the ones that are set to "advertise
in list index"). This is a minor issue as long as the request isn't
paginated, but can lead to incorrect item counts when it is.
Example:
GET /lists/test(a)example.com?page=1&count=10
will return all lists within the range [:10] from the database. If there
are x unadvertised lists in the result, the page will only show 10 - x
results.
I guess the most common way to solve this is for the REST API to accept
a number of common filter params which are used in the WHERE clause of
the database query. In this case:
GET /lists/test(a)example.com?page=1&count=10&advertised=(0|1|2)
0 - only non-advertised
1 - only advertised
2 - both
** Affects: mailman
Importance: Undecided
Status: New
** Tags: mailman3 rest
** Description changed:
When Postorius GETs a collection of lists from the REST API, it will in
most situations only use a subset (the ones that are set to "advertise
in list index"). This is a minor issue as long as the request isn't
paginated, but can lead to incorrect item counts when it is.
Example:
GET /lists/test(a)example.com?page=1&count=10
will return all lists within the range [:10] from the database. If there
are x unadvertised list in the result, the page will only show 10 - x
results.
I guess the most common way to solve this is for the REST API to accept
- a number of common filter params which are used for the WHERE clause of
+ a number of common filter params which are used in the WHERE clause of
the database query. In this case:
GET /lists/test(a)example.com?page=1&count=10&advertised=(0|1|2)
0 - only non-advertised
1 - only advertised
2 - both
** Description changed:
When Postorius GETs a collection of lists from the REST API, it will in
most situations only use a subset (the ones that are set to "advertise
in list index"). This is a minor issue as long as the request isn't
paginated, but can lead to incorrect item counts when it is.
Example:
GET /lists/test(a)example.com?page=1&count=10
will return all lists within the range [:10] from the database. If there
- are x unadvertised list in the result, the page will only show 10 - x
+ are x unadvertised lists in the result, the page will only show 10 - x
results.
I guess the most common way to solve this is for the REST API to accept
a number of common filter params which are used in the WHERE clause of
the database query. In this case:
GET /lists/test(a)example.com?page=1&count=10&advertised=(0|1|2)
0 - only non-advertised
1 - only advertised
2 - both
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1190582
Title:
Add some common filters to REST API resources that expose collections
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1190582/+subscriptions
Public bug reported:
The LMTP server currently does a sanity check on the To field of the
incoming message, to ensure that it is addressed to a valid mailing
list. This check ignores acceptable aliases, but it should honor them.
** 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/1170726
Title:
The LMTP server needs to check acceptable aliases
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1170726/+subscriptions
Public bug reported:
searching all the code (mailman-3.0.0b3) (with ack) for "tomoderators" returns this:
$ ack -ai tomoderators
src/mailman/bin/checkdbs.py
202: msg.send(mlist, **{'tomoderators': True})
src/mailman/chains/hold.py
241: nmsg.send(mlist, **dict(tomoderators=True))
src/mailman/app/moderator.py
228: msg.send(mlist, tomoderators=True)
299: msg.send(mlist, tomoderators=True)
I can't see where this option is actually used. In practice, the
moderation notification sent from hold.py in line 241 just goes to
everyone in the mailing list, not the moderators.
** 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/1170388
Title:
the tomoderators argument to "send" is ignored
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1170388/+subscriptions
Public bug reported:
There should be an interface for posting to a list from 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/1104505
Title:
Web posting interface
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1104505/+subscriptions
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