🇳🇱Netherlands @ecvandenberg

Found it!
This issue is causing it: https://www.drupal.org/project/role_delegation/issues/3492926 🐛 RoleDelegationRemoveRoleUser and RoleDelegationAddRoleUser access() method does not honor $return_as_object parameter Active
The patch resolves it!

@jurgenhaas sorry for this. And many many thanks for all your work on ECA.

I was not able to get it working. I changed the event to Update content entity, but that did not solve it.
Set field value for the roles is not that easy. I wouldn't know how to do that.
Up til now I just did not update the role delegation module.
I will add an issue to their queue.
Or just automate all role actions with ECA so I don't need the role delegation module anymore :-)

@vincent rommelaars, does your product variation type hold a field_btw. If not, I'm not sure how I got it there. I can't remember. But you can add a field of tax type. I guess that does the tric.

For some reason I have the combination of this module with commerce repeat order working well.
This is the config that works well:

• Drupal 10.3.10
• Commerce Core 8.x-2.40
• Commerce Simple Stock 8.x-1.2 with patch 3450194
• Commerce Repeat Order 8.x-2.2 with patch 3367273

Many months ago I had both patches installed too, but repeating an order resulted in errors.
Now it works great. I guess due to updates on other modules.

I would like to ask the maintainers to publish an updates stable version of this module.
The patch here, together with patch 3450194 make this module work well.

This one is also still open. Do hope you can look at this one too...

I do hope you can find some time to look into this issue...

I see. Thanks so far. We will debug further. I guess ECA is not always that easy...but still great!

Well...I found out it has to deal with permissions. I did as you advised, adding an Entity:Load task to load the author, but that does not change the issue.
The ECA model is executed when I as admin save a node. So the contextual user is user 1.

With role_delegation:1.3 the step of assigning the new role gives this debug info:

Unconditional Set role (Activity_1wkzu8q) from ECA noname (process_ojedgcb) for event eca.content_entity.presave.
Execute Set role (Activity_1wkzu8q) from ECA noname (process_ojedgcb) for event eca.content_entity.presave.
Access denied to Set role (Activity_1wkzu8q) from ECA noname (process_ojedgcb) for event eca.content_entity.presave: 
Finished applying process for event eca.content_entity.presave defined by ECA ID process_ojedgcb.
- user (Entity user/1/admin)

The result is that the role is not assigned.

With role_delegation:1.2 the step of assigning the new role gives this debug info:

Unconditional Set role (Activity_1wkzu8q) from ECA noname (process_ojedgcb) for event eca.content_entity.presave.
Execute Set role (Activity_1wkzu8q) from ECA noname (process_ojedgcb) for event eca.content_entity.presave.
Appliance check for event eca.content_entity.presave defined by ECA ID process_ojedgcb resulted to not apply, successors will not be executed.
- entity (Entity node/page/1/Test)
- node (Entity node/page/1/Test)
- nodeauthor (Entity user/2/test)
- user (Entity user/1/admin)
- event (DTO)
  - machine_name (string "eca.content_entity.presave")
Finished applying process for event eca.content_entity.presave defined by ECA ID process_ojedgcb.
- user (Entity user/1/admin)

Which results in the role assigned.

The complete logs are attached.

If this issue would not depend on the version of role delegation, I would not ask for so much help in the issue que. But in this case I would think my model is correct and something else is wrong. Forgive me if I'm wrong...

First of all, many thanks for your excellent support to the community Jurgen!
I started with a brief description in the hope, it would perhaps be something obvious. But apparently it is not.

Here are the steps to reproduce:

Fresh Drupal 10.3.6 install

composer require 'drupal/eca:^2.0'
composer require 'drupal/bpmn_io:^2.0'
composer require 'drupal/role_delegation:^1.3'

Enable:
BPMN.iO for ECA
ECA Base
ECA BPMN
ECA Content
ECA Core
ECA UI
ECA User
Role Delegation

Add a new ECA model.
Start event: Pre save content entity, Type:Content: Basic page
Task: Add a role to the selected user, Role:Content editor, Entity: node:author

Now create a new basic page and save it.
Check the admin roles. The role Content editor is not assigned.

Now downgrade Role Delegation:
composer require 'drupal/role_delegation:1.2'

Edit the node again and save.
The role Content editor is assigned to admin.

Yes I did :-)

{{ order_entity.your_field_name.value }}

ecvandenberg → created an issue.

After updating this module to 2.0.0 the #8 patch does not apply anymore. A fix is very welcome...

ecvandenberg → created an issue.

Usually you do not have to do anything with your Drupal website. Just have the MySQL server upgraded and your site keeps running.

But I ran into an error with some sites. The website gave a general error. In the server logs we found:
[Thu Aug 22 15:53:38.641234 2024] [error] .... Got error 'PHP message: PDOException: SQLSTATE[HY000]: General error: 1193 Unknown system variable 'tx_isolation' in /data/sites/web/...

That explained it. The MySQL transaction isolation level set in settings.php were not compatible anymore.

Exlained here:
https://www.drupal.org/docs/getting-started/system-requirements/setting-... →

Just tried MR15 too. And that also works fine. I can't judge the code, but it works well without any warnings or errors.
Drupal 10.3.1
PHP 8.2.21
Mollie 2.2.1 + Patch MR15

Thanks!

Helps me too!

