Loop using VIEWS: EXECUTE QUERY

Created on 14 March 2023, over 1 year ago
Updated 15 March 2023, over 1 year ago

Problem/Motivation

I am trying to loop each element of a list created with ECA VIEWS: EXECUTE QUERY. For each item I need to send an email with information about the item.

The problem: I cannot manage to make the loop. In the ECA guide page there is a tutorial to make a loop https://ecaguide.org/resources/tutorials/btown-1/?h=loop. But this loop is based on user content properties (taxonomy). However I want to make a loop based on a list obtained with ECA VIEWS: EXECUTE QUERY.

Proposed resolution

I am currently launching a Cron event, then I get my list with ECA VIEWS: EXECUTE QUERY. But from this point I have no ideas how to continue.

Remaining tasks

In the tutorial I see that they use TRIGGER A CUSTOM EVENT (ENTITY-AWARE) and ECA CUSTOM EVENT (ENTITY-AWARE). But I can't find the way how to make the loop from the list obtained with VIEWS: EXECUTE QUERY.

πŸ’¬ Support request
Status

Fixed

Version

1.1

Component

Documentation

Created by

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • 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 over 1 year ago
  • πŸ‡«πŸ‡·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 results

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

Production build 0.69.0 2024