Publisher hierarchy

[dread]

'Publisher' entities in the model. They are hierarchical.

'User-Publisher' connections with one or more roles (e.g. drafter, moderator).

Authorization settings can control who can set what values in a 'published by' type field.

Publishers and User-Publishers available to read in the API.

Future tickets will provide:

• API to write Publishers and User-Publishers
• UI to edit Publishers and User-Publishers

(This feature deprecates authorization groups)

[pudo]

This ticket is essential I think. I would propose we should be a bit more radical here, though:

• Introduce an "Agent" SQLAlchemy object and derive both publishers and users via single table inheritance.
• Make agent the central object of authorization, e.g. by introducing c.agencies including the user account, visitor, logged_in, etc.
• Abolish AuthorizationGroups? in favor of publishers. Yes, they are different but the use case for what AuthzGroups? do and Publishers don't is just nerdery.
• Restructure URLs to be /<agent>/<package_name> rather than /package/<package_name> and have /<agent> be a useful list of managed resources rather than a revision list (users current home page).
• Make Agents a primary facet for all kinds of navigation.

Of course this would be done incrementally but I think we should agree on some such scheme as a marching direction.

[dread]

I think it is a good idea to allow both users and publishers to be the object of authorization. The user_object_role table and all logic surrounding it would be simpler.

I deliberately didn't suggest any detail on the authz front because I know other related changes are afoot so it would be useful for David Raznick to contribute here.

I really like the url ideas - more like github. /<agent> having a list of packages and a search box, plus a link to the latest revisions would be great. /package/<package_name> would usefully redirect to /<agent>/<package_name>. I do think this should be split off into a separate ticket though. What do you think?