How is email_id field on civicrm_group_contact table used?

Question

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 [email protected] and [email protected]. [email protected] 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?

Answer 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.