CiviCRM Community Forums (archive)

Hello there.

A client wanted some custom data to be shared across some but not all organisation types and some but not all individual types.

The use case was that they are interested in tracking information on their funders.  There funders come in four flavours.  Three of which are organisations and one of which is an individual

* Institutions (a type of organisation)
* Trusts and foundations (a type of organisation)
* Corporates (a type of organisation)
* Major donor (a type of individual)

So I wondered if CiviCRM could be hacked to allow this by making the custom data set apply to a contact and then manually editing the data definition in the civicrm_custom_group table (it isn't possible to do via the UI).

It turns out this is possible.  The steps I followed to do this are.

1) create a custom data set and say that it applies to Organisations
2) choose the organisational sub types that you need.
3) find the civicrm_custom_group table and the row that represents the custom data set.  edit the extends column - change it from Organisation to Contact
4) also edit the extends_entity_column_value column and add in the individual contact sub types.

Note: You can get the names of the individual contact subtypes from the civicrm_contact_type table.  Be careful when you are doing step 4 since CiviCRM uses an interesting character to separate values which doesn't show up very well in programmes like phpmyadmin.  My quick google didn't turn anything up civicrm specific but I am pretty sure this character is the one returned from this php function "chr(0);"

But I have a couple of questions.

1) Do you think this is 'safe'? I can't off the top of my head think of why this would cause anything to break but it seems kind of likely that since civicrm is not expecting contact to have any contact sub types defined, we mihgt break something somewhere

2) do you think we should expose this through the UI.  It is quite useful IMO (see above use case).

This is an interesting idea -- seems to especially make sense for donors that can be orgs or individuals as you've pointed out, but also Media contacts. One concern I'd raise is analogous to the problem of allowing profiles to be used in different contexts: if you have a set of fields in use for all contact types that are "funders" which could be an org or an individual, you may put in fields that make more sense for one or the other. Then if it's not made very obvious that this set of fields is used for both contact types, someone might be looking at this set of fields in the individual record and be tempted to delete a field that doesn't make sense for individual media contacts but does for organizational media outlets (i.e. publication frequency or audience). (Or vice versa, something may make sense only from the org point of view). Perhaps not a big problem...just want to flag it as something to ponder.

A little input from our team: they generally think it would be useful, both for funders like you've done, and for media contact types. No negatives from them, so I'd just say you need to make it clear and have good help text that the fields are used for both individual funders AND foundations, or individual AND organizational media contacts, so not to wipe out a custom field for one unless you want to get rid of it for both. That is all.

that was dgg's proposal

any reason why you are against exposing in the UI in principle?  Maybe we should brain storm about the best way to expose this.  One possible solution would be to have all contact + household + individual contact subtypes (but not contact + household + individual themselves) available when you select contact.

I suggest that since I don't think there is any disadvantage of having some custom data that applies to just some organisation sub types defined as contact custom data (even though it could be more specifically defined as organisation custom data.