I am currently associating users, not addresses with these permissions, so your suggestion is compatible with my stuff.
site owner does sound more appropriate than server owner.
Everything else suggested sounds fine to me.
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