Ticket #1198 (new enhancement)

Opened 3 years ago

Last modified 23 months ago

Publisher hierarchy

Reported by: dread Owned by:
Priority: critical Milestone: ckan-backlog
Component: ckan Keywords:
Cc: kindly, pudo Repository: ckan
Theme: none


'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)

Change History

comment:1 Changed 3 years ago by 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.

comment:2 Changed 3 years ago by dread

  • Cc kindly, pudo added

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?

comment:3 Changed 23 months ago by seanh

  • Milestone set to ckan-backlog
Note: See TracTickets for help on using tickets.