Ticket #2204 (assigned enhancement) — at Version 10
[super] Related (Stuff) Extension
Reported by: | rgrp | Owned by: | ross |
---|---|---|---|
Priority: | critical | Milestone: | ckan-sprint-2012-04-30 |
Component: | ckan | Keywords: | [7.5d][r:3d] |
Cc: | Repository: | ckan | |
Theme: | none |
Description (last modified by ross) (diff)
This is a reworking of the existing apps extension.
Initial proposal at http://wiki.ckan.org/Proposals#Apps_in_CKAN and http://wiki.ckan.org/Proposals#References.2FLinks_in_CKAN
Naming
What do we call this extension?
- related
- RP best IMO but perhaps too close to separate relationships concept?
- relatedstuff
- links
- references
Proposal
"Related Stuff": Apps as in an application (website/service/tool) that uses this dataset (as in Apps and Ideas extension)
- This case seems a general example of wanting to link some external thing to a dataset (e.g. this policy paper refs this dataset, this application uses this dataset, this visualization is built on this dataset cf http://lists.okfn.org/pipermail/ckan-discuss/2011-August/001607.html)
Implementation
New table named Related with following structure
|| id (int) || type || title || description (markdown) || image_id || owner_id || url || created (timestamp)
- type = Idea | App | API | Visualization | Post | Paper | News Article
- Suggest we make this a ckan.ini config option (comma separated ...?)
- image: ?? Depends where we store images. Simplest option would be to change to image_url and leave it to users to have already uploaded an image somewhere. If not we need to support image uploading and storage. See #1692 (add image attribute to datasets and groups) for more discussion, once implemented the URL here can be an internal url.
- owner_id = user_id or creating user (see authorization below)
Related2Dataset (note that related_id, dataset_id tuple should be unique). This allows for m2m connections. If a given related item is only with one dataset this could be simplified. May contain status so dataset owner can turn this on/off.
|| id || dataset_id || related_id
Url
- /dataset/{dataset-name}/related/{related-item-id}/{related-item-title-stringified}
- If a reference item could exist in its own right (and perhaps refer to multiple datasets then it should get its own url at e.g. /related/{id}
- /dataset/{dataset-name}/related/add => Modal dialog on related tab so we can use API to create them.
/dataset/{id}/related <- list
- use image_url for small icon etc, title description (shortened?)
- Click through to full related item (optional)
- dataset owner is shown show / hide button ... (or on /dataset/{id}/related/{id} )
- related owner sees an edit button / icon (pops up modal)
/dataset/{id}/related/{id} (optional)
/dataset/{id} will have a Related tab (with bubble with count).
- Drop down with Add Related -> Pop-up modal and save via API
(Not used: /related/add with dataset prefilled ... )
/related/{id}/edit
Authorization
Addition of related item be considered orthogonal to datasets (and hence with separate authorization i.e. i can add the info that site X uses dataset Y without needing permission to edit dataset Y).
Thus any logged in user could add a Related item. We set the owner of the related item to creating user and going forward only that user or a sysadmin can update or delete.
NB: we could have a system where datasets owners have to approve related items before they show up next to their dataset. This would add substantial complexity so I propose we leave out of phase 1.
Change History
comment:3 Changed 2 years ago by rgrp
- Owner changed from amercader to toby
- Status changed from new to assigned
- Milestone changed from ckan-v1.7 to current-ckan-sprint-2012-04-02