Answers.Body: <p>The field apparently was added to CiviCRM in version 1.1 <a href="https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Contact/GroupContact.xml#L106" rel="nofollow noreferrer">https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Contact/GroupContact.xml#L106</a> so it is very possible it is no longer used. You can use the svn repo at <a href="https://github.com/civicrm/civicrm-svn" rel="nofollow noreferrer">https://github.com/civicrm/civicrm-svn</a> to do more investigation if you want of the code references as well as confirm when it was added to the schema - the comment seems odd on the line cited above.</p>
  <p>If you can't find the field in the curren codebase, then, yes, it might be cruft that could be used for something else, but best practice would be to remove it.</p>
  <p>I would be cautious when searching the codebase for references since fields are often not prefaced by a table in PHP code, and sometimes fields are implicitly referenced as a group. Probably grep'ing email_id would be a tedious but good place to start.</p>
  <p>Putting up a PR to remove it would be useful in the normal course of finding an unused field.</p>
  <p>I discourage repurposing of core fields for alternative purposes. It is safer if you are going to create a custom extension to handle emails for groups in other ways to just create a new my_email_id field. That way your extension won't get battered by a cruft cleanup of core down the road, or leave you asking core maintainers to not merge the cleanup because of your extension's use.</p>
  <p>In general I think it would be good to make it more feasible to use different location types for cases where it defaults to primary email. If you need support to facilitate this by refactoring a core file, eg to add a hook, please ping me.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-12-15T01:48:26.447Z
Answers.LastActivityDate: 2022-12-15T01:48:26.447Z
Answers.UserDisplayName: Joe Murray
Body: <p>See also <a href="https://lab.civicrm.org/dev/core/-/issues/4032" rel="nofollow noreferrer">https://lab.civicrm.org/dev/core/-/issues/4032</a></p>
  <h1>Overview</h1>
  <p>I'm currently working with an organisation who are moving to CiviCRM. They have contacts, who frequently have multiple employers, typically with a work email address for each employment. When signing up to email groups, it's often useful for these contacts to be able to control which group subscription goes to which email address.</p>
  <p>For example:</p>
  <p>We have a contact, Bob. Bob is employed by CompanyA and CompanyB, and has the email addresses bob@company-a.com and bob@company-b.com. bob@company-a.com is the primary email address.</p>
  <p>Bob signs up for two three mailing lists, but wants two to go to his primary email address and one to go to his secondary email address.</p>
  <h1>Current behaviour</h1>
  <p>This isn't something which is possible through the current CiviCRM UI, which is fine (I can't imagine this use-case is that common).</p>
  <p>However, looking at the database table civicrm_group_contact it has a field email_id, with the comment Optional email to associate with this membership. This field is exposed in the CiviCRM API and SearchKit.</p>
  <p>As far as I can tell, it appears that this email_id field is not actually used by any logic within CiviCRM core. It seems to be at least 10 years old (dating back to the pre-Git days), and so it's possible the email_id was introduced as part of a feature that was never finished.</p>
  <h1>Expected behaviour</h1>
  <p>I had assumed that when email_id was set, this email address would be used as the email address to actually be emailed, when sending a bulk mailing to a group via the CiviMail component. This unfortunately does not seem to be the case.</p>
  <p>Currently it is possible to set the &quot;Location Type&quot; and &quot;Selection Method&quot; when selecting a group as part of the new mailing form. If a location type is set I would expect it to take precedence over the configured email_id (although this detail could be debated
  either way).</p>
  <p>Whilst it might be nice if there was an associated UI to select the email address, I don't think any UI changes are required to make the email_id field useful - if CiviCRM simply uses the value (as set via plugin code or the API) that would be enough to enable the use case detailed above.</p>
  <h1>Comments</h1>
  <p>It's possible that I'm completely misunderstanding what the email_id field is for, and it is actually used - if so I'd love to know the details from someone closer to this area of the core code!</p>
  <p>So I guess my question are:</p>
  <ol>
  <li>Has anyone else come across a requirement like this, and how did you get around it?</li>
  <li>Does anybody know the history of the email_id field in the civicrm_group_contact table?</li>
  <li>Is there an alternative solution which I'm missing?</li>
  </ol>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-12-13T18:08:25.173Z
