Ability to define user as domainowner or serverowner

Bug #1423756 reported by Andrew Stuart
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNU Mailman
Fix Released
High
Abhilash Raj

Bug Description

I had an idea about rounding out the Mailman permissions model, interested in hearing thoughts on it. Obviously there has been considerable discussion on this topic before.

Mailman already carries much of the information needed for determining user permissions to Mailman resources. Only two things are missing: 1: the ability to define a user as being a “serverowner”
2: the ability to define a user as being a “domainowner”

(You’ll need to look at this email in plain text to see the table properly).

The Mailman permissions model currently looks like this:

resource_type roles resource_id user_identifier where to find permission
---------------------------------------------------------------------------------------------------------
user userowner n/a UUID (defined in user record)
list listowner list_id subscriber (defined in list member record)
list listmember list_id subscriber (defined in list member record)
list listmoderator list_id subscriber (defined in list member record)
list listnonmember list_id subscriber (defined in list member record)

I am suggesting adding two further permissions to the existing permissions model, which would look like this:

resource_type roles resource_id user_id where to find permission
---------------------------------------------------------------------------------------------------------
server serverowner n/a UUID (not currently defined in Mailman)
domain domainowner mail_host UUID (not currently defined in Mailman)

To implement, it would need to be possible to define as user as being a ‘serverowner’, and also to be able to define a user as being a ‘domainowner’ for any given domain. It should be possible to define multiple user with the serverowner role and it should be possible to define multiple users with the domain owner role.

If it were possible to do so within the Mailman core then there would be a completely usable permissions model entirely within Mailman, and no need to store any additional permissions data outside Mailman. The permissions model would allow definition of user access to any Mailman resource including domains and servers.

The interpretation of the permissions would still be up to the application that consumes the REST API, as is currently the case.

There would need to be methods available via the REST API to:
set domainowner role for a user
set serverowner role for a user
delete domainowner role from a user
delete serverowner role from a user
find if a specific user holds domainowner
find if a specific user holds serverowner role
find all domainowners for a domain
find all serverowners

Related branches

Barry Warsaw (barry)
Changed in mailman:
status: New → Triaged
importance: Undecided → High
assignee: nobody → Barry Warsaw (barry)
milestone: none → 3.0.0b6
Revision history for this message
Barry Warsaw (barry) wrote :

This needs to be tackled at several layers.

Within the model, I think we add a flag to the user object to indicate whether they are a server_owner or not. It defaults to False.

Also at the model layer, Domains currently have a `contact_address` field. I think this should go away in favor of a set of user references. This will probably need to go in a separate table. The field would be called `owners` and it would iterate over user objects for users who own the domain. I wish we could use a roster but rosters require mailing lists.

There will need to be a database migration for these changes. Tests and docs too.

After that, both features need to be plumbed through the REST API. For the server_owner flag, it's easy; just add the boolean to the user record.

For domains, we probably need a subresource which is a collection of owners, i.e. users. That might make the _DomainBase a little trickier but I think it can be done. Then that subresource probably needs the usual GET, POST, PUT, PATCH, DELETE methods to add and remove domain owners.

Docs and tests for these too.

Am I missing anything? Would anyone like to take a crack at this?

Changed in mailman:
assignee: Barry Warsaw (barry) → nobody
Revision history for this message
Andrew Stuart (andrew-stuart) wrote :

If there is a GSOC student with the skills to take this on then that would be ideal as I’m struggling to find enough time to get my own code finalised.

Would it make sense to post to mailman-developers and ask if there are any GSOC’s up for it?

as

Revision history for this message
Andrew Stuart (andrew-stuart) wrote :

Actually re-thinking this after my post of 20 minutes ago. If Barry is willing to look at it that might be the best way to move ahead. Possibly too challenging for a GSOC student?

Changed in mailman:
assignee: nobody → Abhilash Raj (raj-abhilash1)
tags: added: mailman3-suite-blocker
Barry Warsaw (barry)
Changed in mailman:
assignee: Abhilash Raj (raj-abhilash1) → Barry Warsaw (barry)
status: Triaged → In Progress
Revision history for this message
Abhilash Raj (raj-abhilash1) wrote : Re: [Bug 1423756] Re: Ability to define user as domainowner or serverowner

I am already working on this, if you want to continue with my branch it is
here:

lp:~raj-abhilash1/mailman/bug_1423756

Revision history for this message
Andrew Stuart (andrew-stuart) wrote :
Download full text (3.5 KiB)

I’m not working on it although Barry might be.

On 25 Mar 2015, at 2:02 pm, Abhilash Raj <email address hidden> wrote:

I am already working on this, if you want to continue with my branch it is
here:

lp:~raj-abhilash1/mailman/bug_1423756

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1423756

Title:
 Ability to define user as domainowner or serverowner

Status in GNU Mailman:
 In Progress

