🇳🇱Netherlands @johnv

A new version 2.1.9 is released.

Thanks, fixed in #3554208-9: Introduce WorkflowUser → with credits.

I can now reproduce the error from #6:

The website encountered an unexpected error. Try again later.

Symfony\Component\Validator\Exception\UnexpectedValueException: Expected argument of type "string", "array" given in Symfony\Component\Validator\Constraints\LengthValidator->validate() (line 35 of vendor\symfony\validator\Constraints\LengthValidator.php).

It comes with a message: "Warning: Array to string conversion in Drupal\Core\TypedData\TypedData->getString() (line 113 of core\lib\Drupal\Core\TypedData\TypedData.php).

It happens when adding a new Node with 2 Workflow Fields, and save without touching any ajax button. Just add a title and [Save].
Not sure what triggers the problem, but the 2nd Workflow type was not touched since a long time.
I saved the Workflow type's 'Edit' page, along with States, Transitions, 'Manage Form Display'.
The last page 'Manage Form Display' was needed for another error in #3555256-3: Fails to display user edit form when workflow field is contained within a paragraph →

That indeed generates the same error.
But that does not seem to be the root cause.
Please save the 'Manage form display' tab of your Workflow type and report back.

johnv → created an issue.

[]... issue just occurs if the widget of workflow status field is set to "Check boxes/radio buttons". After changing it to "Select" or "Workflow Transition form" anything works fine for me.

This is strange. I would expect problems on "Workflow Transition form" on one hand, and Checkbox/Radio or Select on the other hand.
Also, there is a small core difference between Checkbox/Radio (only a single value) ans Select (an array with one or more values).

Is the quote correct?

This setup is too difficult to reproduce. I will try having a WorkflowField inside another WorkflowField (as an attached field).

Please try new v2.1.8 ( = latest dev from today).
I made some adaptation to the $form_state. In my test, now Ajax field widgets work on edit and create, combining such fields on both Node and Transition.

Before diving only your detailed information, please try again with the newly released 2.1.8 version.
That version implements the WorkflowTransitionForm as any other Widget, removing a lot of redundant code.

This is now complete, and also the Ajax widgets on Node and WorkflowTransition are working on Node create and Node edit.

This is solved with latest commit #3552010-16: Manage Transition widget via Workflow 'Form Display' field settings →

Adding #2596317 as related.

Current status of the 'File' field problem is in this follow-up issue: 🐛 Add support for File (AJAX) item on WorkflowTransition /3 Active
(In fact, it seems a problem with any Ajax widget)

Current status of the 'File' field problem is in this follow-up issue: 🐛 Add support for File (AJAX) item on WorkflowTransition /3 Active
(In fact, it seems a problem with any Ajax widget)

Added all relevant info from comments into issue summary.
Setting status to 'Postponed', just to not have it closed, in case other people have the same problem.

johnv → created an issue.

johnv → created an issue.

Please try latest dev version.
It contains less custom code in the processing of (attached) fields.

Thanks. For some reason, my Views is broken, and cannot add fields/filters to a view.
This needs to wait until I have refreshed my installation.

@sboden, above commit made the code a bit more explicite.
I do not expect a change, but please test.

@e5sego, do you already participate in 🐛 Drupal\Core\Field\WidgetBase::errorElement() Active ?

There is a broken use case with multiple value fields, caused by a core error.
Do you also have a problem when you do not add a value in the multiple value field, or only 1 value.
(Effectively, my question is: do you only have problems when to push a 'ajax submit' button on a field, before pusing the 'node submit' button?)

Please test latest version, where I reuse the element upon ajax submit, instead of generating it again.

Please check latest version.
The hooks are now applied to the form (as core design and expected)
The hooks are now NOT applied to the widget (as core design and expected).

Do you expect the hooks to be applied on the widget?
For that you can use field.api.php function hook_field_widget_single_element_form_alter

Hi Sven,
Good to hear you found the problem.
Indeed, i did change the first parameter in my cope, because the IDE started to complain.
But my intention was not to break compatibility.
Ley me check what goes wrong.

Added. Thanks.

I added the following to SMS notification schema:

    allow_same_state:
      type: boolean
      label: 'Allow Same State Transition'

When you disable the checkbox, and save the (SMS) notification form, and then re-open, the value is not updated.

I guess this is only needed when you have a Notification from ANY state to ANY state?

johnv → created an issue.

If the report still reports an error integer vs. false, please save the mentioned notification.

johnv → created an issue.

Do you still encounter that error?
Please reports back, and I will create a new version 2.1.8

please try again.

A last commit also supports attached FileItem fields on Workflow.

It took me an unfair amount of time, but finally uploading files (hopefully any item with an ajax widget) workf bont onthe History tab and on the Node form widget.

Please test and report back.
Then I will creaste a 2.1.8 version.

I am finising a new patch. Cleaning up the code, now.

I forgot to add new files on the latest dev. Please downl;oad again. and report back.

johnv → created an issue.

johnv → created an issue.

I think the current status is correct.
I still am preparing some facility to make this configurable.
The issue islong-lasting. See attached D7 issue.

Realizing this is an old issue...
Did one of the followers indeed make use of the 'file upload' attached field? and did an update to a recent version?

And have a working file upload?

Please check 🐛 I can't upload file in the workflow transition Active and share your code.

P.S. the hook is renamed:
- from function hook_copy_form_values_to_transition_field_alter()
- to function hook_workflow_copy_form_values_to_transition_field_alter()
but both version are still being called.

The version 2.1.7 means that the error (still) occurs in 2.1.7, and in fixed in 2.1.7+dev, and later version 2.1.8
So, the patch is not included in 2.1.7, yet.
Can you upgrade to DEV version? or wait for 2.1.8

