Preconfigured task to assign a role not working

I don't know either since the provided information is extremely minimal. Not sure what "not working" actually means. Not sure which preconfigured action is being used. Not sure what role delegation would have to do with this.

So, it's necessary to provide a detailed description of what's not working and how to reproduce that.

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.

Hm, that sounds as if something in the role_delegation module has changed. Is there anything in the logs for when it doesn't work? If not, you may want to compare the code between their 2 versions to see if anything has changed that could interfere.

I've just looked and there is this issue 🐛 TypeError: Drupal\role_delegation\Access\RoleDelegationAccessCheck::access(): Argument #1 ($account) must be of type Drupal\Core\Session\AccountInterface, null given Fixed which is part of version 1.3

Now, that leads me to comment on your model:

Task: Add a role to the selected user, Role:Content editor, Entity: node:author

The field Entity requires the name of a token, not a token. I know, that sounds strange. But maybe reading the chapter about Tokens in ECA may help here. So, you may have to load the author into a token first and then use that token name in that field.

If none of that resolves the issue, you may have to debug the model, see https://ecaguide.org/eca/debugging/

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...

The difference comes from an update of a module, that is not related to ECA or the task which is being performed here. So, it's probably the wrong queue to ask here since I don't have the time to analyse that other module role_delegation and how it impacts the process.

But what I can tell is that the combination of the event "Presave content entity" and "Add a role to the selected user" will never work reliably because the latter is saving the entity which is in a presave state. That should almost always lead to an exception.

That action "Add a role to the selected user" can only be used with the "Update content entity" event, but then this leads to a second save process of the same entity. Not ideal either.

Instead, you could use the Set field value action and append a role to the roles field of the user without saving it as the presave event will be followed by a save operation already.

If the role_delegation module still causes an issue then, this would need to be analysed with xdebug and/or the maintainers of that module.

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

What's the status on this?

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 :-)

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.

This is great, thanks for your feedback and the link to the related issue.

Automatically closed - issue fixed for 2 weeks with no activity.