Make module compatible with workflows defined through "Workflow field" module

Hi johnv,

sorry for the late answer.
Currently, the module needs some adjustments to fit with the brand new 2.0 release of Workflow, mostly because of the "Entityzation" that breaks some stuff.

Thank you for offering your help, it will be welcome if needed. ;)

hbemtec

The work is done (it was only a matter of labels) and commited to the latest dev. release.

Feel free to test it and re-open this thread if necessary.

I tested the dev release of Workflow Fields with a Features captured workflow from Workflow 2.0 beta7. Used a workflow field rather than node implementation. Going to Workflow Fields for states gives me a server error. Will test with node implementation and see if that works. If not, will test with workflow built on the site rather than features based. No watchdog entries created.

Thanks for your active testing kolafson.
If the problem is still active and nothing appears on screen or in watchdog, what does your server error log say ?

Ah good point. Error in the server log:

[Mon Dec 30 11:23:22 2013] [error] [client 127.0.0.1] PHP Fatal error: Call to undefined function workflow_get_workflow_states_by_sid() in /var/www/drupal-7.24/sites/fringe3.krisbuntu/modules/workflow_fields/workflow_fields.module on line 40, referer: http://fringe3.krisbuntu/admin/config/workflow/workflow/1

Today I used the node implementation of workflow 2.x instead of the field implementation and it worked as expected. Maybe it doesn't even make sense for the Workflow Field module to work on Workflow module field implementations since the same workflow field could be added to many content types? If that is the case, perhaps the access control functionality should simply be hidden for field implementations. I'm new to this module so I apologize if I'm not understanding the correct usage.

This patch has fixed the problem, please commit this patch.

Patch #9 fixed the "Call to undefined function ..." error. Thanks!

As stated in #8 it looks like there is no support for Workflow Field "version" yet. I always ended up here: http://drupalcode.org/project/workflow_fields.git/blob/96e8a8ae3cd5c3611... when trying to set field visibility... I will try Conditional Fields method without this module and hopefully report back. ;-)

Bad news: Conditional Fields module works *only* with States API which means:

