Afform - Allow selecting search operator for filter fields

[colemanw]

Overview

This permits filter operators to be set by the form admin.

Before

No control over filter operators (the implied operator was always inferred from the input type and data type, usually CONTAINS).

After

Operators can be set on the backend of the form:

[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).

[demeritcowboy]

Cool it seems to be working but the visual cues to the user aren't quite like I'd expect. I have one on the test site here you can see that I adjusted from one on a real site where this would be neat to have.

1. It doesn't tell them what the operator is.
2. If you have a default value, it initially treats it as =.
3. I'm not sure about the wording of the operators if they are to be displayed on the form to the non-technical users. To them "LIKE" probably doesn't mean anything, and they would expect that's what "CONTAINS" means. "Matches Pattern" probably won't mean anything to them either, and even for techies they might not be sure that means regexp.

[colemanw]

@demeritcowboy TLDR; I've pushed up a fix to item #2. I propose to defer the other two items.

1. Forcing the operator to be displayed - not everyone might want that, and you can adjust the wording of the field label, or add field help text yourself.
2. That was a bug, thanks for spotting. I've pushed up a fix.
3. These are the same operator choices as in SearchKit, so if you think they need adjusting we should do it throughout SearchKit not just here.

[demeritcowboy]

Ok, I don't want to hold it up over the words. Partly I'm thinking the next obvious step is to have the equivalent of drupal views exposed filters, where the end-users would see/select them. The wording would matter more there.

[yashodha]

@demeritcowboy this should be merged, right?

[UshaMakoa]

Thanks @colemanw nice! I'll test it.

[allinappliadmin]

thanks!

[colemanw]

@UshaMakoa are you ready for this to be merged or do you need to do more testing?

[allinappliadmin]

@colemanw I've tested with the new options and I agree with @demeritcowboy that we should be able to edit the operator on the front because sometimes I need to filter the contacts having the 'volunteer' tag and sometimes I will need to filter those not having the 'volunteer' tag. It doesn't really help me to set it 'hard coded' on the backend of the form.
is it hard job to display the operator on the filter some way like on SearchKit?

[colemanw]

Ok guys I think I need to clarify the process of PR review...

The only way for CiviCRM to move forward is for PRs to get merged. When a PR is submitted it needs to be reviewed to answer the basic questions of:

1. Does it improve CiviCRM?
2. Does it cause problems?

Generally speaking, if the answers are "yes" and "no" respectively then it should be merged. If there's a desire for additional improvements (and honestly, when is that ever not the case?), then future PRs can be written, but desires for more features (which do not yet exist) shouldn't derail the current PR (which does exist). Or, as someone wiser than me once said "Don't let perfect be the enemy of good."

So the question before us right now is "Should this PR be merged?"

Additionally, I'll note that funding was provided specifically for this feature of back-end configurable filters. So far, no one has yet provided funding for front-end filters.

[allinappliadmin]

Coleman, thanks again for your work and for explaining the merging process and the necessary method behind it.
My mistake if I hadn't made my self clear enough when giving you few specs about what I was expecting and dreaming of. So if the question, should this PR for adding backend operators to filters for FB be merged, I will say YES. And if this work on the backend is necessary to add filters on the frontend then I'll say YES twice. If it doesn't help for the next step - making CiviCRM even better, then I'll say NO because the goal, even if it needs several steps to reach it, is to have operators to filter on the frontend. I've pinged Usha and he might have a different point of view.

[allinappliadmin]

Now it has been merged, the next question is how many € to then make operators on the frontend real? I don't feel like standing now in the middle of river.

[colemanw]

Thanks all.
To answer your question @allinappliadmin yes this does get us closer to your goal. I think an additional 5 hours work would be needed to expose operators to the front-end as well as the back-end.

[allinappliadmin]

that seems doable. I've pinged @UshaMakoa to check if he'll be interested in supporting your job with us. Tell you soon.

[UshaMakoa]

Thanks all. To answer your question @allinappliadmin yes this does get us closer to your goal. I think an additional 5 hours work would be needed to expose operators to the front-end as well as the back-end.

ok for 50% for me

[allinappliadmin]

@colemanw so it's GO to have operators on the frontend of filters in Formbuilder so the end user can easily filter within the results :-)

[colemanw]

Ok thanks @allinappliadmin and @UshaMakoa I'll let you know when I have that PR ready.

[colemanw]

@allinappliadmin @UshaMakoa here is the new PR for exposed operators! #26496