How to change or create list styles
Hello,
how can I change list style defaults or create new list styles?
I think the mailman shell way isn't persistent, and I would prefer some kind of config file. I have not found any helpful yet.
Thx.
Adam Minski writes:
I think the mailman shell way isn't persistent,
I don't understand what you mean by "persistent" here. I take that to mean that once you change the list attributes, they stay changed until you change them again. But that doesn't seem to make sense.
and I would prefer some kind of config file. I have not found any helpful yet.
There isn't a config file yet, except the Python modules in src/mailman/styles. You have to hack the Python or write SQL.
We're currently working on this but we don't have working code yet, let alone anything we can release. The code we're starting from is designed to allow you to start from a base style, tweak the configuration, and either save the new configuration as a complete style, or save the difference as a mix-in style. There will also be some kind of export/import facility, which you could treat as a config file, I guess.
Steve
- Stephen J. Turnbull (stephenjturnbull@gmail.com) [211019 16:36]:
Adam Minski writes:
I think the mailman shell way isn't persistent,
I don't understand what you mean by "persistent" here. I take that to mean that once you change the list attributes, they stay changed until you change them again. But that doesn't seem to make sense.
What I would like (and perhaps that's the same Adam would like) would be to have inherited list styles, so that precedence is (most to least)
a) the list config, b) templates in order of inheritance (e.g. via parent template), c) site default, d) programmatic defaults
Which would mean: if I change a template later on, all the lists adopt behavour.
However, that isn't the current way. However, currently, the template is copied into the list config at creation time, and then there is no relationship between the two anymore.
Great that you're working on that, this makes lots of sense for some use cases.
Andi
On 10/19/21 5:17 PM, Andreas Barth wrote:
- Stephen J. Turnbull (stephenjturnbull@gmail.com) [211019 16:36]:
Adam Minski writes:
I think the mailman shell way isn't persistent,
I don't understand what you mean by "persistent" here. I take that to mean that once you change the list attributes, they stay changed until you change them again. But that doesn't seem to make sense.
What I would like (and perhaps that's the same Adam would like) would be to have inherited list styles, so that precedence is (most to least)
a) the list config, b) templates in order of inheritance (e.g. via parent template), c) site default, d) programmatic defaults
Which would mean: if I change a template later on, all the lists adopt behavour.
No, having own defaults at list creation time would be pretty ok for me.
Adam
Andreas Barth writes:
Which would mean: if I change a template later on, all the lists adopt behavour.
I'm not sure how easy it is to implement that.
Also, I think Abhilash suggested it might cause more problems than it solves. Sure, if you get an improved version of a style (say, it manages to make anonymous lists more anonymous) you'd like that to apply to all anonymous lists. But there are some changes that probably shouldn't be made to all lists using a particular style, but you want them to constitute a new style. Then you either need to make a mixin style, and apply it to all the lists that need it, or you need to "freeze" the configuration of all the lists that shouldn't get it. Both approaches are fairly annoying, and a change that makes anonymous lists *less* anonymous could be outright hazardous to someone's health.
However, that isn't the current way. However, currently, the template is copied into the list config at creation time,
That is what "template" means, after all.
Steven,
many thanks for your answer. Probably my question was not carefully worded enough.
What I like to do is creating new or modifying existing styles to have reasonable defaults for creating new lists. If I create a new style using the mailman shell as stated by the documentation, the new style is gone as default after restarting mailman server. Maybe i must store the new style into the database, but for me it looks like defaults are coded into src/mailman/styles files.
If I understood you correctly the only way at the moment is hacking the source code, which I always try to avoid without getting changes upstream. Is this correct?
What did you mean with "or write SQL"? Are the style defaults stored at database level? This would bypass the upstream problem.
Thx. Adam
On 10/19/21 4:36 PM, Stephen J. Turnbull wrote:
Adam Minski writes:
I think the mailman shell way isn't persistent,
I don't understand what you mean by "persistent" here. I take that to mean that once you change the list attributes, they stay changed until you change them again. But that doesn't seem to make sense.
and I would prefer some kind of config file. I have not found any helpful yet.
There isn't a config file yet, except the Python modules in src/mailman/styles. You have to hack the Python or write SQL.
We're currently working on this but we don't have working code yet, let alone anything we can release. The code we're starting from is designed to allow you to start from a base style, tweak the configuration, and either save the new configuration as a complete style, or save the difference as a mix-in style. There will also be some kind of export/import facility, which you could treat as a config file, I guess.
Steve
Adam Minski writes:
What I like to do is creating new or modifying existing styles to have reasonable defaults for creating new lists. If I create a new style using the mailman shell as stated by the documentation, the new style is gone as default after restarting mailman server.
I didn't realize that was possible; I need to see how it's done. Anyway, the loss of the style is because the styles are implemented as Python functions. There is no place to store them in the database now.
If I understood you correctly the only way at the moment is hacking the source code, which I always try to avoid without getting changes upstream. Is this correct?
That is correct.
What did you mean with "or write SQL"? Are the style defaults stored at database level?
No, they are not, they're hard-coded in the style/*.py files. If they were, they would persist.
The SQL I'm referring to is a script that would manipulate the database directly for a given list. It wouldn't create a style in Mailman; it would be an "external" style.
Steve
participants (3)
-
Adam Minski -
Andreas Barth -
Stephen J. Turnbull