Storing complex forms in a case

[mathieu]

Hi,

I have a project where staff does a weekly follow-up of their clients every week (more precisely, dietetists for pregnant women in need of support). CiviCase seems to answer the requirements pretty well. I have a question however concerning complex forms.

Currently they have a detailed weekly follow-up form that look like this:

* Type of food A, Quantity, Calories, Proteins, Recommended
* Type of food B, Quantity, Calories, Proteins, Recommended
* etc.
* Total calories, proteins, recommended.

The list of "types of food" is pre-determined and should not change often (about 20 types).

I know it's probably more a general custom field issue, than civicase, but it's probably more likely that people here have run into this issue. Any suggestions on how to organise the custom data for this type of form?

Presumably, this is a case Activity. Should I just create 20 x 4 custom fields, and theme the form with CSS to look as a grid?

Could webform_civicrm be a better solution?

Alternatively, I was wondering, since we don't actually need the form info for stats, except the totals, would be to create a table using Javascript in a single field, store it as json in the field, and store the totals in separate fields. Obviously, this is a complete hack and more of a last result.  (alternatively, maybe webform_civicrm could store in webform the "grid data", and the totals in civicrm custom fields?)

Thanks in advance
Mathieu (bgm on IRC)

[Donald Lobo]

how about a multi-record custom group:

contact id, Date (or week number), type (and u can make total a type), quantiy, calories .....

that way you only have 4 or 5 custom fields. and should be able to use the profile stuff for multiple record custom group in 4.3

i dont know the depth of support that webform has for multiple record custom group

lobo

[mathieu]

Will this work on a Case Activity?

My understanding was that multi-record worked for elements where it can be placed as a Tab (not inline).

[mathieu]

For the curious, I chose to implement a custom extension to store the data. I didn't want to twist a core functionality in an experimental way, and this data does not need to plug into existing search/reports/etc, so it was rather easy to implement.

Here is a screenshot to show the result, in CiviCRM 4.3 beta.

Not shown on the form, is that the "calories" and "proteins" fields are automatically calculated in javascript, based on the quantity and frequence. The "comment" field is persistant accross activities, i.e. it is shown by default, as a reminder to case workers, but they can also change if necessary. Same applies to the "notes" (informations complémentaires), it is always pre-populated with the values of the previous activity.

The numbers shown next to the textfields in the grid are the values of the previous activity. It provides a visual way of comparing values.

In short, with CiviCRM hooks and crmRegion and the functions for extensions, this was pretty easy to implement. Visually, the grid still needs improvement, but that's another issue

The only issue with my implementation, is that I wanted to have an admin UI for the row items and categories. I could have use option values for that, but I didn't find a quick way to add new option groups from the interface (e.g. so that the administrators can create new food categories by themselves). I implemented that part using Drupal.