CiviCRM Community Forums (archive)

*

News:

Have a question about CiviCRM?
Get it answered quickly at the new
CiviCRM Stack Exchange Q+A site

This forum was archived on 25 November 2017. Learn more.
How to get involved.
What to do if you think you've found a bug.



  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Support »
  • Using CiviCRM »
  • Using CiviMail (Moderator: Piotr Szotkowski) »
  • deleting on hold email addresses and making others primary
Pages: [1]

Author Topic: deleting on hold email addresses and making others primary  (Read 388 times)

questions

  • I post occasionally
  • **
  • Posts: 79
  • Karma: 2
  • CiviCRM version: 4.4.6
  • CMS version: Durpal, 7
  • MySQL version: 5.1
  • PHP version: 5.3
deleting on hold email addresses and making others primary
July 07, 2014, 10:37:22 pm
Does anyone get rid of the old email addresses that have bounced? 

It seems like a decent thing to do.  Is there any reason I wouldn't want to get rid of them?  Right now it looks like about 10% of our total email addresses are on hold for bouncing.

Is there any easy way to do this or should I just write some sql, which should be pretty straight forward (delete from civicrm_email where on_hold).  I suppose I might want to only delete those that bounce as bad vs those that get held for quota, vacation, dns, etc.

I guess first I'd want to make sure none of the bounced addresses isn't something easy to fix like .cm instead of .com. 

Then there is the issue of primary.  I assume I'd need to manually set the primary flag on one of the remaining addresses if there is one.

Are there any gotchas I'm missing here?

Erik Hommel

  • Forum Godess / God
  • I live on this forum
  • *****
  • Posts: 1773
  • Karma: 59
    • EE-atWork
  • CiviCRM version: all sorts
  • CMS version: Drupal
  • MySQL version: Ubuntu's latest LTS version
  • PHP version: Ubuntu's latest LTS version
Re: deleting on hold email addresses and making others primary
July 07, 2014, 11:22:17 pm
I guess I would create a scheduled job to do that on a regular basis? In other words, create an API function and set it up as a scheduled job. Do you know how to do this or would you prefer to stick with your sql?
Consultant/project manager at EEatWork and CiviCooP (http://www.civicoop.org/)

questions

  • I post occasionally
  • **
  • Posts: 79
  • Karma: 2
  • CiviCRM version: 4.4.6
  • CMS version: Durpal, 7
  • MySQL version: 5.1
  • PHP version: 5.3
Re: deleting on hold email addresses and making others primary
July 08, 2014, 09:34:54 am
Ultimately a job probably makes sense.  To begin with, I think I'd like to look over the bounces just to make sure we're not automatically deleting something that is ok or easy to see what is wrong.

I suppose I could come up with something that would report the addresses that bounced the first time they were used.  These most likely will have typos. Once a year we have fair amount of manual data entry and get a number of typos.

JohnFF

  • I post frequently
  • ***
  • Posts: 235
  • Karma: 6
  • CiviCRM version: 4.4.13
  • CMS version: Drupal 7.28
  • MySQL version: 5.5.31-1
  • PHP version: 5.3.27
Re: deleting on hold email addresses and making others primary
July 08, 2014, 09:45:16 am
We've got a system on the cards to fire an sms to people requesting a new email address if it bounces. If anyone wants to help me on that then poke me!

Also, is now a good time to plug my automatic email amender? Could help you preventatively get those bounce numbers down...
If you like empowering charities in a free and open way, then you're going to love Civi.

Email Amender: https://civicrm.org/extensions/email-amender
UK Phone Validator: https://civicrm.org/extensions/uk-phone-number-validator
http://civifirst.com
https://twitter.com/civifirst

Pages: [1]
  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Support »
  • Using CiviCRM »
  • Using CiviMail (Moderator: Piotr Szotkowski) »
  • deleting on hold email addresses and making others primary

This forum was archived on 2017-11-26.