Lately there has been lot of confusion using Name, Title/Label and Value. There is also a lot of inconsistency in code and database, hence we are planning to fix it in CiviCRM v2.x release.
Lets take an example of Participant Status, 'Registered'. In this case Name will be 'Registered', value will be an integer from 1..N (this depends on each install) and Label/title can be "Registered" or "I will come" etc. (or a localized version of the word/phrase).
Basic rules are:
- Name: This is fixed value and cannot be changed by user. This is used internally in the code base to do certain actions. This will typically be in english.
- Title/Label: This is user editable field and can be translated. This will be displayed in the system.
- Value: Actual value that is stored in database.
There are few tables where we have adopted correct approach, like "civicrm_option_value". In this table we have separate fields name...Read more
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)
We are currently using ezComponents Mail library to read and process incoming emails. If possible i'd like to transition this to using the Zend Framework, since that will be our basic library framework for CiviCRM v3.0.
The current approach is file based. The...Read more
Earlier this month Evan posted a query about a CiviCRM AMI for Amazon EC2. Joe Murray responded with some proof of concept scripts along with the persistent storage space limitations in EC2. Seems like the folks at EC2 have been busy addressing these limitations and have introduced persistent storage support for EC2 (its currently in beta).
This perked my interest enough, that I spent a few hours over the weekend exploring and thinking about the possibility of using EC2 + Storage as a potential deployment engine for CiviCRM. I think building a base AMI to do this is quite easy, which follows that we can script upgrades, backups and the other missing pieces for a reliable "indivdualized" online hosting service. The tech savvy users can basically...Read more
- We've introduced a new database cache table (civicrm_cache) to cache a few database queries that are repeated a lot. Some of the specific queries include listing all the fields available for the contact types (individual/org/household). This is a combination of the built-in fields (name, address etc) and the custom fields added by the user. This reduces the number of queries invoked from 5 complex queries to 1 simple cache query (and an un-serialize)
- We've added a column (group_type) to the profile table (civicrm_uf_group), so we know the profile type rather than recompute it every time we need it.
- Thanx to Dave Lange who reported and did some analysis on this, we've reduced the number of LOWER( dbColumnName) LIKE 'value' to skip the LOWER part. Email is now stored as lower...