I’m looking forward to being able to set and get domainowner and serverowner (or siteowner or whatever its called). It will allow me to delete lots of code and there’s no greater joy than deleting code.
Are you anticipating this will be in V3.0?
thanks
as
On 24 Feb 2015, at 11:42 am, Barry Warsaw <barry@list.org> wrote:
On Feb 22, 2015, at 11:20 AM, Andrew Stuart wrote:
there was an “application data” table:
———————————————————————————————————————————————————————————————————————— resource_type | resource_id | private/public | key | value ———————————————————————————————————————————————————————————————————————— user list domain server
and: the ability to set domainowner and serverowner permissions in 3.0,
No question, I think domain owner and server owner (or site owner) are concepts that we should capture in the core. I'd accept contributions for this, so let me describe my thinking (open to suggestions!).
The first question is whether to associate addresses, users, or both with the permissions. If you look at the member table (Member model class) you'll see we have a foreign key for both, but the logic ensure that we can't get conflicting values. This allows us to implement the "address as a member" or the "user as a member using their preferred address". I'm not sure whether we need this level of complexity for the site and domain owners.
The other observation is that we'd like to make it easy for both owners two have multiple contact addresses, so that we have fallbacks in case one of them starts to fail.
So I'm thinking we use a User for this association. The user would have to have at least one validated address linked to it.
For domains, we already have a domain table (Domain model class). Since we'd like to be able to associate multiple domain owners, it seems like we need a many-to-many table associating domains to users. (More than one user can own a domain, and any user can own more than one domain.) That table probably doesn't need anything else.
Since we have no site table/model, I think it would be enough to add a flag to the user table/model to indicate whether they are a site owner or not.
Now sprinkle with tests, database migrations, documentation, and REST, and I think you have at least this part solved.
Cheers, -Barry
Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/andrew.stuart%40s...
Security Policy: http://wiki.list.org/x/QIA9