Answers.Body: <p>As of September 2017 (4.7.25) this is now possible without any coding changes (see <a href="https://issues.civicrm.org/jira/browse/CRM-20507" rel="nofollow noreferrer">CRM-20507</a>).  Simply uncheck the "Is this Custom Data Set public?" box.</p>
  
  <p><a href="https://i.sstatic.net/5BUok.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/5BUok.png" alt="enter image description here"></a></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-02-07T02:29:52.457Z
Answers.Text: Nice one Jon - just what I was looking for!
Answers.UserDisplayName: KarinG - Semper IT
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-13T00:56:30.560Z
Answers.LastActivityDate: 2017-08-13T00:56:30.560Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.Body: <p>If you want to stop <em>all</em> custom fields appearing in receipts, you can edit the Contribution - Receipt (off-line) template directly, in 'Message Templates'. </p>
  
  <p>Remove the section starting with {if $customGroup} through to the next {/if}, and give that a try.</p>
  
  <p>If it turns out it's using the on-line receipt (I'm always getting confused as to which is used when), it's the same but with {if $customPost}.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-21T13:15:26.013Z
Answers.Text: If you don't want to turn off *all* custom fields, you may be able to check on a smarty variable. We use {if $customPost AND $contributionPageId != 25} to stop custom fields from a particular page being emailed automatically. I think you can put {debug} into your template to output the variables in the email so you can see if there are any likely candidates (http://wiki.civicrm.org/confluence/display/CRMDOC/Debugging+for+developers#Debuggingfordevelopers-EnableDebugging).
Answers.UserDisplayName: Andrew West
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-21T12:06:54.890Z
Answers.LastActivityDate: 2015-07-21T12:06:54.890Z
Answers.UserDisplayName: Andrew West
Answers.Body: <p>Access control on custom fields is at the level of custom field sets. One way to achieve what you want might be to put the fields that should be seen by donors in one custom field set and the admin-only fields in another set. Then use <a href="http://book.civicrm.org/user/version/4.1/initial-set-up/access-control" rel="nofollow">ACL</a> to restrict who can see the admin-only custom field set. Test carefully to make sure that the access control is correctly applied for receipts.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-28T00:59:15.007Z
Answers.Text: the ACLs aren't applied to offline receipts (in 4.6 at least)
Answers.UserDisplayName: Ken West
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-21T09:03:58.007Z
Answers.LastActivityDate: 2015-07-21T09:03:58.007Z
Answers.UserDisplayName: davejenx
Answers.Body: <p>Here's a patch that screens out custom fields that belong to groups that are private. This code assumes that anonymous users are not granted the 'access all custom data' permission, and ACLs are used to make custom groups public.</p>
  
  <pre><code>--- a/CRM/Event/Form/Participant.php    2015-05-20 16:30:37.000000000 +1000
  +++ b/CRM/Event/Form/Participant.php    2015-10-28 15:06:16.000000000 +1100
  @@ -1602,9 +1602,28 @@
  
         $template = CRM_Core_Smarty::singleton();
         $customGroup = array();
  +
  +      // Assume the receipt is being sent to an anonymous user. This code emulates
  +      // CRM_Core_Permission::customGroup() being called for an anonymous user, and
  +      // assumes that anonymous users are not granted the 'access all custom data'
  +      // permission. Anonymous users are only shown public custom data groups.
  +      $publicGroups = CRM_ACL_BAO_ACL::group(
  +        CRM_Core_Permission::VIEW,
  +        0,
  +        'civicrm_custom_group',
  +        CRM_Core_PseudoConstant::get(
  +            'CRM_Core_DAO_CustomField',
  +            'custom_group_id',
  +            array('fresh' =&gt; FALSE)
  +        )
  +      );
  +
         //format submitted data
         foreach ($params['custom'] as $fieldID =&gt; $values) {
           foreach ($values as $fieldValue) {
  +          if (in_array($fieldValue['custom_group_id'], $publicGroups) === FALSE) {
  +            continue;
  +          }
             $customValue = array('data' =&gt; $fieldValue['value']);
             $customFields[$fieldID]['id'] = $fieldID;
             $formattedValue = CRM_Core_BAO_CustomGroup::formatCustomValues($customValue, $customFields[$fieldID], TRUE);
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-29T16:43:22.857Z
Answers.Text: Hi Ken. I think you should submit your code as a PR to civicrm to be included. It would be a nice fix. :-)
Answers.UserDisplayName: Richard van Oosterhout
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-06T01:53:18.127Z
Answers.Text: I think my patch makes a few too many assumptions to go into Core. Essentially what is needed if for CRM_Core_Permission::customGroup() to be refactored so it can test the permissions of any contact, not just the current user. That in turn requires refactoring much of the CRM_Core_Permission class.
Answers.UserDisplayName: Ken West
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-28T04:56:52.820Z
Answers.LastActivityDate: 2015-10-28T04:56:52.820Z
Answers.UserDisplayName: Ken West
Body: <p>I have 2 set of custom fields for contributions and certain items of that are not meant for donors to see, only for admin purpose. But they are automatically included in offline receipt. How Can I remove them from the offline receipt?</p>
  
Tags: <civicontribute><email>
Title: How to remove certain items of custom fields when sending a offline receipt?
ThreadText: # How to remove certain items of custom fields when sending a offline receipt?
  
  (Asked by: username_0 on 2015-07-21)
  
  I have 2 set of custom fields for contributions and certain items of that are not meant for donors to see, only for admin purpose. But they are automatically included in offline receipt. How Can I remove them from the offline receipt?
  
  **Tags:** civicontribute, email
  
  
  ---
  
  ## 4 answers
  
  ### Answer by username_1 on 2017-08-13. Score: 2
  
  As of September 2017 (4.7.25) this is now possible without any coding changes (see [CRM-20507](https://issues.civicrm.org/jira/browse/CRM-20507)). Simply uncheck the "Is this Custom Data Set public?" box.
  
  [![enter image description here](https://i.sstatic.net/5BUok.png)](https://i.sstatic.net/5BUok.png)
  
  > **Comments:**
  > **username_2**: Nice one Jon - just what I was looking for!  
  
  ---
  
  ### Answer by username_3 on 2015-07-21. Score: 2
  
  If you want to stop *all* custom fields appearing in receipts, you can edit the Contribution - Receipt (off-line) template directly, in 'Message Templates'.
  
  Remove the section starting with {if $customGroup} through to the next {/if}, and give that a try.
  
  If it turns out it's using the on-line receipt (I'm always getting confused as to which is used when), it's the same but with {if $customPost}.
  
  > **Comments:**
  > **username_3**: If you don't want to turn off *all* custom fields, you may be able to check on a smarty variable. We use {if $customPost AND $contributionPageId != 25} to stop custom fields from a particular page being emailed automatically. I think you can put {debug} into your template to output the variables in the email so you can see if there are any likely candidates (http://wiki.civicrm.org/confluence/display/CRMDOC/Debugging+for+developers#Debuggingfordevelopers-EnableDebugging).  
  
  ---
  
  ### Answer by username_4 on 2015-07-21. Score: 0
  
  Access control on custom fields is at the level of custom field sets. One way to achieve what you want might be to put the fields that should be seen by donors in one custom field set and the admin-only fields in another set. Then use [ACL](http://book.civicrm.org/user/version/4.1/initial-set-up/access-control) to restrict who can see the admin-only custom field set. Test carefully to make sure that the access control is correctly applied for receipts.
  
  > **Comments:**
  > **username_5**: the ACLs aren't applied to offline receipts (in 4.6 at least)  
  
  ---
  
  ### Answer by username_5 on 2015-10-28. Score: 0
  
  Here's a patch that screens out custom fields that belong to groups that are private. This code assumes that anonymous users are not granted the 'access all custom data' permission, and ACLs are used to make custom groups public.
  --- a/CRM/Event/Form/Participant.php    2015-05-20 16:30:37.000000000 +1000
  +++ b/CRM/Event/Form/Participant.php    2015-10-28 15:06:16.000000000 +1100
  @@ -1602,9 +1602,28 @@
  
         $template = CRM_Core_Smarty::singleton();
         $customGroup = array();
  +
  +      // Assume the receipt is being sent to an anonymous user. This code emulates
  +      // CRM_Core_Permission::customGroup() being called for an anonymous user, and
  +      // assumes that anonymous users are not granted the 'access all custom data'
  +      // permission. Anonymous users are only shown public custom data groups.
  +      $publicGroups = CRM_ACL_BAO_ACL::group(
  +        CRM_Core_Permission::VIEW,
  +        0,
  +        'civicrm_custom_group',
  +        CRM_Core_PseudoConstant::get(
  +            'CRM_Core_DAO_CustomField',
  +            'custom_group_id',
  +            array('fresh' => FALSE)
  +        )
  +      );
  +
         //format submitted data
         foreach ($params['custom'] as $fieldID => $values) {
           foreach ($values as $fieldValue) {
  +          if (in_array($fieldValue['custom_group_id'], $publicGroups) === FALSE) {
  +            continue;
  +          }
             $customValue = array('data' => $fieldValue['value']);
             $customFields[$fieldID]['id'] = $fieldID;
             $formattedValue = CRM_Core_BAO_CustomGroup::formatCustomValues($customValue, $customFields[$fieldID], TRUE);
  
  > **Comments:**
  > **username_6**: Hi Ken. I think you should submit your code as a PR to civicrm to be included. It would be a nice fix. :-)  
  > **username_5**: I think my patch makes a few too many assumptions to go into Core. Essentially what is needed if for CRM_Core_Permission::customGroup() to be refactored so it can test the permissions of any contact, not just the current user. That in turn requires refactoring much of the CRM_Core_Permission class.  
  
  ---
  
  