[EXPORTING] Workflow exported to new feature even if it already exists in an other feature

In the past, it was possible to have a feature with a workflow field, without its workflow. ATM the workflow is inserted automatically. In your use case, is it needed to have two features? IOW , is this just a helpful remark, or are gou hindered in your use case?

(Not confirming, just adding the referenced issue as a "related issue" so that the people "over there" are also automatically informed about this issue (and its status).)

We are experiencing this issue as well. We have several content types with workflow field instance on them. Each with their own feature, plus a separate workflow feature to hold base workflow configuration. We need to be able to manage each of these individually.

Each time we create or update a feature that includes the workflow field instance it includes conflicting Workflow code in each one. We have been manually removing this code each time.

The exporting of workflow and Workflow Field definition is now decoupled.

That was the wrong approach.

IMO the system works fine.
When you export a workflow_field, it add the workflow as a dependency. This is OK for simple workflows (1 field, 1 workflow). it avoids confusion for the user.

For complicated configurations, you have more complicated options.
At /admin/structure/features/create, you can creat a feature. There, you can also UNCHECK the "Workflow (n) (Workflow)" part.

I hope you can agree with that.

I can confirm this behavior. And agree with kaare-- if we could simply configure workflow inclusion/exclusion via the standard features ui it wouldn't be an issue.

The problem is, every time i save my field bases feature, workflow silently insists on including itself (the fieldset doesn't even appear at all-- not even empty), so once it's been generated, it immediately conflicts with the config feature I use for site configuration.

So far the only way i've found to 'fix' it, is to resave the config feature unchecking the workflow there (the fieldset does show there), generate it, go to the field base feature, uncheck workflow there (it now shows), generate it again, then go back to the config feature, recheck the workflows, and finally generate the feature again. That's 4 feature generations when it should be one.

So far I haven't been able to debug why the workflow fieldset isn't showing in the conflicted feature-- fixing that would take care of the issue.

There's actually no patch here that 'needs work' atm.

@kaare /#4 - you mean you have a separate feature that contains the workflow definitions, the workflow field bases, and workflow field instances all together? This breaks the whole field_bases in one feature best practice, but it might be worth it until this has a fix.

It seems to be working fine so far. It drives me crazy to not have all my field bases in one place, but rebuilding all those features every time something changed was driving me crazier, lol.

Thanks for the tip!

Perhaps the committed #2484297-47: Features import / revert broken in 2.5+ contains an improvement for this issue.

The behavior described above is by design. See the code below // Add dependency on workflow_field:

  /**
   * Generates the result for hook_features_export().
   */
  public function export($data, &$export, $module_name = '') {
    $pipe = parent::export($data, $export, $module_name);

    foreach ($data as $workflow_name) {
      if ($workflow = workflow_load_by_name($workflow_name)) {
        // Add dependency on workflow_node.
        if (count($workflow->getTypeMap())) {
          $export['dependencies']['workflownode'] = 'workflownode';
        }
        // Add dependency on workflow_field.
        $export['features']['Workflow'][$workflow_name] = $workflow_name;
      }
    }

    return $pipe;
  }

I don't think this behavior is consistent with Features. Field bases are exportable. Field instances are exportable. A field instance isn't tied to its field base. There's no assumption that a field base should automatically be exported with a field instance. Organic Groups doesn't do anything like this, nor does Panelizer or File Entity/Media. I can't think of another module that provides exportables that makes a similar assumption.

Attached is a patch to remove this behavior.

#19 is committed. Thanks.