A little while ago (November 2012 probably) I changed a mailing list from
Hypermail to Mailman and wanted to keep some of the look-and-feel of the
archives, e.g. background colour and fonts.
So I patched mailman 2.1.9 in CentOS 5 to include a CSS stylesheet link in
each generated HTML page, replacing e.g.
<BODY BGCOLOR="#ffffff"> with just <body>
and adding e.g.
body {background-color: #ffffff ; color: black; }
in /pipermail/mailman.css, so that HTML style such as FONT and SIZE is
removed from the Python code.
(I only have one list on that server and didn't implement per-list style)
I also changed a few things e.g. content-type to get zero warnings and
errors from the W3C online validator.
Now if I want to get DMARC functionality I'll have to jump past the
RedHat/CentOS release and build 2.1.18, and re-patch for CSS.
I was wondering if there was any interest in incorporating CSS into the
official releases.
--
Andrew Daviel, TRIUMF, Canada
Tel. +1 (604) 222-7376 (Pacific Time)
On Nov 26, 2014, at 02:30 PM, Abhilash Raj wrote:
>I am working on porting mailman3 to python3. There are few doubts I have
>which may sound stupid, but I have a little knowledge about encoding and
>charsets which I think is important for the port. Also this is my first time
>working on python3 so forgive me for asking anything obvious( I did try
>googling first) The code is in very preliminary stages with tons of
>errors. Its up on launchpad.
>
> lp:~raj-abhilash1/mailman/py3
Yay! Note that I also have been playing around with it a bit. I wouldn't say
it's a functional branch, but you might compare notes:
lp:~barry/mailman/py3
>1. `pkg_resources.resource_string` used to read the configuration files while
>initialization and testing now returns bytes instead of string(like in
>python2).
Right. "resource_string" is really a misnomer. In another Python 3 project I
work on, I use:
from pkg_resource import resource_string as resource_bytes
just so that the call sites are accurate.
>So instead I use `pkg_resources.resource_stream` and deocode to the steam to
>a `utf-8` encoding(why? to avoid errors for the time being). I wanted to ask
>what would be the best for this case?
You can of course also decode the bytestring that "resource_bytes" returns.
That's generally what I do in that other project.
>2. To create a hash everywhere unicode strings must be encoded. So again the
>same question what should I encode it to? UTF-8 or US-ASCII? Or someway to
>determine which encoding should be used?
I think utf-8 is generally the right encoding to use, except in contexts where
you are given a better hint. E.g. if you're decoding say the payload of a
message with a Content-Type header, and that header has a `charset` attribute,
it will name the encoding that you're supposed to use.
There may be cases where us-ascii or latin-1 would be better, but I think
those should be determined on a case-by-case basis.
>Also if anybody has suggestions on porting please let me know. I am online
>sporadically on irc as `maxking` on #mailman (I see all of the messages sent
>while I am away).
The trunk should now be `python2.7 -3` clean, so it's ready to be ported.
I'd probably not try to run the full test suite yet, but start at the lowest
level, e.g. database/model and work your way up. If there are changes that
make sense even in Python 2 (i.e. for bilingual support for now) try to
put those in separate branches and merge proposals, so they can be merged into
trunk even before a full port.
This page will be indispensable:
https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef
Cheers,
-Barry
Aurelien Bompard writes:
> I suggest we leave the member's moderation_action on None when it's
> created, and modify the moderation rules to go look for the list's default
> setting if the member's value is None.
I think this is a bad idea. From the subscriber's perspective, it
changes the list's behavior with no action from her, for no good
reason that she knows.
The semantics of these variables is, and I think should be,
initialization, not fallback.
On Nov 25, 2014, at 11:46 AM, Aurelien Bompard wrote:
>As a result, unless I'm missing something changing, the list's
>default_moderation_action has no effect on existing members. Do I
>understand correctly?
That is correct. As Steve points out, the intent is that this setting is
initialization not fallback.
I think this does work differently in MM2.1, but that version's schema isn't
really sophisticated enough to do anything different. There, members have a
moderation flag which gets initialized from default_member_moderation. Then,
if the member's flag is set, member_moderation_action (a list setting) is
taken. So I guess in the case of moderated members, there is a fallback
action, and while there is no member-specific action, there is a
member-specific state.
MM3 collapses that so that rather than having a flag with a fallback action,
each member just has an action. This allows you more flexibility in
controlling an individual member's posting privileges, at the cost of having
to change all members individually if a list's default changes. Can you
elaborate on the use case for having a fallback action?
Note that in MM3, nonmembers are technically members too, but with a
'nonmember' role, so the same moderation action flag controls their posting
privileges too. This replaces MM2.1's generic_nonmember_action and the crufty
lists of {accept,hold,reject,discard}_these_nonmembers.
Cheers,
-Barry
Hi All,
I am working on porting mailman3 to python3. There are few doubts I have
which may sound stupid, but I have a little knowledge about encoding and
charsets which I think is important for the port. Also this is my first
time working
on python3 so forgive me for asking anything obvious( I did try googling
first) The code is in very preliminary stages with tons of errors. Its up
on launchpad.
lp:~raj-abhilash1/mailman/py3
So my doubts:
1. `pkg_resources.resource_string` used to read the configuration files
while
initialization and testing now returns bytes instead of string(like in
python2).
So instead I use `pkg_resources.resource_stream` and deocode to the steam
to a `utf-8` encoding(why? to avoid errors for the time being). I wanted to
ask
what would be the best for this case?
2. To create a hash everywhere unicode strings must be encoded. So again the
same question what should I encode it to? UTF-8 or US-ASCII? Or someway to
determine which encoding should be used?
Also if anybody has suggestions on porting please let me know. I am online
sporadically on irc as `maxking` on #mailman (I see all of the messages sent
while I am away).
thanks,
Abhilash Raj
On 11/25/14, 5:46 AM, Aurelien Bompard wrote:
> Hi *,
>
> I'd like to discuss the algorithm we use to enforce a list's default
> moderation action. Here's what I understand:
> - the list's default_moderation_action setting is stored in the database
> and can be changed via the REST interface
> - when a new member is created, its moderation_action is imported from the
> list's default_moderation_action depending on its role (see
> model/member.py:84)
> - this member's moderation_action is stored in the database
> - it's the member's moderation_action that is used in the moderation rule
> (rules/moderation.py:52)
>
> As a result, unless I'm missing something changing, the list's
> default_moderation_action has no effect on existing members. Do I
> understand correctly?
>
> I suggest we leave the member's moderation_action on None when it's
> created, and modify the moderation rules to go look for the list's default
> setting if the member's value is None.
> How about that ? Other suggestions?
>
> Aurélien
>
The only way I could see that would be to make the flag 3 valued:
They are moderated
They are not moderated
They are in the default state of moderation, see the lists default value.
--
Richard Damon
Hi *,
I'd like to discuss the algorithm we use to enforce a list's default
moderation action. Here's what I understand:
- the list's default_moderation_action setting is stored in the database
and can be changed via the REST interface
- when a new member is created, its moderation_action is imported from the
list's default_moderation_action depending on its role (see
model/member.py:84)
- this member's moderation_action is stored in the database
- it's the member's moderation_action that is used in the moderation rule
(rules/moderation.py:52)
As a result, unless I'm missing something changing, the list's
default_moderation_action has no effect on existing members. Do I
understand correctly?
I suggest we leave the member's moderation_action on None when it's
created, and modify the moderation rules to go look for the list's default
setting if the member's value is None.
How about that ? Other suggestions?
Aurélien
I'm happy to say that with Kurt Griffiths' release of Falcon 2.0b1 to PyPI, I
have merged the MM3 falcon branch to trunk. This means the Mailman internal
dependency transitions are complete. Along with the SQLAlchemy transition,
our trunk should now only depend on Python 3 compatible libraries.
Porting MM3 to Python 3 is not on the critical path for the final release, but
at least work on that can now begin.
Happy hacking.
-Barry
Some weeks back, Florian went through the Postorius bug queue to find a
list of bugs that he thinks are blocking us from being able to have a
final Mailman Suite release.
I just wanted to advertise that list to you all in case anyone here is
looking for some valuable work to do:
https://bugs.launchpad.net/postorius/+bugs?field.tag=mailman3-suite-blocker
There's only 13 of them at the moment, so that's nice.
They're in a variety of different states. Some are somewhat old and we
could really use someone to just try to reproduce them on the most
recent version of postorius and post an update in the bug saying it's
still a problem (or not!). Some have notes from me suggesting a
smaller piece that could be done first by a beginner wanting a new bug
to try or someone more experienced wanting a quicker task. (don't worry
about saving beginner bugs at this stage; I'm more interested in seeing
a release!) Some are more complex.
If anyone's got time to push these forwards in any way, it would be very
much appreciated! I'm even happy to send you some mailman stickers if
you want a physical token of appreciation.
Terri
Hi,
I have installed mailman-bundler-3.0b2. On the Postorius login page, by
default there is the Google, persona and Yahoo authentication. I only
want basic native application authentication, which I can't see in this
page.
Tweaking the AUTHENTICATION_BACKENDS variable in development.py, I could
disable the Google and Yahoo authentication and
'django.contrib.auth.backends.ModelBackend' seemingly corresponds to the
persona authentication.
AUTHENTICATION_BACKENDS = (
#'social_auth.backends.google.GoogleBackend',
#'social_auth.backends.yahoo.YahooBackend',
#'social_auth.backends.OpenIDBackend',
'django.contrib.auth.backends.ModelBackend',
)
So the question does Postorius/Hyperkitty support basic authentication
at all? How can I enable it?
Cheers