Blogs
Integrating CiviCRM with an email client (specifically Outlook) has been a long requested feature. Unfortunately we dont really have any internal windows expertise to make this happen (for now). For now, we've built some code for the HRD project that attaches incoming email as an activity to the contact record of emails that are in the from / to / cc / bcc fields (we create a contact record if not found)
One of the issues to solve when implementing the view-based approach described in my previous post on the topic is how to make the current codebase be aware of when to use a view and when to keep operating on a table.
Next meet up for the UK usergroup will be at the Create Centre in Bristol on Tuesday 22nd July, 4-6pm. Thanks to Dave Moreton, Circle Interactive, and and Sean Kenny, VOSCUR, for kindly organising and donating the venue. We're keeping the agenda open and attendee led so it is of maximum use: we'll start with introductions and a couple of short presentations (volunteers, anyone?), and then follow with an open discussion/round table.
If you’re running a site using Joomla you’re no doubt aware that some things which appear to be straight forward with a Drupal base aren’t so easy. Both Joomla and Drupal have their strengths and weaknesses, I just happen to be a long way down the Joomla path.
A big issue for me was how do I restrict access to my site depending on memberships to a real world (non internet) organisation. All my members have an entry in the CiviCRM database but many will not have a CMS login. Out of the box there was no real way of achieving this without getting into LDAP territory.
Long time no blog – mostly because my initial concept of bringing the multi-language features to CiviCRM was replaced with a brand new approach, which should be much more developer-friendly.
Having the contents of a CiviCRM site in multiple languages means that certain columns in the database (the user-visible ones) must be localisable – but how to implement this from the database point of view is far from obvious.
Long time no blog – mostly because my initial concept of bringing the multi-language features to CiviCRM was replaced with a brand new approach, which should be much more developer-friendly.
Having the contents of a CiviCRM site in multiple languages means that certain columns in the database (the user-visible ones) must be localisable – but how to implement this from the database point of view is far from obvious.
We made few changes to default settings for New dedupe Now default dedupe rules settings are as follows
Fuzzy Rules for
Individual => First Name AND Last Name AND Email Organization => Organization Name OR Email Household => Household Name OR EmailStrict Rules for
Individual => Email Organization => Organization Name OR Email Household => Household Name OR Email