CustomField - Support filters in EntityReference fields

[colemanw]

Overview

This adds basic support for filters on the new custom field type EntityReference.

Before

Filters supported on the old ContactReference custom field type, but not for the new EntityReference.

After

Filters now work for EntityReference forms. Minimalist "Advanced Filter" textfield now shown for EntityReference as well as ContactReference fields:

Technical Details

As of e9fe23e APIv4 started passing anything stored in the CustomField.filter column to the getFields metadata. This completes that work by ensuring the filters are applied at runtime for all forms (both Quickform and Afform), and exposing the filters to the create/edit custom field form.

Comments

This is not a great UX but it's a start. SearchKit-style field selectors would be an improvement but would require mixing Angular code into the create/edit custom field form which is QuickForm-based. Adding Angular code to that form would be a little tricky but not impossible.

[civibot]

(Standard links)

• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[totten]

Yeah, this move seems like a good balance.

Coleman linked this in another discussion, where it had been left as an open-question about how far up to move the install(...search_kit...) statement. The tension in that question: Search Kit is a "required extension", but that concept is contradictory:

• As a "required" thing, it should be enabled by default in all integration tests (to make them more representative of the real runtime - and to avoid redundant boilerplate).
• As an "extension", it should be a discrete thing with clear boundaries (and you can't enforce/test those boundaries if it's always-on).

That's a tricky line. The current patch is a decent balance (enabling it for a large block of tests where they're likely to be needed -- without making it totally required or affecting 3rd party suites).

[jensschuppe]

We're currently testing this, I'll add a review soon.

[TychoSchottelius]

Hi there.
I have now tested the requirements from which this PR arose in our corresponding test environment:

1. Cases have an additional field of type "Entity-Reference" that references events.
2. With the filter field I can successfully limit the autocomplete selection to events of a certain type.

This prevents users from confusing the functionalities associated with certain event types.

I was able to define the filters in two different corresponding ways, both of which make sense from my point of view:

1. event_type_id=11
2. event_type_id:name=EU-Projekt

[colemanw]

Thanks for the review @TychoSchottelius - sounds like this is merge-ready. Did you have anything to add @jensschuppe or is this good to merge?

[jensschuppe]

@colemanw I think I agree 😄 Thanks, this makes Entity Reference Custom Fields much more useful!

[jensschuppe]

... maybe this should be documented somewhere in the docs, alongside the fact that those global per-field filters will always apply, even when an Afform defines additional filtering via SearchKit.

[peth-systopia]

Thanks very much @colemanw, this adds a lot more flexiblity and power to CiviCRM.