Currently Postorius handles form submissions like this:
1. Check to see if inputs are malformed, raise error if so
2. Submit to mailman-core and see what the response is.
- ConnectionError: Mailman-core is unreachable, display error message
- Success: Display some success notification
- HttpError: This happens when mailman-core rejects the request for
Currently the HttpErrors are passed without modification to the user in
a notification. Postorius should have some way of translating these.
We can't translate the raw messages because they sometimes contain
specific strings like emails and it would require us to manually add the
strings to the .pot files.
Theoretically the core could translate the messages before passing them
to postorius. This would require core to know about the language it
should translate to. I don't think this is a very good approach because
we would have to make sure we offer the same languages for core and
postorius and I'm not sure how we would pass the languages to core...
I propose core to return an error code with each request. That way
postorius can add strings for all the errors that it cares about and
translate them accordingly. This would require an api change. Since 3.1
would change the api anyway, it would be nice to include the changes there.
What do you think of my proposal? Do you have a better idea?
The specifics have to be worked out of course.
By the way, Aditi is my student under the Systers org. Please take
good care of her! Thanks to Simon and Aditya for getting started
Aditya Divekar writes:
> It seems you ran into the error due to the incompatible falcon version.
> You should have falcon==0.3 installed for the setup to work for older
> Mailman versions.
> However, this error doesn't occur with the latest Mailman version 3.1.0
> So you should upgrade your Mailman version and the issue would be solved.
> You can pull the Mailman master branch from Gitlab and then re-run the setup.
I would recommend that you have two full suites locally, something
gsoc2016 -+--- gnu ---+- mailman
| +- mailmanclient
| +- bin, include, lib for venv
+- systers -+- mailman
+- bin, include, lib for venv
This will allow you to configure each suite appropriately. The
systers venv at least, and possibly the gnu venv, should *not* use
--system-site-packages, so that you can have private and fixed
versions of external packages like Falcon and Django. This will cost
some disk space, but measured in 10s of MB I suppose.
It seems you ran into the error due to the incompatible falcon version.
You should have falcon==0.3 installed for the setup to work for older
However, this error doesn't occur with the latest Mailman version 3.1.0
So you should upgrade your Mailman version and the issue would be solved.
You can pull the Mailman master branch from Gitlab and then re-run the setup.
I am trying to set up the environment on my system. On running python
manage.py runserver in postorius_standalone, I am getting the following
Traceback : https://www.irccloud.com/pastebin/WeKBXjGx/
On 05/12/2016 01:06 PM, ADITI GUPTA wrote:
> I am Aditi Gupta. I got selected for GSoC'16 Systers Mailman Project.
> I cloned systers repositories of mailman3, mailmanclient, postorius and
> hyperkitty from github.
Their versions are OLD! It doesn't look like they contain any changes.
You should consider creating forks on gitlab so you can keep up to date
and submit merge requests once in a while.
> Also, I cloned the postorius_standalone and
> hyperkitty_standalone from gitlab for testing purposes.
postorius_standalone and hyperkitty_standalone are synced with their
respective repositories on gitlab. They don't care about versions and
releases (for now, maybe for ever). You shouldn't use them with anything
other than the master branches of the gitlab repos.
> On running setup.py
> in postorius_standalone , I am getting deprecation warning because
> postorius of systers is using older version of Django.
There is nothing to install in postorius_standalone. It doesn't even
contain a setup.py
Also if they are using an older version of django there is nothing we
can do about it. We are currently supporting what django supports. That
is versions 1.8 and 1.9. All other versions are considered insecure!
I don't think anyone will support you with any forks of the main
repository. You should follow the official wiki and adhere to it, if you
want people here to help you.
The setup instructions is probably what you are looking for
> Also,I am getting "ImportError: No module named middleware".
Use the latest versions, and if you still run into issues, I'll help you
work them out. (You might want to try the irc first to see if someone is
> This is the traceback : http://pastebin.com/D1c4XCHe
Screenshots are pretty useless FYI. :-)
I am Aditi Gupta. I got selected for GSoC'16 Systers Mailman Project.
I cloned systers repositories of mailman3, mailmanclient, postorius and
hyperkitty from github. Also, I cloned the postorius_standalone and
hyperkitty_standalone from gitlab for testing purposes. On running setup.py
in postorius_standalone , I am getting deprecation warning because
postorius of systers is using older version of Django.
Also,I am getting "ImportError: No module named middleware".
This is the traceback : http://pastebin.com/D1c4XCHe
I have been a little bit inactive these days as I am stuck in my end
semester exams. However, I have been able to take out some time and
update my blog with a few posts explaining my proposal and my
experiences of GSOC. I invite all of you to have a look at my blog
Comments/suggestions are most welcomed.
On 05/07/2016 09:41 PM, Anirudh Dahiya wrote:
> I updated my builds and am facing the following error :
> InvalidTemplateLibrary: Invalid template library specified. ImportError
> raised when trying to load 'postorius.templatetags.membership_helpers':
> cannot import name MailingList
> I tried building on my other machine and faced the same error.
> Complete traceback : http://dpaste.com/3WG8XQ5
> (irc spark)
I guess it's caused by an out of date mailmanclient installation inside
one of your virtualenvs. Can you try clearing them out?
The issue is caused by the following import:
from mailmanclient._client import MailingList
This import should not be there. We should not import via "private"
things. Currently the MailingList is imported for additional
functionality, but it's not actually being used inside Postorius. I
guess a safer option would be to use postorius.models.List instead. We
should be using these classes inside Postorius anyway.
I updated my builds and am facing the following error :
InvalidTemplateLibrary: Invalid template library specified. ImportError
raised when trying to load 'postorius.templatetags.membership_helpers':
cannot import name MailingList
I tried building on my other machine and faced the same error.
Complete traceback : http://dpaste.com/3WG8XQ5
I am working on implementing message queue based archiving system as part
of my GSoC project. Just yesterday, me and Florian(my mentor) were
discussing possible architectural choices, and decided to approach the
mailman-developer community for opinions.
Right now, the archiving happens something like this -
We were discussing the architectural design for the proposed system to be
plugged. We considered two choices -
I. The first one we looked at involved an additional interface between the
backends and IArchiver. The job of this interface would be to decide to
which backend to approach for a particular archive, and subsequently send
the mail to that backend.
The advantage I saw here was that archives/webapps that would be developed
in future would then be able to attach to the our system, and not disturb
II. To this, Florian suggested, and I realized later after some thought,
that choosing backend + the archive right at the IArchiver stage seems more
sensible. This information can be stored in mailman.cfg, following the
current way it works for archiving. It seems more simple and follows the
way archiving is done up untill now.
I later realised that since we'll have to add info about which archive
subscribes to which mailing lists(actually stored the other way round), in
our first design, we would eventually have to add information at the "Our
interface" level. Thus better to do all this at one place, i.e. the
IArchiver interface level, which the second design proposes.
One thing I learnt from reading backends' documentation is that they
encourage several clients(archives in our case) plugged into the same
message queue system, rather than defining a queue system for each archive.
This saves space, and processor time(for the backend server running in the
These are our thoughts, I'd love to hear opinions and suggestions to design