Fix inconsistent handling when searching contribution text fields

[eileenmcnaughton]

Overview

I found that if you search on contribution source it adds wildcards & uses 'like' but with cancel_reason not so much, so you need the exact string

Before

After

Technical Details

I found that for contribution_source there was field-specific hacky handling, so I converted both fields
to be metadata based and added handling for string fields on the form layer

Comments

Per the images the qill formatting is inconsistent. This is not made worse by this PR & I would prefer to leave out of scope as I don't think it makes sense to do it without cleaning up the getWhereClause fn

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[yashodha]

@eileenmcnaughton
We need to handle this for invoice number as well

[yashodha]

@eileenmcnaughton
I did a check - quite a lot of text fields like this across searches e.g Member Source, Case Subject, etc
It might be worth generalising this so all search text fields use this.

[eileenmcnaughton]

@yashodha I agree.

The implementation in this PR is actually generalised but the fields need to be 'metadata handled' to get it. Ideally we would convert the rest of the search forms to use metadata handling (currently grant & activity currently do & with this change participant will too). I expect that conversion to be the way we finally rid ourself of jcalendar.

The various text fields also need to be converted - ie we add them to getSearchFieldMetadata

We do need to be a little careful because lots of fields already have their own hack-handling. You can see I had to remove it for contribution_source. So, while I'd like to pick up pace on it I don't think we can do it en mass.

Also note that once the fields are handled by metadata they should be supported as url parameters too.

We still need to add this line

$this->convertTextStringsToUseLikeOperator();

to each form - hopefully the best place to do that will reveal itself, since I would hope it can be moved to the parent class next round.

Big picture, cleaning up the metadata & making it drive forms is one of 2 things we've been doing on an ongoing basis to prepare for an eventual leap in our form layer to something better (the other thing is moving logic out of the form layer & making it api-accessible & tested). Although this is kind of invisible we have made quite a lot of progress, which is evident from the apiv4 & various extensions that are leaning heavily on metadata these days.

(@mattwire @seamuslee001 @colemanw - pinging as this is a long-form comment on something you've all been engaged with)

[eileenmcnaughton]

@yashodha I did just add in invoice_number since that was easy & you specifically tested it. I also note that the defaults thing also needs an extra step to work - that I won't try to add to this PR.

I didn't convert trxn_id since I think we should be going in a different direction with that field - ie exposing the payment field instead

[yashodha]

@eileenmcnaughton
looks good. I tested all the text fields and the search operator is LIKE now

I am happy to merge this :)

[eileenmcnaughton]

Merging per @yashodha feedback - thanks @yashodha