[ckan-dev] moderated edits c(r)ep. http://trac.ckan.org/ticket/1129
Rufus Pollock
rufus.pollock at okfn.org
Sun May 15 14:23:40 UTC 2011
On 13 May 2011 16:50, Seb Bacon <seb.bacon at okfn.org> wrote:
> Any chance of an entity diagram of some kind? Even just a photo of a
> sketch on a bit of paper. I'm having trouble quickly digesting all of
> this.
A nice complement to Seb's request is to summarize the high-level use
cases and lower level requirements we have here.
## Use-case (from CEP)
1. A user comes and edits a package (or other domain object).
2. This edit generates a new revision of the object but this does not
automatically become the 'active' revision displayed to visitors but
instead is held until the moderator accepts it. Such revisions are
known as Pending.
* The moderator is notified (?)
3. The moderator is shown a list of "revisions" (in diff-format?) and
can choose to accept or reject.
* The most recent accepted revision is then the Active revision and
it is this revision of the object which is now displayed to users.
* Question: who is moderator and how are they specified (i.e. is there
a web interface for setting moderators)?
* Answer (?): moderator will be the object owner/admin as defined by
the authorization system.
Question: is it possible for multiple 'pending' edits to a given object?
Question: If yes this requires some thought: consider package X is at
revision R1. A edits X generating a pending revision R2. B then edits
package X. When editing is B shown R2 or R1? If R2 the experience will
be a bit odd (when editing the object will look different from what
they just saw in read view). If R1 then each pending revision will be
in isolation from each other and when a pending revision is finally
accepted all previous pending revisions will simply be discarded (this
could be quite frustrating: suppose I edit a package's notes to
generate a pending revision. Just after saving I notice that I had a
typo in notes -- I'll now need to completely reenter the notes change
to make that one letter correction (this also begs the question: can I
as revision creator see my pending revision or not once created?)
## Requirements
This is by no means all. But this repeats one set that David mentioned earlier:
We need to get a dict for an object (and associated objects):
1. The latest active revision. (last approved edit)
[ 2. The latest revision - RP: this would seem covered by either 1 or 3]
3. All the unapproved revisions (moderation queue).
4. A point in history/time or a particular revision.
My comment: I wonder whether for 3 and 4 diffs would be sufficient
rather than full objects -- that is, it is enough, for say a moderator
be able to look at a 'dict-diff' between current active revision and
any pending revision. Ditto for history.
I mention this because this because diffs may be easier and even
possible in circumstances where getting "dict" (at least in form
suitable for Objectization) is not (e.g. imagine the model has changed
and there are old dicts that haven't migrated -- could still do a
dictionary diff but wouldn't be able to load).
rufus
More information about the ckan-dev
mailing list