- Issue created by @villavicar
- π«π·France PhilY πͺπΊπ«π· Paris, France
Check https://ecaguide.org/library/test%20models/views/ which seems close to your needs.
Perfect!, @PhilY With your help I have managed to solve the problem.
It seems that the fundamental piece of is USER: SWITCH CURRENT ACCOUNT.
I just put this functionality right after the cron event and before the logic, and everything went great.
- Status changed to Fixed
almost 2 years ago 9:51pm 14 March 2023 - π«π·France PhilY πͺπΊπ«π· Paris, France
Another way is to loop through the view's results.
See https://ecaguide.org/library/use%20case/eca_feature_demo/ at "Load all admin users" task of the "User register" event.
And yes, lots of tasks require to "Switch user" before them. - π©πͺGermany jurgenhaas Gottmadingen
Issuing credit to both of you.
Just an additional note on permissions and security. We've taken a defensive approach by keeping ECA's capabilities on the permission level of the current user by default. That way, an ECA model won't accidentally expose information to users who shouldn't see that.
For sites, where this is a problem, and you hate to switch user account each and every time, you can go into ECA's settings and configure a user which will always been used instead of the current user. This may save you time when building ECA models, but beware of the risc factors.
- π«π·France PhilY πͺπΊπ«π· Paris, France
@jurgenhaas: security first! so I feel it better adding a 'switch user' task as a reminder (btw, it'll be nice to give it a color or a tiny icon in a corner as a warning ;-)
And it might be more versatile when exporting/importing tasks: they do not depend on the ECA's settings user then.As a side note, is there any issue regarding both methods of handling view's results:
comment #2: trigger a custom event
comment #5: loop through the view's results - π©πͺGermany jurgenhaas Gottmadingen
As a side note, is there any issue regarding both methods of handling view's results:
comment #2: trigger a custom event
comment #5: loop through the view's resultsIt depends a lot on your context and the structure how you organize your models.
Triggering a custom event is like an encapsulated sub-process with all used variables having a local scope. You can also keep such sub-processes in separate ECA models and re-use them from many different places or maybe even on multiple Drupal sites.
Looping through a list of items (e.g. view results) in-place is equally valid if the loop is only required once and if you have all the variables (a.k.a. tokens) under control and no issue to unintentionally override them.
Automatically closed - issue fixed for 2 weeks with no activity.