Postorius permissions granularity
Hi,
Is there a way to have more granular permissions in Postorius than either User or Superuser? The user permissions that are configurable under /admin/auth/user/ do not seem to have any effect.
We have a helpdesk team that would benefit from being able to access all list pages in the same way as a Superuser, but without the ability to accidentally delete the mail domain for example.
Thanks,
Liam
On Thu, Dec 11, 2025 at 11:43 AM Liam Reilly <l.reilly@ucl.ac.uk> wrote:
Hi,
Is there a way to have more granular permissions in Postorius than either User or Superuser? The user permissions that are configurable under /admin/auth/user/ do not seem to have any effect.
We have a helpdesk team that would benefit from being able to access all list pages in the same way as a Superuser, but without the ability to accidentally delete the mail domain for example.
Thanks,
Liam
You can create several superusers.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
The issue is we don't want first line support staff to have superuser permissions, just the ability to assist end user list owners by being able to administer all lists. So something that is lower level than full superuser would be ideal.
I'm considering a cron job that adds a web account as Owner to all lists but this feels like a bit of a bodge.
On Thu, Dec 11, 2025 at 12:07 PM Liam Reilly <l.reilly@ucl.ac.uk> wrote:
The issue is we don't want first line support staff to have superuser permissions, just the ability to assist end user list owners by being able to administer all lists. So something that is lower level than full superuser would be ideal.
I'm considering a cron job that adds a web account as Owner to all lists but this feels like a bit of a bodge.
I see. The permissions that can be granted in relation to Postorius are quite limited.
PS: Is it possible that you could retain content that comes in the form of responses to your posts, so the hierarchy is maintained? You seem to be deleting everything, which make your post look like a new one, except for the subject.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
Odhiambo Washington wrote:
The issue is we don't want first line support staff to have superuser permissions, just the ability to assist end user list owners by being able to administer all lists. So something that is lower level than full superuser would be ideal. I'm considering a cron job that adds a web account as Owner to all lists but this feels like a bit of a bodge. I see. The permissions that can be granted in relation to Postorius are quite limited. PS: Is it possible that you could retain content that comes in the form of responses to your posts, so the hierarchy is maintained? You seem to be deleting everything, which make your post look like a new one, except for
On Thu, Dec 11, 2025 at 12:07 PM Liam Reilly <l.reilly@ucl.ac.uk> wrote: the subject.
Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
Apologies, I have been using the "Reply" button in the UI and have not been quoting the post I'm replying to. Does it look better now?
On Thu, Dec 11, 2025 at 12:26 PM Liam Reilly <l.reilly@ucl.ac.uk> wrote:
On Thu, Dec 11, 2025 at 12:07 PM Liam Reilly <l.reilly@ucl.ac.uk> wrote:
The issue is we don't want first line support staff to have superuser permissions, just the ability to assist end user list owners by being able to administer all lists. So something that is lower level than full superuser would be ideal. I'm considering a cron job that adds a web account as Owner to all
Odhiambo Washington wrote: lists
but this feels like a bit of a bodge. I see. The permissions that can be granted in relation to Postorius are quite limited. PS: Is it possible that you could retain content that comes in the form of responses to your posts, so the hierarchy is maintained? You seem to be deleting everything, which make your post look like a new one, except for the subject.
Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
Apologies, I have been using the "Reply" button in the UI and have not been quoting the post I'm replying to. Does it look better now?
It's somehow better. It would be best if you were able to trim off the signature text :)
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
Liam Reilly writes:
Is there a way to have more granular permissions in Postorius than either User or Superuser?
Not without additional code. It couldn't be a plugin. It would have to be a fork of the main Postorius code at first (ie, you would be responsible for patching it and merging our public releases, there would not be regular releases). I doubt it would be merged in a near- future release, at least I wouldn't be confident enough to do that myself without beta testing on a branch.
I don't think it would be hard to implement a "restricted superuser" role. The annoying part would be figuring out where to apply it, as the "authenticated user", "moderator", and "superuser" roles are implemented via Python "decorators" applied to the functions implementing the various features. And the changes would likely need to be pervasive in page templates, forms, and functional code.
The user permissions that are configurable under /admin/auth/user/ do not seem to have any effect.
As far as I know the only bit that has big effects is "superuser", and there's a "staff" bit that has some effect on the superuser IIRC. Everything else is implemented in Postorius.
We have a helpdesk team that would benefit from being able to access all list pages in the same way as a Superuser, but without the ability to accidentally delete the mail domain for example.
I almost started on this two years ago, but that customer wanted it for individual lists rather than a helpdesk team, and realized that all the relevant owners would be satisfied with promoting moderators to owner. So it didn't happen.
Footnotes: [1] There are several consultants who would be capable of maintenance in the consultant list on the wiki, and more than one who would be able to design and implement the code if you're in a we-want-it-enough- to-pay hurry.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Stephen J. Turnbull wrote:
Is there a way to have more granular permissions in Postorius than either User or Superuser? Not without additional code. It couldn't be a plugin. It would have to be a fork of the main Postorius code at first (ie, you would be responsible for patching it and merging our public releases, there would not be regular releases). I doubt it would be merged in a near- future release, at least I wouldn't be confident enough to do that myself without beta testing on a branch. I don't think it would be hard to implement a "restricted superuser" role. The annoying part would be figuring out where to apply it, as
The user permissions that are configurable under /admin/auth/user/ do not seem to have any effect. As far as I know the only bit that has big effects is "superuser", and
Liam Reilly writes: the "authenticated user", "moderator", and "superuser" roles are implemented via Python "decorators" applied to the functions implementing the various features. And the changes would likely need to be pervasive in page templates, forms, and functional code. there's a "staff" bit that has some effect on the superuser IIRC. Everything else is implemented in Postorius.
We have a helpdesk team that would benefit from being able to access all list pages in the same way as a Superuser, but without the ability to accidentally delete the mail domain for example. I almost started on this two years ago, but that customer wanted it for individual lists rather than a helpdesk team, and realized that all the relevant owners would be satisfied with promoting moderators to owner. So it didn't happen. Footnotes: [1] There are several consultants who would be capable of maintenance in the consultant list on the wiki, and more than one who would be able to design and implement the code if you're in a we-want-it-enough- to-pay hurry.
GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Thanks Stephen.
It looks like we're going to take the simple route of the helpdesk using existing screen sharing tools to assist list owners, rather than providing elevated access in Postorius. Many of our list owners are not technical and so the transition from Mailman 2 to 3 has been challenging for some.
Liam Reilly writes:
It looks like we're going to take the simple route of the helpdesk using existing screen sharing tools to assist list owners, rather than providing elevated access in Postorius. Many of our list owners are not technical and so the transition from Mailman 2 to 3 has been challenging for some.
Understood. Some of the design of Mailman 2 had become unsupportable over the years, and there were some features we needed to add. But accomodating those also causes discontinuities for many users.
I may have a customer for a change related to your request for "view-only" superusers . If it's possible to implement in such a way as to support your requirement as well, I'll let you know. Even if you find that the screen-sharing approach makes it unnecessary for you, having multiple possible use cases makes integrating the feature much more attractive for us.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
participants (3)
-
Liam Reilly -
Odhiambo Washington -
Stephen J. Turnbull