Dynamic search suite changes

[stephherbers]

Product Description

Ticket: USH-3666
Part 1 of HQ changes at add dynamic search as a app-level config and add to query request in suite file

Part 2 HQ changes here
Formplayer/core changes: here & here

review by commit

Technical Summary

I added the flag as default to "False" for the app-level config, but really we'd ideally want this true if the FF is true, but I couldn't get the default value to be based on a FF so if you have a better way let me know. Note: from the UI perspective it is set to True, but my understanding is that would override the default value of False if and only if the UI is navigated to and saved.

Note: dynamic search should be disabled for all modules that contain autoselect due to incompatibilities of the features

Feature Flag

DYNAMICALLY_UPDATE_SEARCH_RESULTS

Safety Assurance

Safety story

This is behind a FF and nothing changes logically other than adding a value to the suite file

Automated test coverage

Yes, suite coverage and translation for app UI (no other automated tests for app UI)

QA Plan

I am not thinking of requesting QA

Rollback instructions

• This PR can be reverted after deploy with no further considerations

Labels & Review

• Risk label is set correctly
• The set of people pinged as reviewers is appropriate for the level of risk of the change

[nospame]

This looks good to me as long as it's coordinated timing-wise with the Formplayer/core changes (those have to come first, right?) Also still see

 FAIL: corehq.apps.app_manager.tests.test_suite_inline_search:InlineSearchShadowModuleTest.test_suite

despite changes to test XML, but would feel fine approving once it's addressed.

ideally want this true if the FF is true, but I couldn't get the default value to be based on a FF so if you have a better way let me know.

I assume this would probably need a data migration.

[stephherbers]

ideally want this true if the FF is true, but I couldn't get the default value to be based on a FF so if you have a better way let me know.

I assume this would probably need a data migration.

I think I'm more talking about after the fact that's it's implemented, because with the logic right now, once someone enabled the FF on the environment the default value would still be false when ideally at all times the FF is turned on this would switch. Does that make sense?

[orangejenny]

Code looks good overall.

I added the flag as default to "False" for the app-level config, but really we'd ideally want this true if the FF is true, but I couldn't get the default value to be based on a FF so if you have a better way let me know.

I don't think this is possible, since the user/domain isn't available when the default attribute value is set. (We do have code to get the current global request, but this doesn't seem like a strong enough reason to go mucking around in global-level code.)

Note: from the UI perspective it is set to True, but my understanding is that would override the default value of False if and only if the UI is navigated to and saved.

Can you update that? The UI should match the true value. I think changing the value in the yaml file will do it.

Is there test coverage for the new behavior? I was expecting to see dynamic_search="true" in test code somewhere.

[stephherbers]

Note: from the UI perspective it is set to True, but my understanding is that would override the default value of False if and only if the UI is navigated to and saved.

Can you update that? The UI should match the true value. I think changing the value in the yaml file will do it.

Updated 81542a2

[nospame]

I think I'm more talking about after the fact that's it's implemented, because with the logic right now, once someone enabled the FF on the environment the default value would still be false when ideally at all times the FF is turned on this would switch. Does that make sense?

Ahh I get it now, that makes sense.

[stephherbers]

@nospame @orangejenny changes made since last approval. Edit: remembered the trick for multi-line strings: #33622

[orangejenny]

This reminds me we might want to split out a "web apps" section and/or rename the android section to something like "UI", but that's not part of this PR.

[stephherbers]

formplayer and core merged