CiviCRM Community Forums (archive)

I have hit a problem which seems to be quite a generic scenario. When running an event there is often a need to gather custom data from a participant AND to maintain administrative participant data such as whether the person has been assigned a room, whether airport pickup has been arranged, whether the person has been sent an information pack.

It is easy enough to set up custom data fields for participants that they don't see but surprisingly difficult to retrieve the information from them.

Say, for example, I choose to set up a checkbox for whether an information pack has been send out. Even if I set the default for this check box to be 0 (no) it doesn't actually get set to that for my participants because this field is not part of the profile they fill in when they enlist. It is null for all the people that matter. I can't search for a null value from my 'find participants' search and if I search for a Null value using search builder then I get everyone who has 'received an information pack' set to NULL for any event because it is a contact based search not a participant based search.

It has been pointed out that if a hidden field were to be added to the template for the event form then it would be set to the default. This would work but isn't trivial to implement (as you have to assign it to the template as well as add it in) for a usage that I would have thought would be extremely common.

If it were possible to search for participants with null values in custom fields or to assign hidden fields to profiles this would be easy.

Thanks Kurund - I think the longer term suggestion is about having a simple admin feature in Profile to 'hide' a particular field so it gets 'auto-filled' by default

Seems like 2 different approaches for resolving the problem have been surfaced here:
1. Add support for finding custom fields with NULL value (to Find Participants and other search forms)

2. Allow hidden fields to be included in Profiles (so a default value can be set for custom fields when records are created or updated)

... and third possibility, which mirrors what we do for core fields (when defaults are defined in the schema):

3. Set custom fields to their default value (if defined) whenever a record is inserted (regardless of whether that custom field is included in the create form).

What do folks think are the pros and cons of these approaches? Any other ways to solve this?

Is it a one-time change? Business requirements for what to track for event attendees change on the fly.

I suspect that one weakness with 2 & 3 is that sometimes these custom fields might be created after many people have registered. e.g. the manager could swan in one day and say that they issue all attendees with a super-duper scout widget and they need to track it.

In this case the participation entries would already be created so better search options might work better. The search in this case probably should treat NULL as whatever the field default is.