Yesterday afternoon the CiviCRM UK usergroup got together for their first proper meeting in Bristol. It was a great chance to meet other users in the UK and be involved in interesting discussion about how we use - and want to use - CiviCRM. It was also nice to go to the dockside afterwards, catch the last of the sun, and watch hot air balloons flying over the city (though at that point, the discussion did move on from constituent relation management).
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.