1. Since states are driven by JavaScript only, it is important to understand that all states are applied on presentation only, none of the states force any server-side logic

   ( https://api.drupal.org/api/drupal/includes%21common.inc/function/drupal_... ) = bad for security

2. Supported dependee fields are for now only core fields (D7) or CCK widgets (D6). That is: select, checkbox, radio and text. Other field types might work but are not supported.

   (Conditional Fields project page) => Doesn't work with workflow_default widget. (Both select and checkbox as wokrflow widgets are compatible and working)

Patch in #8 works, but I can see where this discussion is going to.
I tried workflow_fields on a custom entity (built with ECK module), but I'm now getting told that "There isn't a content type mapped to this workflow."

workflow_field seems to work fine with the entity, I just did some light testing. States change and are remembered, so there is a WID and SID's out there, but it is not mapped to the entity (Quick check db table workflow_type_map is empty).

I used this module successfully in the past on content types, and I for one would like to see it work on other entities, so my vote be for work to continue with this module.

Having said that, I got a project to finish, and for that I am going to use conditional fields module instead. I'll keep this discussion in mind.

Patch #9 works fine for me.

Same problem here as Max_Headroom reports "There isn't a content type mapped to this workflow".
I'm using "Workflow Field" on an EntityForm and since Drupal Commerce requires "Workflow Field", I assume then that Workflow Fields is not compatible/usable with any Drupal Commerce site at the moment?

There are lots of people still on the 7.x-1.x version of Workflow. Please do not abandon us.

@NancyDru : just commited something so that the module remains backwards-compatible with Workflow 1.x

Making the module compatible with Workflow Field is gonna take some time. I'll leave this issue opened for patch and ideas proposals. johnv's patch is a beginning, but it cannot be used as-is as it breaks the module if "Workflow Node" is used.

Thanks.

I've made an attempt to make this module support "Workflow Field" module, as I needed to use it in an Entity Form.

I made a patch, trying to make as few changes as possible while making it work for my case.
That means it's not ready to be committed yet (for example if it was my project, I would have changed names in many more variables).
And of course I haven't test if for workflownode & workflow-1.x branch.

So: unless you are a developer or you really know what you are doing, do not use this patch. It may be working, but I cannot guarantee it works for all cases.

Maybe supporting workflowfield (and all entities) will require a kind-of rewrite of this module, and it will be "cleaner" to have 2 versions of the module: version 1.x for workflownode & version 2.x for workflowfield.

marking it for review, only to trigger testbot..

Slight error with the patch (not the code)... re-uploading..
Sorry

Bugfix for my patch.. (forgot to rename a variable from $node to $entity, causing an isset to always return false)

We still need to add a form_alter for custom non-node entities I think. With this patch I am rolling my own form_alter for eck__entity__form_edit_[type]_[bundle] based on the workflow_fields node_form_alter since the node_form_alter doesn't fire for custom entities and I wind up with no fields processed.

Maybe this module needs to move from node_form_alter to form_alter to support custom entities as well as nodes. It doesn't seem to hard to just ad $entity_type to the workflow_fields functions that don't have it.

@derekw: why add a form_alter?

To determine if a user has access to a field or not, hook_field_accessis used.

I'm using entityforms with workflowfield module (not workflownode)
& workflow_fields with my patch above.

It's working fine for me, but it's not "clean" and probably not backwards compatible.

It appears to me (after spending several days tracing the code) that even using workflowfield the form (and form fields) are altered with hook_form_FORM_ID_alter(&$form, &$form_state, $form_id), specifically workflow_fields_form_node_form_alter().

But that's only going to get called for node forms. If I'm using workflowfield with a custom entity, it's not a node so the workflow_fields_form_node_form_alter() never gets called, and I basically get form with no fields. I'm curious/confused how it works successfully with entityforms, because in my mind it shouldn't since they're not nodes.

If I add my own form_alter for the form id that my entity uses, and duplicate what's in workflow_fields_form_node_form_alter() except with entity lingo, then everything works as it should.

For my ECK-generated "Speaker Arrangement" entity type, I have a mymodule_form_alter that looks like the code below. (I think may have had to add entity_type to some of the workflow_fields _support functions.)

My thought is that all this would need to work with both nodes and custom entities would be the logic to identify which $workflow_field_name is active. I think there's already some code for that in the module but I haven't bothered to implement it here.

if ($form_id == 'eck__entity__form_edit_speaker_arrangement_speaker_arrangement'){
    
    $entity = & $form['entity']['#value'];
    $entity_type = & $form['#entity_type'];
    $workflow_field_name = 'field_workflow_registration'; // this should be determined by the module somehow
    $sid = workflow_node_current_state($entity, $entity_type, $workflow_field_name);

  // Check for visible/editable flags.

  $fields = _workflow_fields_get_fields($entity_type, FALSE, $entity_type);
  $form['sid'] = array('#type' => 'value', '#value' => $sid);
  list($visibles, $editables) = _workflow_fields_compute_permissions($sid, $entity_type, $entity, 'edit', $entity_type);

    foreach ($visibles as $field_name => $visible) {
      $editable = $editables[$field_name];

      if (!isset($fields[$field_name])) {
        continue;
      }
      else {
        $field = $fields[$field_name];
      }

      // Find the path to the field in the form.
      if (!empty($field['path'])) {
        $path = $field['path'];
        if (!_workflow_fields_array_path_exists($form, $path)) {
          $path = FALSE;
        }
      }
      else {
        $path = _workflow_fields_array_key_path($field_name, $form, array('#group_children'));
      }
      if ($path === FALSE) {
        continue;
      }

      if ($editable && $visible) {
        if (isset($field['widget']['weight'])) {
          $element = & _workflow_fields_array_path($form, $path);
          $element['#weight'] = $field['widget']['weight'];
        }
        continue;
      }

      // Process the field.
      if (isset($field['process'])) {// Does the field need special handling?
        $param_arr = array(
          &$form,
          $field,
          $path,
          $entity,
          $entity_type,
          $visible,
          $editable,
          isset($field['process arguments']) ? (array) $field['process arguments'] : array(),
        );
        call_user_func_array($field['process'], $param_arr);
      }
      else {// Standard handling.
        _workflow_fields_process_field($form, $field, $path, $entity, $entity_type, $visible, $editable);
      }
    }
  }

After adding the patch to the current dev release and attempting to perform an update, the following error message is shown:

The following updates returned messages
workflow_fields module
Update #7100

Failed: PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'DEFAULT NULL' at line 1: ALTER TABLE {workflow_fields} ADD `entity` DEFAULT NULL; Array ( ) in db_add_field() (line 2844 of /var/aegir/platforms/panopoly-7.x-1.25/includes/database/database.inc).

Guys, the patch from #25 worked fine for me. I was able to set the permissions for my fields on a custom entity successfully.

Also, I took the liberty to adjust the patch to comply with code standards and removed some leftover comments.

Btw, since we're talking about entities, what about adding properties control to this module as well?

Fixing typo

I had the same error as #29 the first time I tried to run update. However, I then cleared the cache and reapplied the update and it appears to have worked.

After trying #31, it works great. The only problem that I've encountered so far, is that the "visible", but not "editable" setting does not work on panel pages. The fields are only visible if the "editable" setting is set as well.

I'm not sure if it that is a problem with the patch, or a general problem with the module. I'll leave at "needs review" for now, since I'm not sure.

Either way, thanks a lot for all of your work.

Thanks for the feedback @NWOM.

Regarding your issue, there's a config page under admin/config/workflow/workflow_fields that has an option to Hide fields marked as "not editable" when editing.. Just uncheck that and save and you should be good to go.

Let us know if that works for you.

Thank you very much for the quick response @natanmoraes. Sadly the handling is the same with or without that setting being set. Anything else that I can provide to help diagnose the issue?

Are you using workflowfield or workflownode?

Also, are you working with a custom entity or a node?

I'll try to have a look in the code in the next days to see if I can reproduce/fix the issue

I'm using workflowfield with a standard node content type. The panels page is overriding the node/edit form. Thanks in advanced for your help.

I found two issues when using multiple Workflow Fields on the same content type. I have two Workflow Fields. One is "Status", and the other is "Group".

1. At the moment, it seems to only use the Workflow Field Settings from the first Workflow ID that has been attached to the entity. I can't say for sure though.

   I can confirm that the settings for the "Status" workflow only have an effect, and if I change the same Workflow Field settings for the same field on the "Group" workflow, it doesn't override the settings on the "Status" workflow for that same field.

   I assume that this patch should instead focus on only one Workflow per entity, since the ability to support multiple Workflows is not manageable using the current interface.

   Perhaps this can be configured on the Entity/Content Type settings itself, allowing you to specify which Workflow Field, that is attached to the entiy, should use Workflow Field Settings on the entity.

2. The second thing I noticed, is that you can't configure the visible/editable settings for another Workflow field. If the first issue is solved by forcing only one field to use Workflow Field settings, then when configuring the "Status" Workflow Field settings you can at least configure the editable/visible settings for the "Group" workflow field. Currently the field is visible, but not editable, which removes all functionality.

Please let me know if any further clarification is needed.

patch #31 worked for me. using workflow field 7.x-2.5.

@natanmoraes Please ignore my comment at #33. It appears I did not understand the difference between visible and editable. I assumed that if a field was visible but not editable on the "node edit form", that it would still be visible. However, it seems that visible pertains to viewing a node, and editable pertains to editing a node.

Also regarding my comment at #39, I assume that as long as it is mentioned that the module works with only one Workflow Field at a time, making changes is not necessary.

In this case, the first problem that I encountered was just an understanding issue, and the other can easily be fixed by stating it on the Module page for example.

As far as I can tell, this patch is RTBC, but I will wait for your feedback. Thanks for your help, and I hope I didn't inconvenience you too much with my issue claims.

Guys, to make the patch RTBC (& eventually commit it), we will need to make it backwards compatible as well, because this version of the module supports workflow 1.x as well.

I would definitively like to have it committed, but it needs more work & (manual) tests to be done first.

@NWOM
Thanks for the update.
I haven't had the chance to check the module yet.

@Zekvyrin
What kind of work/tests do you suggest? As per the comments here, it seems to be working as expected.

Typo: "haven't had the chance to check the patch yet"

@natanmoraes:
What I mean is that since some people are probably still using Workflow 1.x versions (@NancyDru said it in this issue about that a few months ago), we cannot commit a patch which will break the module for them. So there are 2 ways of handling this:

1) We can drop support for workflow 1.x . This means that we should create another branch for this module (Workflow Fields 2.x) which will support workflow 2.x and only.

