Answers.Body: <p>We found a workaround solution. It seems that is a bug in <a href="https://github.com/civicrm/civicrm-core/blob/master/api/v3/Attachment.php" rel="nofollow">Attachment.php</a> API file.</p>
  
  <p><strong>Original code</strong></p>
  
  <pre><code>315: foreach ($entityFile as $key =&gt; $value) {
  316:   $select-&gt;where('cef.!field = @value', array(
  317:     '!field' =&gt; $key,
  </code></pre>
  
  <p><strong>Workaround solution</strong></p>
  
  <pre><code>315: foreach ($entityFile as $key =&gt; $value) {
  316:   $select-&gt;where('cef.!field'.$key.' = @value', array(
  317:     '!field'.$key =&gt; $key,
  </code></pre>
  
  <p>Seems that if there is more than one <code>$entityFile</code> element, then <code>where</code> clause is generated wrongly.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-30T23:12:16.023Z
Answers.Text: So [where()](https://github.com/civicrm/civicrm-core/blob/master/CRM/Utils/SQL/Select.php#L239) currently tries to dedupe redundant clauses by using `->wheres[$expr]`, and it erroneously treats two clauses ("cef.entity_table == 'foo'" and "cef.entity_id=123") as duplicates. The dedupe key should prob be post-interpolation rather than pre-interpolation.
Answers.UserDisplayName: Tim Otten
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-01T01:19:07.337Z
Answers.Text: Well, I like this patch better than the others -- it seems closer to the root cause. I've drafted a similar/alternative which I think gets at the cause https://github.com/civicrm/civicrm-core/pull/6644 . Could you see if it fixes the problem for you?
Answers.UserDisplayName: Tim Otten
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-30T21:14:28.973Z
Answers.LastActivityDate: 2015-08-30T21:14:28.973Z
Answers.UserDisplayName: Francesc Bassas i Bullich
Answers.Body: <p>I think I've found the cause. Check out bug <a href="https://issues.civicrm.org/jira/browse/CRM-16544" rel="nofollow">CRM-16544</a>, it matches your problem exactly (except theirs was Grant and yours is Event). I think we can fix this by adding <code>civicrm_event</code> to the array on line 210 of <a href="https://github.com/civicrm/civicrm-core/blob/f85b80630e8324121dcdef2d7aacd432946b541f/Civi/Core/Container.php" rel="nofollow">Container.php</a>, but I'm not familiar enough with the Symfony stuff to be sure. I think your best bet is to file a bug.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-26T17:16:32.143Z
Answers.Text: Thanks, Nicholai! It really looks like the problem we have. However, adding `civicrm_event` to the array on line 210 of [Container.php](https://github.com/civicrm/civicrm-core/blob/f85b80630e8324121dcdef2d7aacd432946b541f/Civi/Core/Container.php) seems it's not enough. We try also without luck with `civicrm_participant` and `civicrm_value_inscripci__14` that is the entity table of the custom file field in question.
Answers.UserDisplayName: Francesc Bassas i Bullich
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-15T23:06:32.810Z
Answers.LastActivityDate: 2015-08-15T23:06:32.810Z
Answers.UserDisplayName: Nicholai
Body: <p>We upgrade recently from 4.5.8 to 4.6.6 on four of our CiviCRM instances.</p>
  
  <p>In one of the instances ocurrs something very strange and compromising. When we create a new mailing, in the attachment tab appears one/two random files uploaded previously to event custom fields.</p>
  
  <p>However if we try to delete the attached file/s we get the following error:</p>
  
  <blockquote>
    <p>"Failed to run permission check: Unrecognized target entity table
    (civicrm_participant)"</p>
  </blockquote>
  
  <p>Why they appear if they have no connection with the mailings?</p>
  
  <p><strong>Edit: Screenshot</strong></p>
  
  <p><a href="https://i.sstatic.net/A1tZE.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/A1tZE.png" alt="enter image description here"></a></p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-08-06T19:23:29.233Z
Comments.Text: So we can start looking, how it is stored in the database attachments of a mailing?
Comments.UserDisplayName: Francesc Bassas i Bullich
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-08-07T15:02:08.767Z
Comments.Text: Are you selecting a template when creating the mailing? Perhaps the template is defined to include attachments?
Comments.UserDisplayName: Nicholai
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-08-07T18:40:36.917Z
Comments.Text: No, this happens even before selecting the template.
Comments.UserDisplayName: Francesc Bassas i Bullich
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-08-10T21:32:50.880Z
Comments.Text: It's difficult to understand what's happening.  Could you please include a screenshot?
Comments.UserDisplayName: Jon G - Megaphone Tech
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-08-27T10:52:46.623Z
Comments.Text: A related issue and a related bug report? http://civicrm.stackexchange.com/questions/4929/after-upgrading-to-4-6-7-civimail-fails-to-send-mail https://issues.civicrm.org/jira/browse/CRM-17085?jql=text%20~%20%22Failed%20to%20run%20permission%20check%3A%20Unrecognized%20target%20entity%20table%22
Comments.UserDisplayName: Francesc Bassas i Bullich
Tags: <civimail><issues>
Title: Why unexpected attached files are loaded in all mailings by default?
ThreadText: # Why unexpected attached files are loaded in all mailings by default?
  
  (Asked by: username_0 on 2015-08-06)
  
  We upgrade recently from 4.5.8 to 4.6.6 on four of our CiviCRM instances.
  
  In one of the instances ocurrs something very strange and compromising. When we create a new mailing, in the attachment tab appears one/two random files uploaded previously to event custom fields.
  
  However if we try to delete the attached file/s we get the following error:
  
  > "Failed to run permission check: Unrecognized target entity table
  > (civicrm\_participant)"
  
  Why they appear if they have no connection with the mailings?
  
  **Edit: Screenshot**
  
  [![enter image description here](https://i.sstatic.net/A1tZE.png)](https://i.sstatic.net/A1tZE.png)
  
  **Tags:** civimail, issues
  
  > **Comments:**
  > **username_0**: So we can start looking, how it is stored in the database attachments of a mailing?  
  > **username_1**: Are you selecting a template when creating the mailing? Perhaps the template is defined to include attachments?  
  > **username_0**: No, this happens even before selecting the template.  
  > **username_2**: It's difficult to understand what's happening.  Could you please include a screenshot?  
  > **username_0**: A related issue and a related bug report? http://civicrm.stackexchange.com/questions/4929/after-upgrading-to-4-6-7-civimail-fails-to-send-mail https://issues.civicrm.org/jira/browse/CRM-17085?jql=text%20~%20%22Failed%20to%20run%20permission%20check%3A%20Unrecognized%20target%20entity%20table%22  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2015-08-30. Score: 2 | Accepted answer
  
  We found a workaround solution. It seems that is a bug in Attachment.php API file.
  Original code
  315: foreach ($entityFile as $key => $value) {
  316:   $select->where('cef.!field = @value', array(
  317:     '!field' => $key,
  
  Workaround solution
  315: foreach ($entityFile as $key => $value) {
  316:   $select->where('cef.!field'.$key.' = @value', array(
  317:     '!field'.$key => $key,
  
  Seems that if there is more than one $entityFile element, then where clause is generated wrongly.
  
  > **Comments:**
  > **username_3**: So [where()](https://github.com/civicrm/civicrm-core/blob/master/CRM/Utils/SQL/Select.php#L239) currently tries to dedupe redundant clauses by using `->wheres[$expr]`, and it erroneously treats two clauses ("cef.entity_table == 'foo'" and "cef.entity_id=123") as duplicates. The dedupe key should prob be post-interpolation rather than pre-interpolation.  
  > **username_3**: Well, I like this patch better than the others -- it seems closer to the root cause. I've drafted a similar/alternative which I think gets at the cause https://github.com/civicrm/civicrm-core/pull/6644 . Could you see if it fixes the problem for you?  
  
  ---
  
  ### Answer by username_1 on 2015-08-15. Score: 3
  
  I think I've found the cause. Check out bug [CRM-16544](https://issues.civicrm.org/jira/browse/CRM-16544), it matches your problem exactly (except theirs was Grant and yours is Event). I think we can fix this by adding `civicrm_event` to the array on line 210 of [Container.php](https://github.com/civicrm/civicrm-core/blob/f85b80630e8324121dcdef2d7aacd432946b541f/Civi/Core/Container.php), but I'm not familiar enough with the Symfony stuff to be sure. I think your best bet is to file a bug.
  
  > **Comments:**
  > **username_0**: Thanks, username_1! It really looks like the problem we have. However, adding `civicrm_event` to the array on line 210 of [Container.php](https://github.com/civicrm/civicrm-core/blob/f85b80630e8324121dcdef2d7aacd432946b541f/Civi/Core/Container.php) seems it's not enough. We try also without luck with `civicrm_participant` and `civicrm_value_inscripci__14` that is the entity table of the custom file field in question.  
  
  ---
  
  