Ability to define user as domainowner or serverowner
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| GNU Mailman |
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: Needs Fixing on 2015-04-06
-
Diff: 907 lines (+247/-92)17 files modifiedsrc/mailman/app/registrar.py (+0/-2)
src/mailman/commands/docs/create.rst (+1/-2)
src/mailman/commands/tests/test_lists.py (+1/-1)
src/mailman/database/alembic/versions/46e92facee7_add_serverowner_domainowner.py (+36/-0)
src/mailman/interfaces/domain.py (+5/-8)
src/mailman/model/docs/domains.rst (+26/-23)
src/mailman/model/domain.py (+37/-16)
src/mailman/model/tests/test_domain.py (+23/-1)
src/mailman/model/user.py (+11/-1)
src/mailman/rest/docs/addresses.rst (+1/-0)
src/mailman/rest/docs/domains.rst (+8/-25)
src/mailman/rest/docs/users.rst (+17/-0)
src/mailman/rest/domains.py (+19/-6)
src/mailman/rest/lists.py (+1/-1)
src/mailman/rest/tests/test_domains.py (+12/-0)
src/mailman/rest/users.py (+48/-5)
src/mailman/testing/layers.py (+1/-1)
- Mailman Coders: Pending requested 2015-04-07
-
Diff: 1444 lines (+641/-118)21 files modifiedsrc/mailman/app/registrar.py (+1/-1)
src/mailman/commands/docs/create.rst (+1/-2)
src/mailman/commands/docs/membership.rst (+1/-1)
src/mailman/commands/tests/test_lists.py (+1/-1)
src/mailman/database/alembic/versions/46e92facee7_add_serverowner_domainowner.py (+56/-0)
src/mailman/interfaces/domain.py (+7/-9)
src/mailman/model/docs/domains.rst (+36/-28)
src/mailman/model/docs/registration.rst (+1/-1)
src/mailman/model/docs/users.rst (+15/-0)
src/mailman/model/domain.py (+42/-15)
src/mailman/model/tests/test_domain.py (+93/-0)
src/mailman/model/user.py (+13/-1)
src/mailman/rest/docs/addresses.rst (+1/-0)
src/mailman/rest/docs/domains.rst (+96/-27)
src/mailman/rest/docs/users.rst (+98/-1)
src/mailman/rest/domains.py (+25/-8)
src/mailman/rest/listconf.py (+3/-10)
src/mailman/rest/tests/test_domains.py (+54/-0)
src/mailman/rest/users.py (+87/-12)
src/mailman/rest/validator.py (+9/-0)
src/mailman/testing/layers.py (+1/-1)
Changed in mailman: | |
status: | New → Triaged |
importance: | Undecided → High |
assignee: | nobody → Barry Warsaw (barry) |
milestone: | none → 3.0.0b6 |
Andrew Stuart (andrew-stuart) wrote : | #2 |
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
Andrew Stuart (andrew-stuart) wrote : | #3 |
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 |
Changed in mailman: | |
assignee: | Abhilash Raj (raj-abhilash1) → Barry Warsaw (barry) |
status: | Triaged → In Progress |
Abhilash Raj (raj-abhilash1) wrote : Re: [Bug 1423756] Re: Ability to define user as domainowner or serverowner | #4 |
I am already working on this, if you want to continue with my branch it is
here:
Andrew Stuart (andrew-stuart) wrote : | #5 |
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:/
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...
Changed in mailman: | |
assignee: | Barry Warsaw (barry) → nobody |
Changed in mailman: | |
assignee: | nobody → Abhilash Raj (raj-abhilash1) |
Andrew Stuart (andrew-stuart) wrote : Re: [Bug 1423756] Ability to define user as domainowner or serverowner | #6 |
Hi Abhilash
I’m happy to test this when you’ve got it to the state that you’re happy with.
thanks
Andrew
Abhilash Raj (raj-abhilash1) wrote : | #7 |
Hi Andrew,
I am working on this branch: https:/
Andrew Stuart (andrew-stuart) wrote : Re: [Bug 1423756] Re: Ability to define user as domainowner or serverowner | #8 |
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:/
abhilash1/
doctest on which I need some help.
--
You received this bug notification because you are subscribed to the bug
report.
https:/
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...
Barry Warsaw (barry) wrote : | #9 |
Which doctest do you need help with, and what's the problem?
Abhilash Raj (raj-abhilash1) wrote : | #10 |
Check out this error trace: http://
Barry Warsaw (barry) wrote : | #11 |
I'll fix that when I merge.
Changed in mailman: | |
status: | In Progress → Fix Committed |
Changed in mailman: | |
status: | Fix Committed → Fix Released |
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?