Custom Groups, Custom Fields and multiple values

The CiviCRM core team is currently meeting in San Francisco. We tend to meet 2-3 times a year. These meetings help us crank out a few large projects as a group and also help improve our communication when we return to our respective home bases. The focus of the San Francisco meetup has been on CiviCase, US PIRG projects and a few features from the 2.2 roadmap. Our group (kurund, yashodha and me) have been working on extending custom groups with two new features. In 2.2 a custom group can be designated to hold multiple values. This allows a contact (or relationship/group/activity) to have a 1 to n relationship with a custom group. One use cases for this is storing educational history of a contact. A custom group with fields: Name of School, Qualification earned and Graduation Date could be designated as multi-valued. A contact could have 0 or more educational records. Viewing this custom group will show all the educational information associated with the contact. On edit, you can modify the existing information and/or choose to add new information. Implementing this at a group level has fairly minimal schema changes and is a good chunk for us to tackle and get working for 2.2. Kurund is working on building the view/edit/create screens using jQuery. Yashi has been working on database and interface changes needed for custom group settings. I was responsible for the api functions that store/retrieve custom values from the table. I wrote a few unit tests and in the process found a couple of bugs with the current custom data storage. I then extended the parameters and return values to allow for multiple value and wrote a few more unit tests to ensure that this worked in both the old and the new format. The CiviCRM code base is fairly well structured, so we have to make the code changes in just a few places (or so we hope). We are also taking this time to clean and update the custom group/field codebase Yashi is also working on adding custom group support for specific events pages. Users will be able to create a custom group that extends the object 'Participant' for one specific event. We will generalize this in future releases and add more fields.

Comments

Wow, this could not have been more timely.

Are there plans to support importing into these fields? Sorry if this is an obvious question :)

the first version will be pretty simple and restrictive. So i'm pretty sure we wont support import/export for these groups/fields

Once we get the multiple value thing working for custom groups, our next task will be to get it working via profiles and figure out what extensions we need to do so. I suspect we'll look into import/export after that

however if important to you, consider a code contribution / sponsorship. You can also write a custom search to do the needful quite easily

lobo

Glad to hear this piece is coming together. It will provide great flexibility for the system.

I will be interested to see how the multiple value groups integrate into profiles, especially if they are combined with custom fields (and core fields) that are not multiple values.

Within a single profile, would a user be able to complete some single-value fields, and have the option of entering multiple records for the multiple value fields? This, in my mind, would be the best scenario. Envision a form where a number of records regarding the individual are captured, and, as in the example above, the user can complete 3 records for their educational background, then 5 records for their employment background. All within the same form.

i suspect profile integration will be in 2.3/3.0

I looked quickly at jQuery and while I have no technical opinion on its use I do have a practical concern - Kilobytes!

What with DoJo, Calendar, and MooTool (in Joomla 1.5) scripts, the first connection to a CiviCRM site downloads about 0.5 Mb of data - sloooow. Each subsequent connection tests each of these .js files for an update - slooow. This is particularly a problem over an HTTPS connection where you can't use a proxy.

Please consider performance as well as functionality/coolness.

we will not be able to make the full transition in 2.2, but in 2.3 we'll only ship with jQuery. We'll also replace the calendar widget with a jquery calendar widget (or so we hope)

lobo