Don't lose search criteria for smart group built with search builder

[konadave]

Overview

Consider a smart group with yes/no criteria, e.g. Do Not Email and Deceased. If you go to 'Edit' the search criteria and it rebuilds the search builder the final values (yes/no) are lost and go back to 'Select'

I'm not sure if it's all yes/no fields or what the cause is but it seems to store the value correctly until you go back to edit and then they are lost - this could cause someone to then update the smart group criteria without realising they've lost values

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

[seamuslee001]

@konadave is this something only happening recently or has it been ongoing?

[konadave]

@seamuslee001 a different developer originally wrote this code for the client approx five months ago. I'm working with said client now and have been asked to submit this PR. I did confirm that it is still an issue on a vanilla 5.47.2 before submitting, and this fixed.

[seamuslee001]

@konadave ok thanks, then I think master is fine, was just trying to figure out if it was in the category of a recent regression or not

[jaapjansma]

test this please

[jaapjansma]

• General standards
  • Explain (r-explain)
    • PASS : The goal/problem/solution have been adequately explained in the PR.
  • User impact (r-user)
    • PASS: The change would be intuitive or unnoticeable for a majority of users who work with this feature.
  • Documentation (r-doc)
    • PASS: The changes do not require documentation.
  • Run it (r-run)
    • PASS: We created a smart group with the condition do not email, deceased and country. We played with different conditions, such as = and /= (is not equa) and different value yes and no. We could replicate this issue in dmaster and not in the test environment of this PR.
• Developer standards
  • Technical impact (r-tech)
    • PASS: The change preserves compatibility with existing callers/code/downstream.
  • Code quality (r-code)
    • PASS: The functionality, purpose, and style of the code seems clear+sensible.
  • Maintainability (r-maint)
    • PASS: The change is trivial enough that it does not require tests.
  • Test results (r-test)
    • PASS: The test results are all-clear.

@colemanw or @eileenmcnaughton can one of you merge this PR?

[eileenmcnaughton]

Thanks for testing this @jaapjansma