Afform - typo when getting options from SavedSearch entity

[ufundo]

Overview

Fix a typo that crashes chain select filters on saved searches.

Example form:

• Create a saved search of Cases

• Create a Search Afform and add filters for Case Type and Case Status. Make the Case Status a chain-select based on the Case Type (because Case Types can define available statuses)

<div af-fieldset="">
  <af-field name="case_type_id" defn="{input_attrs: {multiple: false}}" />
  <af-field name="status_id" defn="{input_type: 'ChainSelect', input_attrs: {multiple: true, control_field: 'case_type_id'}}" />

  <crm-search-display-table search-name="Case_Search_by_Standalone_Admin" display-name=""></crm-search-display-table>
</div>

• Open the form and select a Case Type.

Before

The Case Status selector crashes based on failed Afform/getOptions AJAX call for the Case Status

After

It crashes because the Case BAO can't handle being passed an array of possible case_type_id values, which is an improvement...

TODO

Add test
Find a non-case example where the chain select actually works!

[civibot]

🤖 Thank you for contributing to CiviCRM! ❤️ We will need to test and review this PR. 👷

Introduction for new contributors...

• If this is your first PR, an admin will greenlight automated testing with the command ok to test or add to whitelist.
• A series of tests will automatically run. You can see the results at the bottom of this page (if there are any problems, it will include a link to see what went wrong).
• A demo site will be built where anyone can try out a version of CiviCRM that includes your changes.
• If this process needs to be repeated, an admin will issue the command test this please to rerun tests and build a new demo site.
• Before this PR can be merged, it needs to be reviewed. Please keep in mind that reviewers are volunteers, and their response time can vary from a few hours to a few weeks depending on their availability and their knowledge of this particular part of CiviCRM.
• A great way to speed up this process is to "trade reviews" with someone - find an open PR that you feel able to review, and leave a comment like "I'm reviewing this now, could you please review mine?" (include a link to yours). You don't have to wait for a response to get started (and you don't have to stop at one!) the more you review, the faster this process goes for everyone 😄
• To ensure that you are credited properly in the final release notes, please add yourself to contributor-key.yml
• For more information about contributing, see CONTRIBUTING.md.

Quick links for reviewers...

• ➡️ PR Demo site (can be rebuilt with the command test this please).
• 📖 Review standards
• 🗒️ Review template (brief or verbose)

➡️ Online demo of this PR 🔗

[colemanw]

@ufundo let's go ahead and merge this part now. It's a typo fix and causes bugs so IMO should be against the RC branch.

[ufundo]

ok, have undrafted!

[ufundo]

when you say RC branch, is that 5.71 or 5.72?

[ufundo]

I was slightly worried the fix might cause bugs if anything has been working around this not working?

[colemanw]

@ufundo looks like you need to rebase & force-push this branch to take out the master commits.

[colemanw]

@ufundo I don't think there's any chance this would break something.
I just think chainselects are so rare that no one noticed the bug.

[colemanw]

@ufundo to the other point about fixing the filtering based on case type. See this relevant PR and my comment:
#28957 (comment)

At the time I felt it unnecessary to "go nuts" and load lots of case type definitions... and I'm still a little worried about the performance impact - unserializing xml is notoriously slow and if we do it once or more per row for 50 rows in a SK display... I think we should look at caching.

[ufundo]

@colemanw - thanks, have rebased properly now (was on my phone before...). makes sense re-chain selects being quite rare. I'll comment on the other PR on the other PR 👍

[ufundo]

Oh I didn't actually make the other PR yet...