Expanding functionality of UpdateGreeting.php

[kmarkley]

I had completely incorrect expectations of how UpdateGreeting.php should work. 

As discussed in this thread, contacts that are imported, created by event registration, or created by drupal registration have all their greetings set to NULL.  Currently in my DB, 95% of all contacts have NULL greetings.

I thought I could use UpdateGreeting.php to populate these fields in advance of sending out a snail mailing.  Unfortunately, I have just (finally) come to realize that the script ignores NULL greetings by design. (see this thread).

It is possible to update NULL greetings by setting the force=1 flag in the URL.  The downside to this approach is that it will also overwrite the handful of contacts that have had their greetings changed from the default.

So I wold like to propose that UpdateGreeting.php be expanded to include the use case of populating empty greeting fields.  Perhaps by setting force=2, the script could update ONLY those contacts with for which no greeting has been set.  This would also make the script useful as a cron job to periodically 'clean up' by creating default greetings for contacts recently created via event or drupal registration.

[Dave Greenberg]

Kirk - I agree that the script needs a 'mode' where it updates NULL greetings only (to the default) - and doesn't change greetings that are set. I'll be posting an issue / fix for this shortly. Will add the link here.

We'll also be looking at the possibility of setting greetings / addressee values when contacts are created via profiles.

[kmarkley]

Cool.  I have actually made a patch for this to solve my immediate needs, but I haven't had time to test it thoroughly.  Also, I wasn't sure if setting force=2 was really the right approach for telling the script to process null greetings.

[Dave Greenberg]

I've filed an issue for fixing the 'holes' in the UpdateGreeting.php script at:

http://issues.civicrm.org/jira/browse/CRM-5921

I will be discussing it w/ Kurund on Monday to get his feedback on the proposed changes. If you have thoughts on how the proposed new behavior fits your use cases - please post here or comment directly on the issue.

[kmarkley]

Contacts have greetings that are default (D), custom (C), or null (N).

Curent configuration is:

force=0	D
force=1	DCN

There are at least 3 approaches to extend this. 

Either add to the values that force can take:

force=0	D
force=1	DCN
force=2	N

which has the advantage of not changing anyone's current use of the script.

Add dimensions for each greeting state:

force=1	C
default=1	D
null=1	N

used in any combination.

Or explicitly define which greeting states get updated on each run:

proc=default, 0, or absent	D
proc=custom or 1	C
proc=null or 2	N

just like the way contact_type (ct) and greeting_type (gt) are defined now.  force=1 could still be interpreted as process all states (effectively overriding proc= if set)


My use case is satisfied as long as there is some combination of flags that process null greetings only.  That said, the third approach seems most consistent with current usage.

[Dave Greenberg]

The 3.1.4 implementation as spec'd in the issue tracker will process NULL greetings only by default (i.e. when no force=N is passed). This seems to be the most common use case, so we've made it the default behavior. It handles contacts created w/ NULL *_greeting_id OR address_id, as well as contacts who haviing a value for the _id, but don't have the _display value set. This second condition can happen during contact IMPORT (since the import code doesn't set the _display (evaluated) value.

We also are hoping to get the 'profiles do not set greeting / addressee data' problem fixed in 3.1.4:
http://issues.civicrm.org/jira/browse/CRM-5922