🇳🇱Netherlands @johnv

Vesion 2.1.5 is now released. Also a dev branch 2.1.x

Version 2.1.5 is now released. Happy testing and using!

johnv → created an issue.

johnv → created an issue.

This commit moves code better to the abstract class and fixes some issues in VBO views.

@golubovicm, is your problem solved, too?

Nice,
ITMT, I managed to create a 2.1.x version, which is now the actual one.
Working on 1 issue, then will create a new version. Will keep you posted, and leave tis open as a reminder until then.

Please use https://www.drupal.org/project/workflow/releases/2.1.x-dev →

I am only working on Actions, now. Do you use them?

Are you using an Action, by any chance?

johnv → created an issue.

The above patch filters the 'roles', so that no values '0' are saved (for unselected roles - which causes mentioned error)
Also, the 'days_to_trigger' validation is moved (together with above roles) to the WorkflowAbstractcNotification::save() function, so that it is checked upon save, whatever the source.

johnv → created an issue.

The last error is fixed by comparing other core Actions: https://git.drupalcode.org/project/workflow/-/commit/d2fd588b5104ea6ae6e...

There must be an update not executed.

what does the following report say: /drupal/admin/reports/status#error

please apply the patch and see what happens.

johnv → created an issue.

Please use 2.0.x dev version.
Or New 2.1.x branche.
The 2.1.4 version does not contain this fix, yet.

In the mean time, thisis added to the code base.
Thanks all