This solves the problem with the upload widget.
The patch is too big - the main part is in src/Element/WorkflowTransitionElement.php, where field were removed.

The current status is:
- the file upload has no error,
- the file is indeed uploaded, as can be seen in /admin/content/files
- the file is not displayed upon node view or Edit transition.
- the hook_workflow_copy_form_values_to_transition_field_alter() should fix the problem, but apparently, does not.

I found the error.

I will need time. I f you need a quick fix, please uncomment the fillowing line in WorkflowTransitionElement::copyFormaluesToTransition():

    foreach ($attached_field_definitions as $field_name => $field) {
      // Remove value, (E.g., 'field_name' ruins Comment's 'field_name').
      // $form_state->unsetValue([$field_name]);  // <-- comment this line
    }

There is a problem with the widget wrappers in FileWidget::submit():

  public static function submit($form, FormStateInterface $form_state) {
    // During the form rebuild, formElement() will create field item widget
    // elements using re-indexed deltas, so clear out FormState::$input to
    // avoid a mismatch between old and new deltas. The rebuilt elements will
    // have #default_value set appropriately for the current state of the field,
    // so nothing is lost in doing this.
    $button = $form_state->getTriggeringElement();
    $parents = array_slice($button['#parents'], 0, -2);
    NestedArray::setValue($form_state->getUserInput(), $parents, NULL);

    // Go one level up in the form, to the widgets container.
    $element = NestedArray::getValue($form, array_slice($button['#array_parents'], 0, -1));
    $field_name = $element['#field_name'];
    $parents = $element['#field_parents'];

    $submitted_values = NestedArray::getValue($form_state->getValues(), array_slice($button['#parents'], 0, -2));

We must test several use cases:
- Node Edit widget with radiobuttons
- Workflow History tab with radiobuttons
- Node Edit widget with actionbuttons
- Workflow History tab with actionbuttons

But all are wrong

Indeed, I encounter the same error.
No problem when attaching a Number field, so there is a problem with the FileWidget.
Above patch addresses some errors I encountered when adding a File field (and accidentally removing an existing Number field).

johnv → created an issue.

It seems you have an error in the formatter. Is that correct?
Please check if the file upload went ok.

I think we dis nog got it working, in the past.
See https://www.drupal.org/project/workflow/issues/2899025 ✨ Add field type 'file' support on WorkflowTransition Fixed

Thanks, not sure why/when this happens - I will keep an eye on it.

I think #13 is the culprit. It removes some checks before checking all possible transitions.
They are now back. Since they are intended for better performance. It is now in the comments.
I cannot reproduce the error though.
I will check your dedicated issue 🐛 Call to a member function getCacheTags() on null Active

Please apply above patch.
I will commit more patch, but those are only to reduce duplicate code.
Thanks!

Thanks for working on this.
Interesting finding.
That does indicate that the author role is added to the user wrongly some where. Does it not?

johnv → created an issue.

johnv → created an issue.

Please follow the attached issue ✨ [Meta] Display/hide/require the Widget subfields based on State/Role Active

From ✨ WorkflowTransitionForm contains action "Update workflow" when no transitions are available to the user Postponed

"When a user does not have any more transitions available, the block "Workflow Transition form" contain a "Update workflow" button that, when pushed, does nothing. Could it be removed?

Please follow the referenced issue.

From #2850103: Display/hide/require the Comment subfield based on state →
"I have a situation where on some states, the transition should happen with comments mandatory and on remaining states, the comment field itself should not be visible."

From 💬 Do not hide widget when having only one option RTBC

Actually a very valuable reason to have the widget is, e.g. for and application flow the button would be "Apply now" or submit which can be nicely controlled with workflow and transition lables. But not having this breaks this idea totally. I think it must always be shown.

Please follow ✨ [Meta] Display/hide/require the Widget subfields based on State/Role Active . The info is added there.

Added info from ✨ Make Comment Requirement Configurable per Transition Closed: duplicate :

[...] allowing the requirement of a comment field to be granular to transition.

Example Transition Configuration
Creation -> Draft | Not Required
Draft -> Review | Not Required
Review -> Reject | Required
Reject -> Review | Not Required
Review -> Approved | Not Required
My reasoning is that some transitions require context. [...] Anyone who is REJECTING content should also provide a comment which may include reason for rejection and needed revisions for approval. In this example users would be forced to comment on 4 other transitions just to enforce that one need. [...] I see this as adding an additional field (comment_required) to workflow_transitions table.

I am now collecting all issues for 'customizalbe comments' or 'customizable subfields'.
Please check the behaviour of current 2.1.x-dev.
IMO the commetn view is always displayed.

I guess this isue can be closed, by now.
New version 2.1 has a better set-up for your needs.

good catch.
I think it is the other way around: the captil W should be removed in the 'category' of WorkflowItem.php
see the commit. Thanks.

:-)

Using workflow 2.1.7+dev, on D11-2-dev, this is solved:
- for Gin theme, Olivero theme and Claro theme.

I guess this issue can be closed.

There was a hausse on messages liek this, but apparently it is sovled, either in workflow module, or in contrib modules, or in core.
Closing this message.

I guess this issue can be closed.
In recent Drupal versions, the logic has indeed changed to always save the complete entity, to prevent errors such as yours.

I guess this issue can be closed. Please test again in latest version, and reopen if necessary.

I guess this issue can be closed.

I guess this issue can be closed.

I guess this issue can be closed.

I guess this issue can be closed.

I guess this issue can be closed.

PHP7 is not supported anymore. I guess this issue can be closed.

Hi Denis,
Indeed, it was a long journey, but I am glad the problem is solved!
Perhaps we meet in person some day.

Kind regards,