[REF] Afform - Code cleanup in LoadAdminData API action

[colemanw]

Overview

Minor code simplification and added docblocks in the loadAdminData Afform API.

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

[eileenmcnaughton]

@colemanw looks simple - I can r-run if you confirm where I would see it

[colemanw]

@colemanw looks simple - I can r-run if you confirm where I would see it

@eileenmcnaughton if you add a search display that has 1 or more field transformation in the search, you should still see the transformed field in the afform when creating a form for the display.

[eileenmcnaughton]

My transform isn't working - but it's pre-existing - ie 'amount' is not getting MATH options - trying another field

[eileenmcnaughton]

Possibly this is also pre-existing

[eileenmcnaughton]

@colemanw I was able to add & select a date field & transform to YEAR - the transform options for date field also seemed a bit confusing - ie

but 'LOWER CASE still leaves the only cased thing in the date in upper case & I'm not sure what the MATH ones would mean in this context

[eileenmcnaughton]

@colemanw so the summary is - I think that all the things I spotted testing this are unchanged by this & if you are happy that is the case then go ahead & merge

[colemanw]

Hoo boy, those are a lot of issues with the transforms. I think a lot of the issue is that not all sql functions are appropriate for every field and the UI needs to do a better job of making that clear.
Another part is that pseudoconsant matching happens in the post-processing not the sql query so UPPERCASE(financial_type_id:label) isn't going to work as expected. If we worked at it a bit I think it could be fixed but yea that's currently broken.

[eileenmcnaughton]

@colemanw I suspect once we can do them on combined fields the issues will change again so maybe it's worth figuring out that first

[colemanw]

Well there is a way to do pseudoconstants in SQL, by rewriting the query to use FIELD() like this:

civicrm-core/Civi/Api4/Query/Api4SelectQuery.php

Lines 318 to 327 in 1930b3e

	// Use FIELD() function to sort on pseudoconstant values
	$suffix = strstr($item, ':');
	if ($suffix && $expr->getType() === 'SqlField') {
	$field = $this->getField($item);
	$options = FormattingUtil::getPseudoconstantList($field, $item);
	if ($options) {
	asort($options);
	$column = "FIELD($column,'" . implode("','", array_keys($options)) . "')";
	}
	}

I don't know how it would impact performance if we switched them ALL to work that way. We could switch the ones inside functions to do so though, and that would get things like UPPERCASE working.

[eileenmcnaughton]

@colemanw I guess that's the question isn't it - should they all work in sql or should we do some parts in php. I guess that's why I think working on combining the fields makes sense - because whether you hit the limits of mysql in there might drive that answer