Add a way to allow existing or migrated content to be added to a workflow

Hello @cobblestone.consulting,

that would be an interresting feature that we could easilly implement throw the drupal console.
I am going to evaluate that and let you know asap.

Hakim

I second this. I already have content on the site, this content should also be available for editing through form steps...

Hm, no news here... Would it be at least possible to do this at the level of the database (how?)

Ah, I see. The form mode apparently adds a new entry to the database for each step. This is how such entries look like:

1 4bc26c2a-cfa6-4c70-b6d5-6a446a5334e0 group test_group 121 group.step_1 test_group_edit edit_group_content

For simple workflows that only span a single entity type, all that is needed is to add an entry to this database for the first step in the workflow. Something like this

INSERT into table_name VALUES (new_uuid, entity_type, entity_bundle, entity_id, form_mode(1) , workflow_name, step(1))

Whatever the table name is (didn't look in the code or DB, sorry).

In my case:
new_uuid needs to be generated
entity type= group
entity bundle = test_group
Entity ID= some existing group ID
form mode (1) = group.step_1 (first one in the workflow)
workflow name = test_group_edit
step(1) = edit_group_content (first one in the workflow)

Once the first step has been allocated, the subsequent ones will be happily generated by the module as necessary. If more than one entity type is used in the workflow, one such entry would need to be added to the DB per entity ID. Generally: only the entries need to be added where new entities would be added if no list entry exists.

As for the user interfaces, it's easy for the simple case but quickly gets more difficult for complex workflows:

Simple case: just one entity type in the workflow

Non-interactive:
- "add all existing entities of this type to the workflow" button
- equivalent operation with drush (probably the best choice)

Interactive:
- Table that allows the user to "choose which entities to add" like in /admin/content

Complex case: several entity types in the workflow

User would have to manually choose which entity of type 2, 3, 4... must be added to a workflow for each entity of the type 1. It would be helpful if the already chosen/used entities would not be available for choosing, but there is no easy way to allocate the data automatically that I can think of.

Good news is that there is rarely a need to have a multi-entity workflow. When more than one entity type is necessary in a workflow, one can add an entity reference field to the first entity type and use the "inline entity form" in the form. And this is how one would typically design a pseudo-workflow without this module anyway.

That is, a non-interactive drush "add all existing nodes (of type X) to workflow Y" option, would IMO make many potential module users with existing content very happy.

Hello deno,

if you feel confident providing a patch with the feature I'd be glad to review it and merge it.
Otherwise, given the number of open issues we have for now, you'll have to wait a bit for this one to be processed.

Anyway thanks for all your suggestions !

I'm not a developer but I'll ask my colleagues if someone could do this. What would help to speed things up is a comment on the pseudo-SQL command that I wrote above. If we know what the exact command must look like, it will be easier to implement this.

Hi Deno and nicoloye,

I just filed Allow forms_steps to edit users and believe my need is essentially the same. Glad to help push this forward, given that forms_steps seems to be the "Drupal Way" approach to such situations.

@Deno: at least for users, adding the appropriate entry into forms_steps_workflow table (using existing uuid) seems to work.

@nicoloye: is that going to break anything? :)

I know it's been some days without answers. We are working on this issue and we hope to give you a feedback soon.

This is a patch, please give me a feedback, pls.
A drush command has been added.

Somes examples:
- drush fs-attach-workflow —help
- drush fs-attach-workflow example_1 --nid=“63”
- drush fs-attach-workflow example_1 --content_type=“team"

@sebby, thank you for writing the code for this. It's going to save a ton of time for one of my projects.

I haven't covered all the possible edge cases but, all in all, the code is solid and does what's expected. There are just a couple questions and comments I have that might improve it.

1. Rename function `coucou` to `attachWorkflow`. Drush obviously doesn't care, but it will make the code more readable
2. Change the command from `forms_steps_attach_workflow` to `forms-steps:attach-workflow` to align with standard practice in Drush 9.
3. As the options are written, you could pass both `nid` and `content_type` and the code would process both options. Should those be exclusive?

Attached is a revised patch based on that provided in #15.

Beyond the changes I suggested in #18, this also converts the node loading lines to use loadByProperties().

      $nodes = \Drupal::entityTypeManager()->getStorage('node')
        ->loadByProperties([
          'type' => $content_type,
        ]);

@sebby, one change I made to what you had is that I dropped the constraint that the node be published before this command would pick it up. For my use case, we need both published and unpublished nodes. Since apparently your use case needs only published ones, perhaps we could find a way to parameterize the node status?

Hi Team,

I did some major changes on the way you implemented the stuff and also revised the command names.

This should be ok.
Command example: forms_steps:attach-entity example_1 node article 12345678 default step1 --instance_id=51e4e52a-d9d9-44c4-9aa1-9b075255e18c

if instance_id is not provided, one is generated.

Hakim

Working on it...

Updated patch with all missing files.

Hakim

Replacing #22

Patch is ready to be reviewed.

Hakim

The drush command seems to work fine.
I cleaned it a bit and I added a small check on the entity existence before adding it to a workflow.

Hi Nicolas,

I am ok with that, I just added an option to avoid this verification in case of intense import.

Hakim

Nice, to me it's ok, I just added the proper documentation.
I let you review this, after that the thing is RTBC to me.

Ok to be merged.

Merged ! Thank you everybody for your contribution on this issue !