We have been using the workflow module to implement several customer applications, and an upcoming project will require some modifications to the module code itself. I'd like to share with you the problem and get your feedback, so as to better align our direction with the upcoming workflow.module developments.
The system requires to automate a workflow where each step includes new data fields to be input by a designated role. Fields that had been input in previous steps should not be available for editing. Currently, there is no way (known to us) to let the module selectively show/hide and enable/disable data fields.
We have been considering the following approach to solve this:
- Create a new content type with all data fields.
- Modify the workflow module to specify in the settings, for each state, which fields to show/hide and enable/disable.
- Modify the theme of the content type to enforce this per-field specification when rendering the node.
Has anyone encountered similar requirements? Does this approach sound reasonable? Do you know of prior work in this direction?
Thanks for your feedback,
Karim
Comments
General approach sounds right
Hi Karim,
I too have a similar requirement from a client. I expect to tackle this part of the project in about two weeks.
Your general approach sounds right, but I would warn you away from hacking the core module itself. Hiding/showing form elements (or making them required at some stages), is probably better done using hook_form_alter. On node edit forms, you get a copy of the entire node inside of the form, and you can get the workflow state from this data. Then you can look up (in your own tables) which fields should be hidden and alter them out (or turn them into "#type" => "value" elements).
This was going to be my plan of attack.
Please update this thread if you make any progress. I'll do the same.
-Mark
I have done this exact thing
in hook_form_alter(). the code is simple:
if ($form['#node']->_workflow != NEWSLETTER_WORKFLOW_SCHEDULED) {unset($form['field_sent_date']);
}
I just use 'defined' constants at the top for my workflow states since the actual IDs may vary from install to install.
This code will probably break if we get more than one workflow per content-type though..
cheers,
-o
Implementation underway
Thanks for your replies. I started implementing the feature inside the workflow module, but yes I will move the code to a separate module once it works. I expect to be done with the proof of concept by this weekend, so hopefully I can contribute something worthwhile during next week.
Cheers,
K.
sounds exciting!
very cool indeeed!