Comments.Text: I just checked a couple of sites that have been in use for years and saw no data in that field. Doesn't answer your question but maybe increases your confidence of this field being unused
Comments.UserDisplayName: petednz - fuzion
Tags: <core><civigroup>
Title: How is email_id field on civicrm_group_contact table used?
ThreadText: # How is email_id field on civicrm_group_contact table used?
  
  (Asked by: username_0 on 2022-12-13)
  
  See also <https://lab.civicrm.org/dev/core/-/issues/4032>
  
  # Overview
  
  I'm currently working with an organisation who are moving to CiviCRM. They have contacts, who frequently have multiple employers, typically with a work email address for each employment. When signing up to email groups, it's often useful for these contacts to be able to control which group subscription goes to which email address.
  
  For example:
  
  We have a contact, Bob. Bob is employed by CompanyA and CompanyB, and has the email addresses bob@company-a.com and bob@company-b.com. bob@company-a.com is the primary email address.
  
  Bob signs up for two three mailing lists, but wants two to go to his primary email address and one to go to his secondary email address.
  
  # Current behaviour
  
  This isn't something which is possible through the current CiviCRM UI, which is fine (I can't imagine this use-case is that common).
  
  However, looking at the database table civicrm\_group\_contact it has a field email\_id, with the comment Optional email to associate with this membership. This field is exposed in the CiviCRM API and SearchKit.
  
  As far as I can tell, it appears that this email\_id field is not actually used by any logic within CiviCRM core. It seems to be at least 10 years old (dating back to the pre-Git days), and so it's possible the email\_id was introduced as part of a feature that was never finished.
  
  # Expected behaviour
  
  I had assumed that when email\_id was set, this email address would be used as the email address to actually be emailed, when sending a bulk mailing to a group via the CiviMail component. This unfortunately does not seem to be the case.
  
  Currently it is possible to set the "Location Type" and "Selection Method" when selecting a group as part of the new mailing form. If a location type is set I would expect it to take precedence over the configured email\_id (although this detail could be debated
  either way).
  
  Whilst it might be nice if there was an associated UI to select the email address, I don't think any UI changes are required to make the email\_id field useful - if CiviCRM simply uses the value (as set via plugin code or the API) that would be enough to enable the use case detailed above.
  
  # Comments
  
  It's possible that I'm completely misunderstanding what the email\_id field is for, and it is actually used - if so I'd love to know the details from someone closer to this area of the core code!
  
  So I guess my question are:
  
  1. Has anyone else come across a requirement like this, and how did you get around it?
  2. Does anybody know the history of the email\_id field in the civicrm\_group\_contact table?
  3. Is there an alternative solution which I'm missing?
  
  **Tags:** core, civigroup
  
  > **Comments:**
  > **username_1**: I just checked a couple of sites that have been in use for years and saw no data in that field. Doesn't answer your question but maybe increases your confidence of this field being unused  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2022-12-15. Score: 1
  
  The field apparently was added to CiviCRM in version 1.1 <https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Contact/GroupContact.xml#L106> so it is very possible it is no longer used. You can use the svn repo at <https://github.com/civicrm/civicrm-svn> to do more investigation if you want of the code references as well as confirm when it was added to the schema - the comment seems odd on the line cited above.
  
  If you can't find the field in the curren codebase, then, yes, it might be cruft that could be used for something else, but best practice would be to remove it.
  
  I would be cautious when searching the codebase for references since fields are often not prefaced by a table in PHP code, and sometimes fields are implicitly referenced as a group. Probably grep'ing email\_id would be a tedious but good place to start.
  
  Putting up a PR to remove it would be useful in the normal course of finding an unused field.
  
  I discourage repurposing of core fields for alternative purposes. It is safer if you are going to create a custom extension to handle emails for groups in other ways to just create a new my\_email\_id field. That way your extension won't get battered by a cruft cleanup of core down the road, or leave you asking core maintainers to not merge the cleanup because of your extension's use.
  
  In general I think it would be good to make it more feasible to use different location types for cases where it defaults to primary email. If you need support to facilitate this by refactoring a core file, eg to add a hook, please ping me.
  
  
  ---
  
  