[Imc-drupal-dev] Workflow for stories (i.e. draft -> review -> published)?

[Ben West]

Howdy, I've been working on a drupal IMC at http://reboot.stlimc.org. The
site dev has been done largely by me, and, unfortunately, not as well
coordinated with this group as perhaps it should have been.

Anyhoo, something that I've had difficulty setting up is a coherent workflow
for editorial stories and newswire stories. In particular, I was hoping to
implement the following workflows, based on those from dadaIMC:

Editorial Features:
A. Draft (visible to eds) -> B. Peer Review (visible to eds) -> C. Published
in center column (visible to all)
- transition from state A to B occurs when author has completed story (e.g.
unchecks a box marked "Draft" or something)
- transition from state B to C occurs when a proposed feature receives
enough votes from editors

Newswire Stories
A. Initial submission (visible to all) -> B. Promotion to feature (visible
only to eds?) -> C. Published in center column (visible to all)
- transition from state A to B occurs when the story receives enough votes
from users or editors (different vote thresholds for users vs. editors)
- transition from state B to C occurs when a proposed feature receives
enough votes from editors

Users/editors should be able to opt for email notification about any of
these state changes, e.g. "a story was just submitted for feature
consideration..."

Drupal has the workflow <http://drupal.org/project/workflow> and
actions<http://drupal.org/project/actions>modules, which should be
ideally suited for this task, but I've encountered
a problem with setting up workflow states with restricted access (e.g. draft
stories only visible to eds) because of
incompatibilities<http://drupal.org/node/171882>I found between the
workflow_access and taxonomy
access <http://drupal.org/project/taxonomy_access> modules.

Furthermore, I'm reluctant to use Drupal's built-in published/unpublished
property since A) that only represents 2 states, and B) that would require
giving all editors Node Admin access, which makes for very cluttered node
submission forms that can confuse less-than-web-savvy editors. There are
hacks <http://drupal.org/node/41188> related to the published/unpublished
switch, but they don't look pretty. Also, the Node Admin access would let
eds circumvent revision control (e.g. change a story w/o storing the
previous revision), which can become a problem with accountability.

On the up side, I *was* able to create a functional voting system whereby
editors vote features into publication using a combination of taxonomy
access, voting API <http://drupal.org/project/votingapi>, voting
actions<http://drupal.org/project/voting_actions>,
vote up/down <http://drupal.org/project/vote_up_down>, and a custom
action<http://drupal.org/node/135125>to assign taxonomy terms. Maybe
this would be of use to the IndyDrupal
project?




-- 
Ben West
westbywest at gmail.com
http://savetheinternet.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.indymedia.org/pipermail/imc-drupal-dev/attachments/20071112/bd3d9350/attachment.htm