Greetings and Salutations :-)
As some of you may already know, the existing "Greeting Type" feature in CiviCRM is pretty broken. You can't use it to specify a greeting for either email or printed / postal communications (no token or export support). In addition, as described in Tony Guzman's recent blog on
Better Household Management - it's not designed to support a number of key use cases.
So... Tony and the folks at
Dharmatech have been working with us to figure out a flexible WORKING solution which can handle the simple cases ("Dear Dave") as well as the more complex cases ("Dear Dave and Bob", "The Honorable Scout Conberg", etc.). If you haven't read Tony's blog yet - start with the
Greetings and Salutations section there. Then, if this is an issue that affects you - check out the
details of the proposed implementation in the issue tracker.
Address Sharing
Tony's blog also raised the issue of extending
address sharing beyond the current "Use Household Address" feature. It makes sense to us to generalize this - allowing sharing between any contact types. I've filed a
draft specification here to get the ball rolling on this. However, this work won't make it into the 2.3 release - unless some other developer(s) step up to take it on.
Please add your comments / suggestions for either specification here.
Comments
It is fantastic to see the effort that has gone into thinking this through. There are lots of people who will appreciate this development!
(PS - I think HH are important and could work well in our use cases if they were a special contact type that only had one location to which you can easily add individuals who then display the HH address within their profile as a "Household" location)
Thanks Dave for helping move this functionality forward. I think it will be a great improvement to greetings but also better allow organizations to not use the Household contact type if they don't need it. Speaking of which, here is the issue that proposes making the household and organization contact types optional in case people are interested: http://issues.civicrm.org/jira/browse/CRM-4566
Tony
Hi,
I don't think the above described option handles "non english" languages. For instance, in french, you write the greeting differently if this is a male (Cher Robert) or female (Chère Anna).
In german the prefix/title is important (Herr Doktor Schuman, Frau Doktorin Meyer) too.
Basically, to avoid the clumsy Cher(e) {firstname} or avoid having a custom greeting for all of the non english contacts, you need to introduce tests.
What about having custom functions one can call as a token ? eg {function.GermanGreeting (firstname,lastname,jobtitle,prefix)}
that will compute the right way of addressing the person.
BTW, could also be useful even in english, eg. to have custom message based on a value, for intance write a different sentence if the contact has a phone number recorded or not)
What do you think ?
X+
You'll be able to create any number of options for the Greetings "drop-down" - and include any of the contact tokens in those choices. I think this should provide pretty complete support for things like gender differentiated greetings. For example, user can select:
- Cher {contact.first_name} for male contacts
- Chère {contact.first_name} for female contacts
... or
{contact.individual_prefix} {contact.job_title} {contact.last_name} for the German example
and they can enter a completely custom string for the exception situations.
I think xaviers suggestion is to also make the custom greeting hookable so folks can use logic to customize the greeting (since thats what a language like german makes you do)
lobo
Yes,
and if I have to choose the salutation type on a per contact, it puts the user in charge of choosing Chère when choosing Female. That's asking them to do something the system should do for them, not that they do for the system.
Beside, and I'm probably being an edge case, but the salutation is ideally not based on the contact, but on the mailing language as well. We do write to the same contact in different languages. When there is a planned mailing, we have the time to translate the document to the national language, when that's an alert, that's sent in english for instance.
Don't have any idea of the complexity, but if I can have a {function.customGreating1(contact.first_name,contact.last_name,contact.gender)}
and have a php file where I can put a
function customGreating1($first,$last$gender) {}
I'm quite sure even the most wicked case is covered, and you're able to write custom message based on the group, the tag, the third custom field on the left and the captain's age...
X+
After lunch discussion w/ lobo :-)
CRM-4600
Caveat - we're up to our eyeballs in 2.3 issues, so this might get pushed to 2.4 unless you are able to jump in and take it on.