More operators for search kit

Exposing the operator in a dropdown-select would complicate the afform (both the code and the UI) by quite a bit. But I think we might not need that.

Here's my proposal:

For number & date fields on search afforms, the admin UI would have the option to make the field accept a "range". This would allow the end-user to enter a low & high value. That kills 3 operators with one stone: >= (if user only enters a "low" value), <= (if user only enters a "high" value) and BETWEEN if user enters both.
For Date fields, if the admin makes them "Select" AND "range", then "Date Range" would be prepended to the dropdown (similar to current date search fields).
For fields with option lists, the admin would be able to set the field to multivalued (which would implicitly change the operator from = to IN). We could improve this further by borrowing the Include/Exclude combo widget from CiviMail which would allow "IN" and "NOT IN" with a single field.
Text fields will remain as they are now (search with wildcard based on site settings). IMO they don't need fancy operators.

Those all seem like pretty good things - whether we will grow out of them I'm not sure and I'm also not sure if doing those now would create obstables to a more grown up version later.

I'd be keen to get some broader input on this - I can include in the search kit but I'd also like to try to get a few people on a call to shoot the breeze on it - people like @JonGold who I think have already dug in a bit

changed time estimate to 1d 2h

@colemanw just to add this in the mix - I guess where I can imagine people wanting to go is to have say a configured dashlet of givers over x amount where they can change x amount (as per above) but that there might be a default for x and that if they change it it would be remembered as their preference - not saying this is an immediate requirement, just that it's good to think about as I expect it will come up

added triaged label

I'd like to go ahead & implement my proposal and if we find we also need to add a filter_operator param in the future, that will still be possible.

@colemanw if your proposal does not block out another solution later then yes yes yes - I'd be OK with it going into 5.36 if it's this week as it will help my documentation effort

Ok. IMO it would be non-blocking, as adding operators would be a separate thing & we could still do it.

I have pinged the potential funder, who is trying to resolve some other matters prior to engaing with Josh. This was just an example of what they might to fund, so I don't think support from them would be lost by proceeding prior to it being in place.

@JoeMurray please let me know when you find out more about that funding. Thanks for facilitating that :)

mentioned in issue #2494 (closed)

Hi,

Thank you for raising an issue to help improve CiviCRM. As you may know, this issue has not had any activity for quite some time, so we have closed it.

We would like you to help us to determine if this issue should be re-opened:

If this issue was reporting a bug, can you attempt to reproduce it on a latest version of CiviCRM?
If this issue was proposing a new feature, can you verify if the feature proposal is still relevant? Did it get the concept-approved label? Have other people also shown interest? Could it be implemented as an extension?

If the answer to either question is yes, please feel free to comment or re-open the issue. Please also consider:

Is it something that you could help implement, either by sending a patch or hiring someone who can?
Would you be willing to fund the work, either through a CiviCRM partner, or the Core Team?

Thank you for your help and contributions to CiviCRM.

P.S. This is an automated message, see infra/gitlab issue 20. We understand that automatic responses are annoying, but given the number of open issues as the project evolves, we need a bit of help to triage and prioritise the most relevant issues.

closed

More operators for search kit

Child items ...

Activity