Just to confirm that this patch solves the warning for me too.
Drupal 10.3.1
Webform 6.2.7
Webform Views Integration 8.x-5.2 and this patch.

Ahhhh....I'm very sorry to have disturb you.

With the migration from Drupal 9 to Drupal 10 I had moved this module to the custom modules to change some stuff. But I never managed to get it back in contrib. That just does not work. So, the contrib is updated with the patch, but the effective custom version is not.

Sorry again, have a nice weekend!

I still get this warning after applying the patch. I checked to make sure the patch was properly applied and it was.
Cleared cache multiple times.
Dupal 10.3.1
php 8.2.20
Commerce Core 8.x-2.39
Commerce Simple Stock 8.x-1.2

This issue has a solution in /project/drupal/issues/3132426 🐛 Notice: Undefined index: title in Drupal\update\ProjectSecurityRequirement Fixed

ecvandenberg → created an issue.

ecvandenberg → created an issue.

MegaChriz, you are the best!
That really makes sense. In the past I wasn't aware of this effect. And indeed I see the cardinality: 1 in the config files.
That makes me think what else might be mixed up in my sites...

Many thanks for your quick response.

ecvandenberg → created an issue.

ecvandenberg → created an issue.

Hi Manual, we use nodes with up to 600 paragraphs! Well...we are expecting 600 paragraphs. We are now around 250. It all seems to work fine, but we are experiencing issues too.
We have many users that own this type of node and can add paragraphs. Some of them experiencing that not all newly added paragraphs are stored, when saving the node. They must save after every paragraph added to be sure it's stored.

I try to get it more clear but can not reproduce yet. I bumbed into this issue, perhaps it's related.

Patch #14 seems to work fine here with multiple access modules and a complex structure of access rights and workflows.

Yes, that looks much better :-)

Thanks for this nice module and getting it Drupal 10 compatible!

ecvandenberg → created an issue.

Thanks Kobe! The patch applies cleanly to the 3.0.0-alpha1 version. Still on a Drupal 9 site.

And the breakpoints work very well. Nice!

Now let's see if all works fine after upgrade to Drupal 10...

Patch #19 applies to dev.

I use this function now for some time and it works great. Preparing for migration to D10 and this patch seems to still do the trick with the latest search_api_location dev version. Can not use the alpha version due to issue 3048597.

I could use this too. If you let me know when you have a first patch I'm happy to test it.

You are lightning fast!

One problem...I think the other (related) patch is also required. But they can not apply on top of each other.

Thank you very much!

It seems to work fine over here.
Although I got this error:
https://www.drupal.org/project/commerce/issues/3304747 🐛 RuntimeException: Failed to start the session because headers have already been sent by Response.php Active
Not sure if this has anything to do with Mollie though...

Are you able to create a patch file?

ecvandenberg → created an issue.

For those who look for this solution, I have tried the function in #17 but that didn't work. Now, I'm not a good module developer, but with some help from the chatbot I came to this module. It also adds a permission setting View all media.

my_module.module:

use Drupal\views\ViewExecutable;
use Drupal\views\Plugin\views\query\Sql;

/**
 * Implements hook_views_query_alter().
 */

function my_module_views_query_alter(ViewExecutable $view, Sql $query) {
  if ($view->id() == 'media_library') {
    $user = \Drupal::currentUser();
    $user_roles = $user->getRoles();

    // Check if the user has "View all media" permission.
    if (in_array('administrator', $user_roles) || $user->hasPermission('View all media')) {
      return;
    }

    $query->addWhereExpression('AND', 'media_field_data.uid = :current_user_id', [':current_user_id' => $user->id()]);
  }
}

And my_module.permissions.yml:

View all media:
  title: 'View all media'
  description: 'View all media in the media library widget'

ecvandenberg → created an issue.

ecvandenberg → created an issue.

ecvandenberg → created an issue.

ecvandenberg → created an issue.

I tried the patch in a Drupal 9.5.10 site with autologout 8.1.4 and php 8.1.21.
The warnings are gone.

ecvandenberg → created an issue.

ecvandenberg → created an issue.

And thank you for a quick fix!
It works in a fresh D10 website, but with some remarks.
When you add or remove a node type at /admin/config/system/reference-access it immediately has effect to the user trying to get access. I simulate this by having a private browser window with the dedicated user logged in and trying to access the restricted node.
But when you change the specific nodes the user should have access to, that does not has effect before clearing all cache.

In an older D9.5.10 it works partly. Add or remove a node type at /admin/config/system/reference-access it immediately has effect.
But adding a specific nodes to a user does not have any effect. The access stays forbidden.

I do not see any errors in the CMS log. If you have any hints in how I could debug this better please let me know.
This site used to have other access modules like access by term. But these are all uninstalled now.

ecvandenberg → created an issue.

Patch #9 works for me on Drupal 9.5.9 and Textfield Counter 2.1.0

I now have four patches on this module. Do hope we get a stable version with all R&TBC patches in it...

ecvandenberg → created an issue.

I tried to install the latest dev. Altough I do not understand #75 fully I think I run into the same issue.
Downloading the latest dev with drush does not work.

$ drush dl search_api-7.x-1.x-dev
copy(): Filename cannot be empty drush.inc:768                                                           [warning]
Unable to download search_api to  from .    

PHP 7.4.33, Core 9.5.3, Webform 6.1.4, Entity print 8.x-2.11
with patch #2 works for me.

ecvandenberg → created an issue.