Support workflow states

according to what I recall its states aren't node properties
thus it would need review and consideration

if you want to accelerate the process, check whether workflow or another contrib mod is capable of displaying states in node edition form, if so there are good chances to have it as a driven property
otherwise, such a contrib module should be provided first

well, workflow does provide node edition, that's a good news
then I'll have to study it
(which will take some time, since my vacations went out already)

BTW, is this module misbehaving with regard workflow?
I'm asking because the issue was titled "compatibility.."
or it is rather a request to have "workflow states as driven properties"?

as you should notice, its been a long while since I lost workflow's evolvement track
please, correct me if the following use case is too narrow:
- build a workflow with some states: A, B, C, D (when the target content type is created it starts in A)
- editing the node (or actions, triggers, etc) allows some roles to make transitions to different states
- you would like to have the sate (in this use case I'm talking just about one state) modifiable through comment as it would be a sort of cck_state module (i.e. the same as it would be a node's property)
- am I missing something else with workflow? (I mean, is there anything else than states?)

committed to HEAD (wasn't released with alpha1, but will be on next release)

• download latest dev of Driven API
• latest dev of comment_driven only got cd_inspect support for workflow, i.e. no changes were made
  (therefore updating to latest dev is only needed to have inpect tool working with workflow)
• clear cache
  (otherwise schedule property won't be rendered properly, since its new theme function needs to be registered)
• if driven_nep was previously enabled it will require to be re-enabled to get its proper weight
  (otherwise workflow will go after hidden properties been applied and therefore won't have any effect on them)
  Note that I won't write an update function just to fix the weight of a module within "Driven API" that haven't had its first release yet (not even an "unstable" one)
• enable "Driven workflow properties" module
• make the workflow enabled for node edition but NOT for comments (admin/build/workflow)
• if having it at node edition is undesirable use "Driven Node Edition Policy" to hide state/schedule/comment

PS: the following are workflow's issues that would be nice to have referenced on #718824: follow up foreign issues
but once I checked the amount of bugs it has opened I decided not to waste my time locking if they are already reported nor opening new ones in vain

• workflow_load jumps into unserialize($workflow->options) even when loading the workflow failed (i.e. returned FALSE)
  this causes a workflow's bug, which fortunately doesn't cause a crash
  for illustration (of a resulting side-effect bug) visit admin/build/workflow/edit/999999
  but this needs to be addressed at driven_workflow by checking before calling workflow_load (which brings an unnecessary second DB hit)
• currently workflow-6.x-1.4 has an variable $name being passed from workflow_form_alter to workflow_node_form which is initialized to empty string
  I would recommend to change it to a name like "state", since it is the parent element of state's radios
• take into account that workflow doesn't support revisions (i.e. table {workflow_node} maps nids instead of vids),
  therefore "live comparison" won't reflect state changes (which only matters when using "inspect" tool)
• function workflow_transition uses strtotime imploding date parts without any separator
  it seems to me that year.month.day will result in an undesirable date when month/day have a single digit
  (cdriven is using a hyphen separator before passing it to strtotime)
• input date/time seems to be... GMT or site's?
  if the user's timezone differs from site's timezone the resulting effect disorients me
  when evaluating a transition the timezone is subtracted (user's or site's depending on config)
  and before displaying the timezone is added by core's format_date (expected to be the same previously subtracted)
  but workflow_node_form loads from DB without caring if the viewer user has a different timezone
  and workflow_cron compares against time(),
  which (seems to me) will correspond to the site's timezone, and its delta regarding the user's timezone is never considered
  (there is something I'm not understanding around workflow's timezone handling, if it is just my ignorance, please report it as a bug before next release)
• workflow_tab_form reads $timezone but never uses it,
  timezone is being subtracted before evaluating a transition, and it is added by core's format_date
  therefore reading timezone is unnecessary, but there is a lack of comments and such code is misleading

BTW, this was a whole new feature
since these are absolutely different kinds of driven properties

good screenshots
but regretfully not enough

I have in mind a few reasons for that to happen (besides being a bug)
here is what I would need to know to start discarding

1)
- what version of workflow are you using?
- I'm working with workflow-6.x-1.4, now checking dev tarball I see they are assigning a non-empty value to the $name variable (mentioned at #8)
- what to do? support the recommended release or the development HEAD?
- if this is the problem, I think it should be first an issue for workflow to make another release cycle and then a issue of the driven_workflow properties to be updated
- also it would be valuable if you test with 1.4 and check if state's radios are performing well

2)
- go to "Edition hidden" tab and disable the first checkbox (i.e. uncheck "Enable driven properties")
- then go to edit the node and check if the state's radios properly appear
- if you can see the state's radios, take a DOM inspector to see the HTML id of one of those radios (e.g. <input type="radio" id="edit-workflow-3" ...)
- if you don't see the state's radios, then it should be a "hidden" form element, please, provide a screenshot of that workflow's transitions

3)
- disable ACP module
- check if the state's radios appear in the Driven fieldset of the comment_form
- if so, then you're having an access control configuration issue, check (at "Comment driven" tab) what is into the "Property settings" fieldset

PS: still, there can be another configuration conflicts, but lets start with those three above

for first scenario above: #759664: states on workflow's HEAD (above 6.x-1.4)

you can use workflow's HEAD but it requires patch at #759664 to be applied (to Driven API)
read the patch, it pretty straightforward and commented
and that patch should work despite updates getting into Driven API (unless workflow's HEAD continue changing its variable name)