Having dug around the models and data structures a bit I am wondering if some of some of these constructs are not Mailman constructs but Postorius constructs, which is to say, third party application level contstructs rather than Mailman core constructs.
Specifically the ones you refer to “domain administrator” and “mailman administrator” don’t seem to be represented in the Mailman core code. Perhaps I’m wrong of course, I’ve just done a little ham fisted glancing over the code but so far I can’t see how a user would get to become “domain administrator” or “mailman administrator”.
Which is fine of course - no problem with these being application level constructs - I’m just trying to understand because I’m writing some authorisation code and I need to know how to authorise a user to the correct level of their privilege.
On 24 Jan 2015, at 11:31 pm, Sumana Harihareswara email@example.com wrote:
On 01/24/2015 12:05 AM, Andrew Stuart wrote:
you can have users with site privileges
I had a look at the data model but couldn’t see this. Would you mind please pointing me in the direction of where user site privilege information is stored?
I can see that there is the concept of “Rosters” but rosters seem to apply to lists and not at a higher level i.e. as far as I can see there’s no way to apply a roster to the system rather than to a list.
The main thing I’m looking for is whether there is an authorisation concept that operates at a higher level than the list.
I wonder is there the concept of some sort of “special” mailing list that is different or hidden or privileged in some way? There is a reference in the documentation to a “site list” but I coudn’t find much more about it. If there is a “special” list then maybe site wide user priveleges can be stored against it.
I can see there is a site_owner in the Mailman config file although this just seems to be an email address to get bounces in certain circumstances, is it used for anything?
On 24 Jan 2015, at 3:13 pm, Terri Oda firstname.lastname@example.org wrote:
On 2015-01-23, 7:12 PM, Andrew Stuart wrote:
Is this defined in any way?
Is there any concept that a given Mailman user has “site admin rights”?
Or is the concept of the “site administrator” not realised in the application and just considered to be someone with operating system level access to the system that Mailman is running on?
In Mailman 2, there's no admin "users" in a typical sense but the site administrator is someone who knows the global password for a site and/or has shell access. The global password lets you log in as an admin to any list, and depending on your settings may let you do things like create and delete lists. And yes, it's really just one shared password
In Mailman 3 there's a much more nuanced user system and you can have users with site privileges (and there's no longer a need to share passwords).
Just yesterday I spoke with Barry and straightened out my own understanding of the privilege levels within Mailman. Here's the hierarchy as I understand it (the first level has the most power and each successive level has less power):
site administrator - has command-line (shell) access to the machine. (The website's system administrator, usually.) Has ultimate power! Can invoke "mailman stop", for instance, to stop mailman services.
Mailman administrator - does not have command line access to the machine, but can use the web interface to change everything within the Mailman installation on that site (that is, can do anything Postorius lets you!). Can create, change, and delete domains, lists, users, and so on.
domain administrator - Any given list belongs to 1 and only 1 domain, which correlates to an actual internet domain name, such as mozilla.org. A domain administrator can create, change/administer, and delete lists. If you set up multiple domains, you can, e.g., have one domain administrator who has power over the lists at the 70 lists at example.com, and another domain administrator for the 40 lists at example.org.
list administrator - can change list settings such as preferred language, digest threshold, footer, etc., and moderate messages, manage users, etc.
list moderator - cannot change the list's settings as a list administrator could, but can allow/reject messages on moderated lists or that trip certain rules, approve subscriptions, ban users, etc.
user - can change their own user preferences
I do not know where all this is laid out in the code, though. And I am totally willing to be told I have gotten the nomenclature wrong!
Sumana Harihareswara http://brainwane.net