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.