Pff,
first some complaints.
- Drupal form handling is way too difficult, and uses too many conventions (null vs NULL, '?TYPE' vs. '|null', etc.
- Why does ECA module load and perform all those configuration form upfront??
- Why does Gin theme mess around with existing forms?

But then the bright side:
- this issue reveals a regression error where the 'action buttons' are no longer suppressed in the Workflow Action configuration form.
- this issue forced me to make a step further: until now, for adding the WorkflowTransition form element, I called a complete form. Now, I still do not the ideal situation (calling a proper widget), but call only the form element building thing, without loading the complete form surroundings.
(In v1.7, many code was coded and executed twice)

This may lead me to remove more duplicate code in the future.

Thanks,
Please test 2.0.x and report back.

Adding the above 🐛 Latest Gin admin theme button in "more actions" dropdown Active to related issues.

Made better readable links in OP, using [ # <number> ] format.

Thanks Daniel,
Your screendumps reveal the key issue. You are using the Gin theme, or a subtheme.

That does a strange thing with Form buttons.

Also, i think you have 'action buttons' specified in one or all of your workflows.

Please confirm both assumptions.

Now I can reproduce the error.

Perhaps the following must be reviewed in this context: ✨ Support Gin action item Active

johnv → created an issue.

On the other hand, I think you know better where the beef is.
Leaving it up to you to add a patch with only the translation part.
Also, perhaps 🐛 Error upon Translate Workflow Notification message Active is related.

Please give a test script how to reproduce ther problem.

This was a comment of mine from years ago.
There is no benefit now to change this.
Removing the @todo comment.

Thanks,
I have a hard time to understand and test the patch at this moment. So will do some other moment.

Issue contains a patch.

Indeed, the following issue seems to do the same, and has a patch: #3043773: Send mail if no change happened after some days →

I guess this is still valid for 3.0.x version.

The attached patch does not only check if the state changes, but also for other (attached) fields in the $transition.
I think it is up to the custom project to for instance fill such a attached field if a node field is changed.

Thanks. committed. But there are more occasions left.

I am not sure, but I think the current 3.0.x code already contains an id. Please check and re-open if this is not as desired.

As a co-maintainer, I just now encounter your extensive patch.
Thanks a lot.
As it happens, I just finished the re-factoring of the module myself, by extending the separate WorkflowNotification and WorkflowSmsNotify Classes, and create a WorkflowAbstractNotification parent classe for all common code.

Regarding your translation functionality, I will try to deduct from the MR.

Do you have some code examples?
At the moment, version 3.0 gives messages on the screen and also in page /admin/reports/dblog

Hi, It has been a long time!
I added many changed to the 3.0.x code base in [#i3534202] and issues from the same date.
Can you check and create a new version?
ITMT I will go through the issue queue.

I guess this can be closed.

I guess this is outdated. if the problem still persists please reopen the issue.

ANd if the problem persists, please give details testscript. How is the 'transition' programmed?

Please try with newest versions of Workflow 2.1 and WorkflowNotification 3.0.x

Thisis fixed in the mean time in v3.0.x. Thanks.
WorkflowNotification::loadMultipleByProperties() now always returns an array.

Indeed, the hook_entity_insert() was missing in both submodules.
Fixed in 3.0.x

This was because of a fault commit in Workflow module.

This is now fixed in the current v3 version.

I guess this old ticket can be closed.
The current v3 code does check for a 'state change'.

In the current dev version, this does not happen anymore, since the function WorkflowNotification::loadByProperties() now always returns an array, even when nothing is found.

the module files are now stripped as much as I can.
Some functions are remaining, because I cannot test them, or cannot be moved into a Notification object, due to the calling context.

johnv → created an issue.

There are still some issues left in the phpcs, phpstan checks, but I leave that for the original developer team.

The create() function as in your code works as expected in my system. I released v2. 1.4, but that should not make a difference.

The WID should be deducted from the SID.
Does the entity have that field name?
Do you have multiple workflows per entity?
Can you debug the function?

@golubovicm, easel share you use case.
It seems you are using the action, but Op is not about using the actions. Only having them causes the problem.

johnv → created an issue.

johnv → created an issue.

I now see thisis possible with gitlab:
- https://lostcarpark.com/drupal/future-proofing-your-module-and-dependenc...
But it requires phpunit tests for full code coverage, and that is missing in my modules.

(Very late comment)
I use the version as follows: It is the version in which the problem appears last. The following release is the release that contains the fix.
Please use 2.1.x

johnv → created an issue.

The commits adds compatibility to D11.2 and W2.1.
It also contains general code style improvements, and some cosmetic changes.

johnv → created an issue.

This issue has been bugging me for years.
I now have decided to change the error message in WorkflowConfigTransitionRoleForm.php
from 'Please give the author permission to go from %creation to at least one state!'
to 'At least one role must have permission to go from %creation to another state.'

The patch also unifies the usasge of 'Author' vs 'author'.

Please try again with version 2.0.x-dev and both report back.

The warning is now removed and replaced by a switchable field description.
Also, a NULL was passed to Twig, where only (empty) strings are allowed.

Please find attached a new version, after also having tested the 'WorkflowFieldValue' condition.

Some remarks:
- The 'WorkflowHasField' condition is not tested yet.
- The buildConfigurationForm from the Event is removed. IMO events have no configuration
- The buildConfigurationForm from the Condition - I do not understand how the UI gets its values. The code has no default values, but the UI has.
- There are some @todo's.

Sorry for not using MR.

I am now upgrading and testing the Workflow ECA → module in 📌 Adapt to upcoming 1.9 release of Workflow Active .
Are you using that submodule, too?

With current Workflow DEV version and the patch, I can save and execute an ECA event + action.
Still working on the Condition - the Workflow ECA module must be .

The new message 'You have multiple' is intentional, but never used in this context.

Sorry to hear that the Actions problem is not solved. It should have been solved in workflow_update_8008(). I presume you did proper update.php. Can you re-run workflow_update_8008() again?

Please find attached a new version, after testing an Event + Action.
I did not find a way to test a Condition, though.

This is a problem when using ECA v2.
In several cases, ECA adds, then removed a referenced interface definition.

This is fixed in the more generic 📌 Adapt to upcoming 1.9 release of Workflow Active

Compatibility with ECA v2 is handled here: 📌 Adapt to upcoming 1.9 release of Workflow Active

Attached patch is updated for ECA v2.1.8 and Workflow v2.1.

It also contains resolved incompatibilities between ECA v1 and ECA v2.
I did not truly test a 'model'.

I took the liberty to:
- not make dependent on D11, but D11.2, since that is my dev environment
- not make dependent on Workflow version 1.8 (which is obsolete), 1.9 (which does not exist), 2.0 (which has had a short lifetime), but 2.1 (of which 2.1.2 is current version)

It contains also 2 @todo's, where my IDE tells me there is a problem, I cannot fix myself.

In the past, one could test against different version of PHP.
The new system does not support that, I believe.

When developing, I work in 1 version, so, indeed, sometimes a PHP8.3 feature was built in, innocently.
Now, I have several issues for this and other module that should be postponed, until 8.1 and 8.2 are not supported anymore.

If you have any tests failing, I am happy to revert some code.
Please create an issue in that case.

Let us forget this, and better focus on 🐛 Fix field cache for anonymous users by implementing LazyBuilder Active

johnv → created an issue.

OK, I understand, this is not consequent.
What if:
- when "Title for exceptions section" is empty, the title is not displayed
- then also no title for 'normal hours'
- adding a little help text to the setting.

(Might even be called a bug)

Some debugging is needed.

IMO this happens because of the change(s) between WorkflowTransition::baseField['to_sid'] and ['from_sid'] being a list_string or an entity_reference.

I guess this still happens when you switch from 'action buttons' to 'select list'?

Can you determine what is being saved?
- the node/entity, or
- the WorkflowTransition

In WorkflowTransition::save(), or its more generic parent EntityBase::save() in one of the first lines, you should find the 'target_id'. Unset that, and see what happens.

Still valid.

johnv → created an issue.

This was a misunderstanding. let us close this.