Bug description:
 I had an idea about rounding out the Mailman permissions model,
 interested in hearing thoughts on it. Obviously there has been
 considerable discussion on this topic before.

 Mailman already carries much of the information needed for determining user permissions to Mailman resources. Only two things are missing: 1: the ability to define a user as being a “serverowner”
 2: the ability to define a user as being a “domainowner”

 (You’ll need to look at this email in plain text to see the table
 properly).

 The Mailman permissions model currently looks like this:

 resource_type roles resource_id user_identifier where to find permission
 ---------------------------------------------------------------------------------------------------------
 user userowner n/a UUID (defined in user record)
 list listowner list_id subscriber (defined in list member record)
 list listmember list_id subscriber (defined in list member record)
 list listmoderator list_id subscriber (defined in list member record)
 list listnonmember list_id subscriber (defined in list member record)

 I am suggesting adding two further permissions to the existing
 permissions model, which would look like this:

 resource_type roles resource_id user_id where to find permission
 ---------------------------------------------------------------------------------------------------------
 server serverowner n/a UUID (not currently defined in Mailman)
 domain domainowner mail_host UUID (not currently defined in Mailman)

 To implement, it would need to be possible to define as user as being a ‘serverowner’, and also to be able to define a user as being a ‘domainowner’ for any given domain. It should be possible to define multiple user with the serverowner role and it should be possible to define multiple users with the domain owner role.

 If it were possible to do so within the Mailman core then there would
 be a completely usable permissions model entirely within Mailman, and
 no need to store any additional permissions data outside Mailman. The
 permissions model would allow definition of user access to any Mailman
 resource including domains and servers.

 The interpretation of the permissions would still be up to the
 application that consumes the REST API, as is currently the case.

 There would need to be methods available via the REST API to:
 set domainowner rol...

Read more...

Barry Warsaw (barry)
Changed in mailman:
assignee: Barry Warsaw (barry) → nobody
Changed in mailman:
assignee: nobody → Abhilash Raj (raj-abhilash1)
Revision history for this message
Andrew Stuart (andrew-stuart) wrote : Re: [Bug 1423756] Ability to define user as domainowner or serverowner

Hi Abhilash

I’m happy to test this when you’ve got it to the state that you’re happy with.

thanks

Andrew

Revision history for this message
Abhilash Raj (raj-abhilash1) wrote :

Hi Andrew,

I am working on this branch: https://code.launchpad.net/~raj-abhilash1/mailman/bug_1423756/ . The work is complete, except for one doctest on which I need some help.

Revision history for this message
Andrew Stuart (andrew-stuart) wrote : Re: [Bug 1423756] Re: Ability to define user as domainowner or serverowner
Download full text (3.6 KiB)

OK thanks Abhilash,

I’ll test it tomorrow and let you know how I go.

thanks

as

On 6 Apr 2015, at 8:53 am, Abhilash Raj <email address hidden> wrote:

Hi Andrew,

I am working on this branch: https://code.launchpad.net/~raj-
abhilash1/mailman/bug_1423756/ . The work is complete, except for one
doctest on which I need some help.

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1423756

Title:
 Ability to define user as domainowner or serverowner

Status in GNU Mailman:
 In Progress

Bug description:
 I had an idea about rounding out the Mailman permissions model,
 interested in hearing thoughts on it. Obviously there has been
 considerable discussion on this topic before.

 Mailman already carries much of the information needed for determining user permissions to Mailman resources. Only two things are missing: 1: the ability to define a user as being a “serverowner”
 2: the ability to define a user as being a “domainowner”

 (You’ll need to look at this email in plain text to see the table
 properly).

 The Mailman permissions model currently looks like this:

 resource_type roles resource_id user_identifier where to find permission
 ---------------------------------------------------------------------------------------------------------
 user userowner n/a UUID (defined in user record)
 list listowner list_id subscriber (defined in list member record)
 list listmember list_id subscriber (defined in list member record)
 list listmoderator list_id subscriber (defined in list member record)
 list listnonmember list_id subscriber (defined in list member record)

 I am suggesting adding two further permissions to the existing
 permissions model, which would look like this:

 resource_type roles resource_id user_id where to find permission
 ---------------------------------------------------------------------------------------------------------
 server serverowner n/a UUID (not currently defined in Mailman)
 domain domainowner mail_host UUID (not currently defined in Mailman)

 To implement, it would need to be possible to define as user as being a ‘serverowner’, and also to be able to define a user as being a ‘domainowner’ for any given domain. It should be possible to define multiple user with the serverowner role and it should be possible to define multiple users with the domain owner role.

 If it were possible to do so within the Mailman core then there would
 be a completely usable permissions model entirely within Mailman, and
 no need to store any additional permissions data outside Mailman. The
 permissions model would allow definition of user access to any Mailman
 resource including domains and servers.

 The interpretation of the permissions would still be up to the
 application that consumes the REST API, as is currently th...

Read more...

Revision history for this message
Barry Warsaw (barry) wrote :

Which doctest do you need help with, and what's the problem?

Revision history for this message
Abhilash Raj (raj-abhilash1) wrote :

Check out this error trace: http://pastie.org/10075809 . I am not able to fix it.

Revision history for this message
Barry Warsaw (barry) wrote :

I'll fix that when I merge.

Barry Warsaw (barry)
Changed in mailman:
status: In Progress → Fix Committed
Barry Warsaw (barry)
Changed in mailman:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.