Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: specify email(s) from contact record to use for sync #5

Open
ufundo opened this issue Jul 16, 2020 · 4 comments
Open

Feature: specify email(s) from contact record to use for sync #5

ufundo opened this issue Jul 16, 2020 · 4 comments
Labels
documentation Improvements or additions to documentation enhancement New feature or request

Comments

@ufundo
Copy link
Contributor

ufundo commented Jul 16, 2020

Hi,

We have issues where contacts have one email they use day-to-day as their primary email, and a secondary email registered for Google Account. We would like to keep their main email for their primary email for CiviCRM, whilst syncing their "Google" email to GoogleGroups for access control to Google Groups Web UI etc.

I see this working similar to the "bulk email" checkbox feature for CiviMail.

Considerations:
In some cases you might want to sync both addresses to the GG: the primary for receiving emails from the GG and the Google Account for access control. The "bulk email" model as above would work for this.

Sometimes you can tell an email would be good to sync to GG because it is a @gmail address, but with GSuite accounts they may have a custom domain. Could be cool to have some some automatic selection logic on the basis of spotting @gmail accounts though?

@ufundo
Copy link
Contributor Author

ufundo commented Jul 16, 2020

Sorry, I am now seeing the code is there to prefer an address with location type of "Google"!

This goes a long way to solving the issue, which is great.

I didn't see this feature in the documentation anywhere though ─ could it be added?

I see two outstanding use cases:

  • if there is a desire to sync multiple emails from a contact record
  • if an org already uses the email location type for another purpose (e.g. to distinguish a contact's work/home emails)

Wonder if development to address these would be of interest to others?

@ufundo ufundo changed the title Feature: specify a "non-primary" email from contact record to use for sync Feature: specify email(s) from contact record to use for sync Jul 16, 2020
@deepak-srivastava
Copy link
Contributor

Information about "Google" location type has been added to the documentation. If you see any other improvements to doc, please feel free to PR.

Rest of the points i see as feature request , and let others discuss / weigh-in.

@deepak-srivastava deepak-srivastava added enhancement New feature or request documentation Improvements or additions to documentation labels Sep 3, 2020
@zampettim
Copy link

I would say that adding a hook that can be used to "obtain" the email address to use would be the most extensible. That way, people could just implement the hook to retrieve the email address using any rules they want. For those that don't want to do any coding, people could provide extensions with some common implementations to choose from as well.

@magnolia61
Copy link

magnolia61 commented May 22, 2022

I was under the impression things worked differently. Therefor with searchkit I created smartgroups that search for emails with a specific location_type_id. The smartgroup is for the entity email so I thought if I would sync those groups the searched for email would sync. But it seems that this extension looks at the contact for that email and selects another email (primary or Google)

image

A easy and end-user friendly suggestion I think would be to include the location type as a selector in the sync configuration screen of the group. A list of available location types could be shown. Plus 'Primary' to let the be the one." Mock up:

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants