Restricting custom field sets to contacts (not users) in specific groups

[amberau]

I'm looking for a way to restrict the visibility of custom field sets that apply to contacts to the edit/view screens of contacts who belong to specific groups.

I want to avoid using custom contact types (can explain further if required) but would really like custom field sets to only appear where they are relevant.

Example:

We have a lot of custom data related to staff (even beyond what CiviHR provides) that I have allowed our HR team to view/edit. However, HR don't only have access to staff contacts - they also use Civi to look up and manage the details of service providers, partners, volunteers, fellows, interns etc. But why should HR see a tab for managing insurance claims for a contact that is a travel agent, or someone we order office chairs from? Not many people in our team are technical, so anything that doesn't need to be on the screen is confusing - Too Much Information.

I can create an ACL for a set of custom fields OR a group of contacts, but not (as far as I can tell) for a set of custom fields ON a group of contacts.

I could create a profile, but even that can only be limited to one group, not many, and I'm not sure why I'd want to create a profile for every custom field set / group combo.

Basically what I'm looking for is a setting on the custom field set form to select the contact groups the field set should appear for.

If this is not possible I will customise our Civi to allow it, but if there's a configurable alternative that would be really nice

As a quick intro, since this is my first post:

I am the sole technical employee for a 65 strong team at a non-profit. I recently presented a case for CiviCRM to all our team leads and we decided to go ahead with implementation. We have a really complex model and requirements, so our implementation will require a lot of customisation and is still in the very early stages. I am really looking forward to having our team happily Civving away, because I think CiviCRM will fill a big gap that has existed in our operations for a long time.

Thanks for any help you can offer!

[Michael McAndrew]

Let me paraphrase to see if I understand what you want to do.  Do you want to say HR should only be able to see HR fields for all contacts, and travel agents only see travel agent fields.  If so, you can do this with just ACL.

Or do you want to only show HR fields on contacts that are HR contacts.  If that is the case, then contact types is kind of the only easy way to do this, I'm afraid.

I guess you probably know this, but ACL is not about what fields contacts have - it is about what contacts users can see for particular contacts.

If this is not possible I will customise our Civi to allow it, but if there's a configurable alternative that would be really nice

If you do decide to go down this route, a word of warning - it is easy to underestimate the amount of work that will be required to keep this customization through upgrades. In my experience, upgrading easily and seeing new features makes users happier than having these kinds of customizations and being prevented from upgrading.  It also makes for happier developers and implementers since reapplying customizations through upgrades is boring, and even if you do it in the smartest, least intrusive way possible, it is still invariably needs testing and fixing through upgrades.  I guess there is a hook that can do this fairly simply on the view / edit contact screen, but I am sure there are details and edge cases that will require extra work.

Not many people in our team are technical, so anything that doesn't need to be on the screen is confusing

Hearing that. You might want to quickly check with them before you embark on this. A question like "Would you be OK seeing this extra informtion - it is going to be a pain to remove it so I'd rather leave it for now - we can possibly remove it in later versions since that feature might get added in a future version of CiviCRM".

Or rather than customize your CiviCRM, you could consider adding this feature to core CiviCRM with some tests, which is more maintainable.

Or you could reconsider using Contact types to do this (though I guess you are using them for something else at the moment?)

[JonGold]

Could you say a bit more about not wanting to use contact subtypes to achieve what you're looking for?

[amberau]

Thanks for your comprehensive and prompt response Michael - much appreciated and a pleasant surprise for my first post.

Or do you want to only show HR fields on contacts that are HR contacts.  If that is the case, then contact types is kind of the only easy way to do this, I'm afraid.

That's the case, and that's what I thought. Oh well.

a word of warning - it is easy to underestimate the amount of work that will be required to keep this customization through upgrades

I hear you. I had hoped, as you suggested, to just do this through a few hooks in a custom extension - maybe even the opposite way around (for each group select which custom field sets apply). I don't have much experience with upgrades yet though, so you are probably right that it would be too painful to maintain.

A question like "Would you be OK seeing this extra informtion - it is going to be a pain to remove it so I'd rather leave it for now - we can possibly remove it in later versions since that feature might get added in a future version of CiviCRM".

That's the first thing I asked. Then I got asked to remove it again. And again. And again. At the moment I'm just trialing this with the HR team. As I introduce more and more people to Civi I can sense I will hear these same questions dozens of times a day if I don't give them a screen that looks exactly as they expect it to.

Or rather than customize your CiviCRM, you could consider adding this feature to core CiviCRM with some tests, which is more maintainable.

I would much rather do that - it makes a lot more sense to me to contribute to Civi core, but as a newbie I have no idea if this is functionality others would be interested in, and if a pull request would be accepted? Maybe an extension would make more sense?

Or you could reconsider using Contact types to do this (though I guess you are using them for something else at the moment?)

Not using them for anything else at the moment, just have a fundamental distaste for a system where a contact has only one subtype and once assigned it can't be changed (please do correct me if I'm wrong in these assumptions). What happens when a volunteer becomes a staff member, and then joins 2 departments, then leaves and co-founds an organisation that is a partner?

Groups and tags are much more dynamic concepts and our organisation is super dynamic

[JonGold]

Hi Amberau,

Multiple contact subtypes are supported in CiviCRM, and people can be added and removed from subtypes as you please.  I hope that info makes your life easier!

[amberau]

Multiple contact subtypes are supported in CiviCRM, and people can be added and removed from subtypes as you please.  I hope that info makes your life easier!

It SO does. Either I've already reached my processing capacity for this week or I was reading outdated documentation / articles.

That's why forums are so lovely, and helpful people on forums are the best people. Thanks!

[amberau]

Well, I'm embarrassed that I now can't find the article I read when I first started playing with Civi that recommended using groups over contact sub-types because of the limitations on sub-types. I really am grateful that I've had those assumptions corrected at this early stage, and hope I'll be a helpful contributor instead of a forum clutterer in the future. Thanks again.

[petednz]

There certainly were discussions some years ago about the limitations of sub-contact types.

The project also sounds like a couple of others we have been involved with where for most of the users, civicrm just has 'too much info' and 'too many steps'. In both cases we found that using Views and Webform-CiviCRM let us create the displays, listings, forms etc that they needed without ever needing to step in to civicrm itself.

May be worth considering for some of your scenarios.

[Michael McAndrew]

I now can't find the article I read when I first started playing with Civi that recommended using groups over contact sub-types because of the limitations on sub-types

Well I'm sure it did exist - feel free to point us to it if you find it, and we can see if we can go about correcting it.