"is_visible" flag on CustomGroup and/or CustomField entities (#3) · Issues · Community / Feature request

"is_visible" flag on CustomGroup and/or CustomField entities

With the introduction of "custom fields on any entity" (CRM-21140), we now have a means to extend the data model in new and exciting ways.

One downside compared to core fields is that custom fields are always added to relevant forms, whereas core fields are added only when applicable.

I'd like to propose that we add a "is_visible" boolean to the CustomField table, set to (and defaulting to) TRUE on all existing fields. This would allow developers to create fields that they don't necessarily want to make public.

I've thought of several use cases for this in the past, but the one that comes to mind now is the OSDI extension. To handle 2-way sync between multiple sources, it's important to keep a record of the foreign system's primary key for that entity. However, this is unnecessary clutter on the user's record.

I can also see the argument that CustomGroup, not CustomField, could have the "is_visible" flag set instead. However, I don't see any downside to having the finer granularity. I could also see the argument to adding it to both - this eliminates the problem of detecting CustomGroups with no visible custom fields inside.

With the introduction of "custom fields on any entity" (CRM-21140), we now have a means to extend the data model in new and exciting ways.

One downside compared to core fields is that custom fields are always added to relevant forms, whereas core fields are added only when applicable.

I'd like to propose that we add a "is_visible" boolean to the CustomField table, set to (and defaulting to) TRUE on all existing fields.  This would allow developers to create fields that they don't necessarily want to make public.

I've thought of several use cases for this in the past, but the one that comes to mind now is the OSDI extension.  To handle 2-way sync between multiple sources, it's important to keep a record of the foreign system's primary key for that entity.  However, this is unnecessary clutter on the user's record.

I can also see the argument that CustomGroup, not CustomField, could have the "is_visible" flag set instead.  However, I don't see any downside to having the finer granularity.  I could also see the argument to adding it to both - this eliminates the problem of detecting CustomGroups with no visible custom fields inside.

To upload designs, you'll need to enable LFS. More information