Running customized version of Mailman 3
Since 2005, our organization has been running a customized version of Mailman 2 with extensions that meet our particular needs. The main novelty is support for /fixed subscription lists/, in which the list members are predetermined (corresponding to a "committee"). Fixed list subscribers are not offered the opportunity to unsubscribe, nor can others add themselves to the list. A further enhancement is /hybrid lists/ which, for example, have both a fixed and opt-in part. (This is implemented as a fixed list residing within an opt-in one in a way which is transparent to users). Our customizations consist of code adjustments (patches) to 23 files.
We are considering moving to Mailman 3 and would like to do this in a way which makes it possible to periodically upgrade our installation to the newest Mailman version, without clobbering our customizations. Thus, I do not think that installing via "pip" is the right approach for us. While I'm relatively new to git and GitLab, they seem to be ideally suited to this situation. If I understand the developer documentation correctly, I start out by creating a "fork" and can later "fetch" changes from the master branch and "rebase" to bring them into our branch.
I would welcome comments on what we are doing. I also wonder whether others might be interested in support for "fixed lists", if they are done in a way which can be "contributed" back into Mailman.
I extend our "thank you" to the developers of Mailman who have provided the robust system which has served us well for 15 years and provides the possibility to extend this into the future.
-Alan
--
Alan Kelm Manager, Electronic Services Canadian Mathematical Society Tel: +1 (613) 733-2662 ext. 799
Please consider the environment.
[cms web link] <https://cms.math.ca/>
Alan Kelm Chef, services électroniques Société mathématique du Canada Tél : +1 (613) 733-2662 poste 799
Considérez svp l'environnement.
Alan Kelm writes:
Since 2005, our organization has been running a customized version of Mailman 2 with extensions that meet our particular needs. The main novelty is support for /fixed subscription lists/, in which the list members are predetermined (corresponding to a "committee").
It's not clear to me that this can't be achieved with existing Mailman 2 (or 3) features. That is, a committee's list could be populated using mass subscribe, and unsubscriptions can be prevented by requiring admin intervention.
I'm not sure why this (or the "hybrid" list) requires patches. If I am correct that the basic functionality is present, and requires only small tweaks, it might be possible to include those tweaks in Mailman 3 itself. (I can't promise; this requirement also seems quite rare, and if substantial code changes, or multiple configuration options, were required, we might prefer to avoid them.) It's certainly good you posted here, and might be a good idea to post to the Mailman 2 users' list, to get others' opinions on your changes.
We are considering moving to Mailman 3 and would like to do this in a way which makes it possible to periodically upgrade our installation to the newest Mailman version, without clobbering our customizations. Thus, I do not think that installing via "pip" is the right approach for us. While I'm relatively new to git and GitLab, they seem to be ideally suited to this situation. If I understand the developer documentation correctly, I start out by creating a "fork" and can later "fetch" changes from the master branch and "rebase" to bring them into our branch.
Your understanding is correct in principle. If you don't have experienced git users around, you might want to find somebody to help you design a workflow. Eg, in general you want to rebase your changes on top of the mainline, rather than the other way around. You also need to be prepared for occasional cases where your patch conflicts with something we do in the same place of the same file.
Steve
On 2/29/20 9:02 AM, Stephen J. Turnbull wrote:
Alan Kelm writes:
Since 2005, our organization has been running a customized version of Mailman 2 with extensions that meet our particular needs. The main novelty is support for /fixed subscription lists/, in which the list members are predetermined (corresponding to a "committee").
It's not clear to me that this can't be achieved with existing Mailman 2 (or 3) features. That is, a committee's list could be populated using mass subscribe, and unsubscriptions can be prevented by requiring admin intervention.
You are correct in pointing out that fixed lists could be implemented without customizations to Mailman, provided that one is willing to leave intact various references to users subscribing and unsubscribing themselves. Modifications were required in 6 separate places (for Mailman 2) to suppress such references for fixed lists. We had additional extensions to permit programmatic re-syncing of subscriber and permitted sender lists with data sources, an adjustment to suppress monthly subscription reminders for such lists, and lots of other minor tweaks that were not strictly necessary.
I'm not sure why this (or the "hybrid" list) requires patches. If I am correct that the basic functionality is present, and requires only small tweaks, it might be possible to include those tweaks in Mailman 3 itself. (I can't promise; this requirement also seems quite rare, and if substantial code changes, or multiple configuration options, were required, we might prefer to avoid them.)
Our hybrid lists were implemented using separate lists - an outer /opt-in/ list having a /fixed/ list as one of its subscribers (using a generic parent/child list framework). Quite a few customizations were needed to smooth over the rough points of this arrangement (for example to ensure that only the parent list's subject line prefix appears on message subject lines). Now that I reflect upon it, it would be likely be possible to maintain a mandated list of subscribers as a subset within an opt-in list (provided that one keeps a separate copy of the mandated subscribers, to enable detection of previously mandated addresses that need to be deleted).
If I were to implement hybrid lists under Mailman 3, I would be inclined to look for simpler mechanisms that what we used under Mailman 2.
We are considering moving to Mailman 3 and would like to do this in a way which makes it possible to periodically upgrade our installation to the newest Mailman version, without clobbering our customizations. Thus, I do not think that installing via "pip" is the right approach for us. While I'm relatively new to git and GitLab, they seem to be ideally suited to this situation. If I understand the developer documentation correctly, I start out by creating a "fork" and can later "fetch" changes from the master branch and "rebase" to bring them into our branch.
Your understanding is correct in principle. If you don't have experienced git users around, you might want to find somebody to help you design a workflow. Eg, in general you want to rebase your changes on top of the mainline, rather than the other way around. You also need to be prepared for occasional cases where your patch conflicts with something we do in the same place of the same file.
Thank you for these helpful comments. When the time comes, we'll make sure to get the git configuration worked out properly.
My investigations over the past few days have convinced me that we are better off sticking with Mailman 2 for a while longer. One feature which is essential for us is to have the list manager informed of bounces, so that failing addresses can be corrected and important missed messages can be resent by other means. The lack of bounce handling in Mailman 3.2 is therefore a showstopper for us. (One of our customizations for Mailman 2 ensures that bounce notifications are sent to the list manager, but this was just a small tweak to existing bounce handling code).
I look forward to returning to take another look at Mailman 3 in the future. Thank you, once again, for your helpful comments.
-Alan
-- Alan Kelm Manager, Electronic Services Canadian Mathematical Society
On 28-Feb-20 16:46, Alan Kelm wrote:
Since 2005, our organization has been running a customized version of Mailman 2 with extensions that meet our particular needs. The main novelty is support for /fixed subscription lists/, in which the list members are predetermined (corresponding to a "committee"). Fixed list subscribers are not offered the opportunity to unsubscribe, nor can others add themselves to the list. A further enhancement is /hybrid lists/ which, for example, have both a fixed and opt-in part. (This is implemented as a fixed list residing within an opt-in one in a way which is transparent to users). Our customizations consist of code adjustments (patches) to 23 files.
We are considering moving to Mailman 3 and would like to do this in a way which makes it possible to periodically upgrade our installation to the newest Mailman version, without clobbering our customizations. Thus, I do not think that installing via "pip" is the right approach for us. While I'm relatively new to git and GitLab, they seem to be ideally suited to this situation. If I understand the developer documentation correctly, I start out by creating a "fork" and can later "fetch" changes from the master branch and "rebase" to bring them into our branch.
I would welcome comments on what we are doing. I also wonder whether others might be interested in support for "fixed lists", if they are done in a way which can be "contributed" back into Mailman.
I extend our "thank you" to the developers of Mailman who have provided the robust system which has served us well for 15 years and provides the possibility to extend this into the future.
-Alan
FWIW: When I had similar requirements (MM2), I found it most convenient to
populate the "fixed" list with a distribution list name. The distribution list
was sourced from an LDAP group. That allowed the distribution to be populated
based on job title, reporting relationship, committee membership - whatever.
On the Mailman side, it's only one member (the distribution list) that had
special treatment. Opt-in would be moderator approval, as was unsubscribe.
But the moderator only had to remember the one "can't unsubscribe" name.
That, or a variant might work for you - and probably can be done modifying fewer
files... In minimal form, if you don't want to rely on a human, it seems like the
minimal implementation is a "can't unsubscribe" bit for users and an admin interface
to set it. You could also cause that user to have a different "language" - e.g. en-ZZ; then
adjust the templates for that "language" to remove references to "unsubscribe". That's
not functionally necessary - but prettier.
On 2/29/20 10:35 AM, tlhackque via Mailman-users wrote:
On 28-Feb-20 16:46, Alan Kelm wrote:
Since 2005, our organization has been running a customized version of Mailman 2 with extensions that meet our particular needs. The main novelty is support for /fixed subscription lists/, in which the list members are predetermined (corresponding to a "committee"). Fixed list subscribers are not offered the opportunity to unsubscribe, nor can others add themselves to the list. A further enhancement is /hybrid lists/ which, for example, have both a fixed and opt-in part. (This is implemented as a fixed list residing within an opt-in one in a way which is transparent to users). Our customizations consist of code adjustments (patches) to 23 files. FWIW: When I had similar requirements (MM2), I found it most convenient to populate the "fixed" list with a distribution list name. The distribution list was sourced from an LDAP group. That allowed the distribution to be populated based on job title, reporting relationship, committee membership - whatever.
On the Mailman side, it's only one member (the distribution list) that had special treatment. Opt-in would be moderator approval, as was unsubscribe.
But the moderator only had to remember the one "can't unsubscribe" name.
That, or a variant might work for you - and probably can be done modifying fewer files... In minimal form, if you don't want to rely on a human, it seems like the minimal implementation is a "can't unsubscribe" bit for users and an admin interface to set it. You could also cause that user to have a different "language" - e.g. en-ZZ; then adjust the templates for that "language" to remove references to "unsubscribe". That's not functionally necessary - but prettier.
Thank you for explaining the approach which you took for making a hybrid list with both opt-in and "fixed" components. Including the address of the fixed distribution list as a single subscriber within the opt-in list sounds completely analogous to what we did. Our mechanism for identifying a fixed list was essentially a "can't unsubscribe" bit as you describe. Rather than using a separate language template without unsubscribe links for fixed lists, we did some coding to suppress that portion of the template for fixed lists.
It certainly is nice that Mailman comes with source code and plenty of configuration options, so that special needs like this can be accommodated.
--
On 03-Mar-20 15:08, Alan Kelm wrote:
On 2/29/20 10:35 AM, tlhackque via Mailman-users wrote:
On 28-Feb-20 16:46, Alan Kelm wrote:
Since 2005, our organization has been running a customized version of Mailman 2 with extensions that meet our particular needs. The main novelty is support for /fixed subscription lists/, in which the list members are predetermined (corresponding to a "committee"). Fixed list subscribers are not offered the opportunity to unsubscribe, nor can others add themselves to the list. A further enhancement is /hybrid lists/ which, for example, have both a fixed and opt-in part. (This is implemented as a fixed list residing within an opt-in one in a way which is transparent to users). Our customizations consist of code adjustments (patches) to 23 files. FWIW: When I had similar requirements (MM2), I found it most convenient to populate the "fixed" list with a distribution list name. The distribution list was sourced from an LDAP group. That allowed the distribution to be populated based on job title, reporting relationship, committee membership - whatever.
On the Mailman side, it's only one member (the distribution list) that had special treatment. Opt-in would be moderator approval, as was unsubscribe.
But the moderator only had to remember the one "can't unsubscribe" name.
That, or a variant might work for you - and probably can be done modifying fewer files... In minimal form, if you don't want to rely on a human, it seems like the minimal implementation is a "can't unsubscribe" bit for users and an admin interface to set it. You could also cause that user to have a different "language" - e.g. en-ZZ; then adjust the templates for that "language" to remove references to "unsubscribe". That's not functionally necessary - but prettier.
Thank you for explaining the approach which you took for making a hybrid list with both opt-in and "fixed" components. Including the address of the fixed distribution list as a single subscriber within the opt-in list sounds completely analogous to what we did. Our mechanism for identifying a fixed list was essentially a "can't unsubscribe" bit as you describe. Rather than using a separate language template without unsubscribe links for fixed lists, we did some coding to suppress that portion of the template for fixed lists.
It certainly is nice that Mailman comes with source code and plenty of configuration options, so that special needs like this can be accommodated.
I meant to also mention that basing the 'fixed' subscriber on LDAP also imported the LDAP permissions mechanisms. So control of who's in and who's out can be limited, delegated, etc. And automated. (e.g. all 2nd level reports of the chief widget-counter.) Assuming you have an LDAP directory :-) In any case, these groups tend to be maintained for other purposes (e.g. file permissions, purchasing authority, application access controls, etc). So keeping the "fixed" list maintenance external to Mailman can provide efficiencies - even reduce errors.
The advantage of a language template is that fewer code changes are required, so upgrades are easier. Of course, you do have to maintain the modified templates - there's a break-even point if you support a lot of languages. But since you're simply deleting subscription-related text, it's a lot less error-prone than patching code.
But the best solution in any given case will depend on local factors, and open source provides options.
Your mileage will vary.
participants (3)
-
Alan Kelm
-
Stephen J. Turnbull
-
tlhackque