Fix improper survey metadata generation when using booleans

[VirajP1002]

What is the context of this PR?

Previously test_metadata_routing.json was failing to open because flag_1 (now changed to boolean_flag) wasn't being included within survey_metadata however it was included as top level metadata leading.

In order to fix this issue, the logic in getSurveyMetadataFromClaims was flipped where metadata in claimValues that is not top level metadata is considered to be survey metadata.

claimValues used in getSurveyMetadataFromClaims did not contain boolean_flag when unticked in launcher (set to False) and so the logic where boolean_flag is added back to survey_metadata for token generation in GenerateTokenFromPost had to be changed as the previous implementation added boolean_flag into top level rather then in survey_metadata.

launch.html was updated to ensure that the form submission doesn't contain unwanted metadata.

How to review

• Ensure the changes made are suitable

• Run Launcher and Runner locally and ensure test_metadata_routing.json opens when boolean_flag is set to True/False in the Launcher UI.

• Ensure boolean_flag is not put in top level metadata, do this by adding a breakpoint to line 110 in sessions.py in Runner, open launcher and open test_metadata_routing.json. In the debug window, select decrypted_token and check that boolean_flag is within survey_metadata and is the correct value.

• Check the loaded values on the launcher UI are correct, do this by adding metadata to a schema such as { "name": "test", "type": "date" }. Load up the launcher UI and check that it has been added in the Survey Metadata section with a value in the field. The same can be checked for altering the type to string,uuid or url. If you run Runner in debug mode, you can check the token to ensure test in within survey_metadata.

• Check test_metadata_routing opens in quick-launch, add an additional piece of metadata (similar to the one above) to the schema and run Runner in debug mode. Enter the url into the browser and check that the survey_metadata is correct, it should match the one from the UI. You can also add additional arguments to the URL or override an existing piece of metadata and ensure the survey_metadata section is correct.

• Ensure changes do not break other schemas, e.g. test_supplementary_data, or any business/social surveys

[VirajP1002]

Bug: Launcher improperly generating survey metadata

[berroar]

Looks good so far, but as per the ticket we need to implement this part as well: If a key type is unknown, and therefore launcher doesn’t have a default for it, use the type of the metadata value to auto-generate something suitable. At the moment, for strings Launcher is sending an empty string e.g. "", but if you added a new metadata with a type like date to metadata in your test schema, the launch would fail as there would be no value set (as no default exists). So we need to dynamically generate values based on the type

[MebinAbraham]

Not directed at your changes, but this highlights how much of a mess the current Go logic is. Unnecessary complexity and confusing logic in quite a few places. Even though it is a dev tool, it might be worth us doing a refactor.

[VirajP1002]

Not directed at your changes, but this highlights how much of a mess the current Go logic is. Unnecessary complexity and confusing logic in quite a few places. Even though it is a dev tool, it might be worth us doing a refactor.

I would say it's quite messy by the fact it's hard to navigate, for example going to method calls and definitions is odd as it jumps around the page and that some v1 methods are still there.

[petechd]

All the issues above seems to be resolved and all the functionality (scenarios) mentioned work as expected, code is hard to follow but not because of PR creator's design.