ECA: Cron Event - View - Message per Mail

That sounds like a permission issue. If your cron job is run via drush or other means, which is not the automated_cron module from Drupal core, than the process runs as the anonymous user. And that user most likely has no permission to query the view. You may have to use the User: switch current account action right after the event.

Hallo Jürgen ;)

First of all, thank you very much for your quick response. I have now made the UserSwitch after the cron event of Eca and then I check the view to send out the mail. I will now test this overnight to see if it works as desired.

But in any case, I have already correctly surmised that the core cron is different from the ECA cron event. So it probably doesn't matter when they run separately. Only always at the same time is probably unfavourable? Or do the two have any other influence on each other and is there anything else I need to be aware of?

Thanks for the help

ECA Export:

uuid: 854bec77-51a2-4a86-bf06-07508024432b
langcode: en
status: true
dependencies:
  config:
    - field.field.node.agent_anlegen.body
    - field.field.node.article.body
    - field.field.node.bonus_anlegen.body
    - field.field.node.grund_anlegen.body
    - field.field.node.page.body
    - field.field.node.paragraphs_ief_example.body
    - field.storage.node.body
    - views.view.erinnerungsmodul_ansicht_einen_monat
  module:
    - eca_base
    - eca_render
    - eca_user
id: process_tcsl0rh
modeller: bpmn_io
label: 'Erinnerungsmodul grafisch'
version: ''
weight: -10
events:
  Event_08nnbjr:
    plugin: 'eca_base:eca_cron'
    label: Cron
    configuration:
      frequency: '0 */1 * * *'
    successors:
      -
        id: Activity_1yzoqbg
        condition: ''
conditions: {  }
gateways: {  }
actions:
  Activity_0qsiv4k:
    plugin: 'eca_render_views:views'
    label: 'Views ausgeben'
    configuration:
      view_id: erinnerungsmodul_ansicht_einen_monat
      display_id: default
      arguments: ''
      name: ''
      token_name: viewergebnis
      weight: ''
      mode: append
    successors:
      -
        id: Activity_00bl874
        condition: ''
  Activity_00bl874:
    plugin: action_send_email_action
    label: 'Mail verschicken'
    configuration:
      recipient: landwehr@system-labor.de
      subject: 'Ich bin die Testnachricht'
      message: |-
        Ich bin die Testnachricht:

        [node:title]
        [user:account-name]
        [user:display-name] 
        [comment:body] 
        -----------------------------------
        [viewergebnis]
      replace_tokens: true
    successors: {  }
  Activity_1yzoqbg:
    plugin: eca_switch_account
    label: 'set user permissions'
    configuration:
      user_id: '1'
    successors:
      -
        id: Activity_0qsiv4k
        condition: ''

But in any case, I have already correctly surmised that the core cron is different from the ECA cron event. So it probably doesn't matter when they run separately. Only always at the same time is probably unfavourable? Or do the two have any other influence on each other and is there anything else I need to be aware of?

That's not how it works. Core provides a cron API, and all modules can tell core "Hey, I have something to do when cron runs". And that's what ECA does, just exactly like all the other modules as well who implement a cron worker.

If you wanted to have more fine grained control over which cron tasks run at what time, then there are contrib modules that allow you to configure that. But that has nothing to do with ECA.

Okay, I see, thank you. The cron frequency settings in eca_base:eca_cron must have confused me a bit. So in any case ECA sends its request to the cron api and the Drupal cron actually executes it first. Ideally, both should run one after the other. Have I understood correctly now?

Now I'll see if it works as intended.

Thank you

It's the other way round. Core cron is the only process running. And core is asking all modules if they have anything to process. So, eca responds yes, just like alle other modules. It then verifies if any of the cron events in all your models are due for execution. If so, they get processed, otherwise skipped.

The starting point is always cron from core. And it's up to you how frequently that cron executes. It's strongly recommended to turn the automated cron module off and run "drush cron" from a crontab on the os level.