And some code rewrite would be needed as well if we decide .

2) Make 100% sure that the patch doesn't break anything anywhere. That means that we should test it in every possible way someone will use it: a) using workflow 1.x b) using workflow 2.x but having workflownode enabled instead of workflowfield c) using workflow 2.x with workflowfield. (I don't know if there are other cases)

"c" is the only version I've checked and made the patch for. I don't have a clue if it works in cases a & b. Unfortunately I didn't have the time & the environment to test it.

I only created a patch, which works in my environment and shared it because it might help some people having the trouble I had, and to make a step closer towards "officially" supporting workflow fields. I'm glad that it works for you and some other people, but my recommendation is to really know what you're doing before applying it as I haven't test it in other cases, and it might break your site.

Also the patch is "dirty". Yes you fixed the coding standards/comments, but as I said, my intention was to do as few changes as possible to work fine in my case. For example some variables would need rename (as @johnv also mentioned), which I chose not to change them before someone from the maintainers review the patch.

I wrote these before (comment #22 when I posted the first version of the patch).

I would really like to have some feedback from module's maintainers about the patch and how we will proceed. It's not up to me.

Yes, I have a major site on Workflow 1.x. Updating it to 2.x would be an utter nightmare.

Usage stats show that around 1,500 sites are still on 1.x.

Got it @Zekvyrin.

For now, I'll remove the task assignee in case someone else wants to work on it, since I won't have much time in the next days, I'll try to improve the patch when I have some time

Based on the last comments, I'm putting this as "Needs Work" so that we can get back to it.

Update: Tested with Workflow 7.x-1.2 and I received the following error on the fields visibility page:

Call to undefined function workflow_state_load() in /home/fcaminada/Documents/sandbox/sites/sandbox/modules/workflow_fields/workflow_fields.module on line 40

#31 works for workflow 7.x-2.8

I have to add one thing. I have got into a situation where i have no permission with a user to edit oder view the field but its required AND the user gets the message that the field should get filled which is not possible in that situation. I have added a field after other fields and workflow was set up. I assigned the new field to the first of 2 states to be editable. All old nodes are in state 2 so they should be not able to fill this new field, this was only for new nodes.

EDIT: Found a issue which descibes that problem. It seems to have to do with special field types as file_entity in my case or relation_select #2573907: Incompatibility with Relation Select module - Hidden but still required

@fox_01 Are Having a difficult time following your comment can you restate in detail.

No Problem.
I have a required field which is editable and viewable in state 1 but not in state 2. I created that required field after some nodes had been in state 2 some in state 1. If node were in state 2 when i created this field and they try to save the node the message shows that the required field is required even if its not viewable or editable and in that case not printed to the screen. Thats a trap where no saving is possible. Nodes in the state 1 works correctly and if the field were submitted earlier than nodes in state 2 can also be saved normally.

@Fox_01 seems Seems like an unavoidable issue in your usecase. have your tried reverting nodes to state 1 using or updating field values programmatically or with VBO?

@Kcannick: this would help of cause but is not that practical depending on what you are trying to solve. In my case some requiredfields should only get filled at steps after creation so that fields has to be ignored by validation even they are required because they are not printed to the screen. This is what i would expect

@johnv: This makes sense for me. But i have to note that you could run into the same issue in a special case where you have e.g. 3 steps. Step 1: field is NOT editable. Step 2 editable. Step 3 again not editable. If that field is required it should be undependet if you apply this case to existing or new content and it should be impossible to save step 1 and 3.

I can not find the setting for this. I dont think that the required setting per step is supported by the latest dev version of workflow_fields + patch from #31.

Then for me #31 is working fine.

Can someone clarify the visible vs. editable option?
If I set a field to be visible but not editable, then shouldn't that field be visible and not editable? Currently, a readonly field is not provided if you only select visible.

With visible checked, the field wrapper is being written out to the page but the actual input field is not.

<div id="edit-field-myfield-view" class="form-item form-type-item">

</div>

There seems to be a problem with this line:
$renderable = field_view_field('node', $node, $field['field_name'], 'default');

I've been using #31 in a live environment for over 2 years now. It has worked great so far!