Workflows
From CKAN
CKAN supports various 'workflows' around managing datasets and especially dataset metadata.
NB: CKAN supports setting of permissions on a per object basis (e.g. per data package or per group). Thus, one can have different permissions for different objects e.g. one could allow any to make edits to one particular data package but for a different data package only allow the sysadmin to edit (or the package owner).
Contents |
Wiki Workflow
In this workflow datasets and their attributes can be edited by anyone (can restrict only to logged-in users).
Moderated Workflow
In this workflow there are 2 classes of users:
- Sysadmins / Moderators
- Editors
Restrictions:
- Only Editors or Sysadmins can create or edit information.
- Sysadmins must approve edits by Editors before they become visible to general users
To use this workflow requires the Moderated Edits extension
Additional Options:
- Editors can be anyone or a specially designated users who have to be invited
Special Case: Approved Publisher Model
This model is used on the IATI registry, where various international organisations and governments can sign up to release reporting on development projects. To support this workflow, the following adaptations were made:
- All packages are released by IATI publishers, normal users cannot submit packages. Publishers (CKAN Entity: Group, renamed in a custom i18n) themselves are typed as one of "Donor", "Community" or "Recipient". The type is stored as a "type" extra on the group and then folded into each indexed package via a monkey-patched as_dict() method on Package. This allows us to facet over packages associated with a specific type of Publisher.
- Anyone can sign up to the site (previously only via OpenID, we should promote the fact that CKAN now has normal user accounts) and create Publisher. The publisher is then created in a "pending" state (monkey-patched VDM) and an email is dispatched to all users that are sysadmins on the site (ckanext.iati.approval) to review the application. Meanwhile, the pending publisher is not shown in any group listings and when called directly, a warning box is included on the page to make the pending status clear. Admins can log in and edit the publisher to select the "active" or "deleted" state depending on whether a publisher is valid or not.
- When creating a publisher both a "Group" and "AuthorizationGroup" are created. The AuthorizationGroup is named after the (Package) Group, in the form group-%(group.id)s-authz. It is updated whenever the Group/Publisher is edited and member lists are kept in sync: Group members are added as AuthzGroup admins and the AuthzGroup has at least read rights on the actual Group (ckanext.iati.authz).
- Packages can only be created by those that are both registered as users and a member of at least one active publisher. This is checked via a helpers.py monkey patch "am_authorized_with_publisher" (ckanext.iati.patch) and through a custom AtLeastOneGroupSelectField used in the package form (ckanext.iati.forms.package).
- When a package is created, a post-creation hook is used to replace its default authorization mode is changed: the individual user is removed as a package admin and replaced by the first authz group that he is a member of. This way, all members of the associated publisher are automatically admins of the new package and removing the individual user would not orphan the package.
Note that this is not a generic mode within CKAN and requires some extension of the existing system through plugins. The full code is available at: http://bitbucket.org/okfn/ckanextiati
tbd: How well does this work with CKAN 1.5 Authorization? What would need to be changed?
Sysadmin Only Workflow
- Lock down so only sysadmin can add or edit any information
