Answers.Body: <p>First, you'll want to check if what is being saved is a draft or revision, and if so, ignore it for your purposes. You can check via:</p>
  
  <pre class="lang-php prettyprint-override"><code>use craft\helpers\ElementHelper;
  
  
  if (!ElementHelper::isDraftOrRevision($element)) {
  }
  
  </code></pre>
  
  <p>Next if you want to avoid doing anything during "bulk saving events", on Craft 3.1.22 or later there is:</p>
  
  <pre class="lang-php prettyprint-override"><code>if (!$element-&gt;resaving) {
  }
  
  </code></pre>
  
  <p>...which was added in <a href="https://github.com/craftcms/cms/blob/develop/CHANGELOG-v3.md#added-18" rel="nofollow noreferrer">Craft CMS 3.1.22</a></p>
  
  <p>Some additional discussion that might be useful: <a href="https://github.com/craftcms/cms/issues/3482" rel="nofollow noreferrer">Improve behaviour for automatic resaving of entries when saving an entry type</a></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-08-29T15:12:14.520Z
Answers.LastActivityDate: 2019-08-29T15:12:14.520Z
Answers.UserDisplayName: andrew.welch
Body: <p>We need to send notification emails when entries of a particular type are created, updated, or enabled/disabled. The entrypoint for this happens in a module's <code>init()</code> method:</p>
  
  <pre><code>Event::on(Elements::class, Elements::EVENT_AFTER_SAVE_ELEMENT, function (Event $event) {
      // do stuff
  }
  </code></pre>
  
  <p>We recently updated to Craft 3.3.0, which resulted in many many many emails being sent. I think these have something to do with queue tasks that are generated as a result of system updates. During the update, the <code>craft_queue</code> table contains many rows. The first row's <code>description</code> is "Updating entry drafts and revisions" and the many subsequent rows show a <code>description</code> value of "Updating element slugs and URIs".</p>
  
  <p>First, is it correct to assume that some system updates trigger queued resaves of all entries?</p>
  
  <p>Second, we need to prevent the notification emails from being sent unless the save event is triggered as the result of a user action. I see the <code>sender</code> property of <code>ElementEvent</code>, but it seems that that has to do with the current method and doesn't bubble up the event chain. </p>
  
  <p>We've thought about disabling versions on these entries, but that feels more like a bandaid. </p>
  
  <p>Is there a way to determine the originating source of an ElementEvent's save event? If so, is that the best way to gain more control over when these notification emails are sent? In general, I'm wondering if we can detect whether an element is being saved as the result of a system update/queue task vs a manual user action.</p>
  
Tags: <events><updates>
Title: How to determine source of Elements save event
ThreadText: # How to determine source of Elements save event
  
  (Asked by: username_0 on 2019-08-29)
  
  We need to send notification emails when entries of a particular type are created, updated, or enabled/disabled. The entrypoint for this happens in a module's `init()` method:
  
  ```
  Event::on(Elements::class, Elements::EVENT_AFTER_SAVE_ELEMENT, function (Event $event) {
      // do stuff
  }
  
  ```
  
  We recently updated to Craft 3.3.0, which resulted in many many many emails being sent. I think these have something to do with queue tasks that are generated as a result of system updates. During the update, the `craft_queue` table contains many rows. The first row's `description` is "Updating entry drafts and revisions" and the many subsequent rows show a `description` value of "Updating element slugs and URIs".
  
  First, is it correct to assume that some system updates trigger queued resaves of all entries?
  
  Second, we need to prevent the notification emails from being sent unless the save event is triggered as the result of a user action. I see the `sender` property of `ElementEvent`, but it seems that that has to do with the current method and doesn't bubble up the event chain.
  
  We've thought about disabling versions on these entries, but that feels more like a bandaid.
  
  Is there a way to determine the originating source of an ElementEvent's save event? If so, is that the best way to gain more control over when these notification emails are sent? In general, I'm wondering if we can detect whether an element is being saved as the result of a system update/queue task vs a manual user action.
  
  **Tags:** events, updates
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-08-29. Score: 3 | Accepted answer
  
  First, you'll want to check if what is being saved is a draft or revision, and if so, ignore it for your purposes. You can check via:
  
  ```php
  use craft\helpers\ElementHelper;
  
  if (!ElementHelper::isDraftOrRevision($element)) {
  }
  
  ```
  
  Next if you want to avoid doing anything during "bulk saving events", on Craft 3.1.22 or later there is:
  
  ```php
  if (!$element->resaving) {
  }
  
  ```
  
  ...which was added in [Craft CMS 3.1.22](https://github.com/craftcms/cms/blob/develop/CHANGELOG-v3.md#added-18)
  
  Some additional discussion that might be useful: [Improve behaviour for automatic resaving of entries when saving an entry type](https://github.com/craftcms/cms/issues/3482)
  
  
  ---
  
  