With the introduction of the Workflows module in Drupal 8.3, it seems to me that there's a natural fit here with Webform.

I frequently get requests for more complex approval workflows for webforms. For example:

  • Student submits a course change request: received and approved by advisor, then instructor, then sent to the registrar.
  • Application to attend: Applicant applies, then review team evaluates and admits, then applicant completes full registration information on the same form, then organizers verify and mark as complete (or return to attendee for more info)

Ideally, each webform component can be set to be editable depending on state.

I'd love to hear ideas, opinions, and directions for integrations between Webform and Workflows.

Comments

Shawn DeArmond created an issue. See original summary.

jrockowitz’s picture

I can see where you are going with this ticket. I am also seeing people building custom workflows using the Webform module. I am not sure if core's workflow/moderation initiative can solve all our problems. I need to do a little more research and see if core's workflow can be applied to any content entity.

I am actively working on building out demos for more complex Webform workflows. Right now I am specifically focusing on the application and evaluation pattern. The latest dev release include an demo for building an application form that can be evaluated. The next beta release will include a screencast highlighting this demo.

anpolimus’s picture

Issue tags: +KyivCampCS17
ptsimard’s picture

TL; DR: That's an interesting idea. I too looked at what Workflow could offer before settling on a simple "select" webform element + custom code. I would fully support more core integrations as long as they make things simpler to setup and maintain.

I'm also currently building a quite complex multi-webforms implemented via custom controllers dealing with the "linkage logic", custom pager/progress between webforms and a custom workflow that triggers certain editing conditions/handlers depending on state. Before I decided on Webform for my app, I looked at Workflow + custom entities with field API.

I eventually settled on using a simple "select" webform element. So far it works fine for me and is very easy to setup and keeps it firmly self-contained in a custom webform. But it does require custom code for state behaviors.

I know the workflow module allows you to set specific predefined transitions between states and permission access which is where it can shine. The only implementation of Workflow I'm familiar with it geared toward content types publishing workflow. Maybe this D8 version is generic enough for usage in webform? I don't know enough about it to have a judgment on if it could be integrated in webform or not.

In any case I would fully support more core integrations as long as they make things simpler to setup and maintain.

unsettlingtrend’s picture

I've also got a need for this. I'm not sure what I can add, but the current state of the experimental core workflow module seems to be that any other module can create a "workflow type"; the "content moderation" module then just adds a workflow type that is geared toward content/nodes.

I don't know how much of a pain it would be to develop, but I'm guessing taking a look at how content_moderation works is a good start? (At least, that's where I'm heading....)

jrockowitz’s picture

It is a pain.

I am guessing core's workflow initiative is first focusing on nodes but architected to support any content entity.

Keep in mind that webform submissions DO NOT support revisions because the submission data is not stored using FieldAPI. This might limit how content moderation can be used within the webform module. Approval workflow is still very applicable for the webform module.

infroger’s picture

BTW, "revisions" would be a much appreciated feature for Webforms. In fact, for my use case, I only miss revisions and easy PDF printing (I'm digging through the last lately).

We intend to use Webforms to store data about applications we develop. The form should be filled by different people on different times (even after submission). So, it's like an 'alive' form. I would like to be able to compare revisions of the same submission and see when and who changed which field and what was the old value. Something like Mediawiki Revision History.

I understand it's not a priority for the project. But I was wondering the reason for not having it, since it seems pretty close to it. Now I understand it's a technical limitation. If this limitation could be overcome in the future, it would be great.

From the point of view of a beginner, would it be difficult to save different YAML versions of each submission and show a diff?

unsettlingtrend’s picture

As I understand it (anyone, feel free to chime in if I'm wrong):

- Content Types (nodes) and even the old Webform in D7 (I think?), use/used full blown fields (webform sort of had their own special types, but they were similar to fields in that they had their own, dedicated tables in the database for each field.)

- In D8, the Webform module seems to be saving the form submission data in a single table for ALL forms, in a serialized format (with each submission only taking up a single row), as opposed to full, bloated tables for each field.

I'm not really sure how hard it would be to make the move to revisions for this, but I think that's [at least part of] the reason that it's not such an easy task to just support it the same way that nodes can do it.

jrockowitz’s picture

StatusFileSize
new74.32 KB

Webform for D7 and D8 stores submission data in an Entity-Attribute-Value (EAV) data module. (aka a single table).

Webform for D8 does have a submission (transaction) log that could be used to store previous revisions of submissions as YAML or some other format. The question is do we want revisions so that we have a history any changes and the workflow or do we need to be able to revert to previous revisions.

I could very easily create a WebformHandler that logs all changes to a submission. The handler could even let you choose the log format, HTML, Table, Text, or YAML.

infroger’s picture

"The question is do we want revisions so that we have a history any changes and the workflow or do we need to be able to revert to previous revisions."

Having a history of changes seems easier to implement and would be very useful. Being able to revert to previous revisions would also be nice, but could be a long term goal, imho.

jrockowitz’s picture

Status: Active » Closed (outdated)
Related issues: +#2875006: Porting to Drupal 8

I am going to close this ticket and direct every to the webform_workflow module.

@see #2875006: Porting to Drupal 8

nigelcunningham’s picture

For those interested, I've created https://www.drupal.org/project/config_entity_revisions. It supports revisions of webforms and the workflow API. At the time of writing, it's still work in progress - I'm still to implement matching submissions to a particular revision and unit testing. Apart from that, it should be usable.

jrockowitz’s picture

@Nigel Cunningham Your module is going to be an awesome features/enhancement.

To get more people aware of your effort, I added your module to the Webform module's list of Add-Ons (/admin/structure/webform/addons)
and included it on the Webform: Add-Ons documentation page.

nigelcunningham’s picture

Thanks very much Jacob. It's not quite ready yet so I was going to hang off a bit before asking for that :) That said, much appreciated!

Nigel