feat: Multiple Parse Options support Stage1b - Add parseConfig to forms response and service models

[timDeHof]

Description

Added support for adding the parseConfig field to fetching of form questions configuration, along with flexibility. This new optional field allows for additional configuration parameters to be stored for different question types, such as:

• Icon-based radio buttons
• Scale questions with custom min/max labels
• Boolean questions with custom yes/no text

In addition, A new wiki page was created called Form Input types v2

The changes include:

1. Added parseConfig field to OptionChoice and BaseQuestion classes
2. Updated form selection queries to include the new field
3. Added proper validation and Swagger documentation

Issue link

Fixes # 86b3u7ygj

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Feature updates / changes
• Tests
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

The changes have been tested through:

1. API endpoint testing to verify parseConfig is properly saved and retrieved
2. Validation of parseConfig object structure
3. Swagger documentation generation
4. Existing functionality remains unchanged

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• I have updated the change log

[timDeHof]

Yes, I agree that its better to keep it just parseConfig, I think I was just trying to find a good way to present it in the examples for the form response. Hopefully the simpler parseConfig example structure in forms response models would make it easier to understand.

[cherylli]

Yes, I agree that its better to keep it just parseConfig, I think I was just trying to find a good way to present it in the examples for the form response. Hopefully the simpler parseConfig example structure in forms response models would make it easier to understand.

I think if needed, we can do something like this,

parseConfig: {
  type: "scale" // could use an enum for this, the type could indicate what values it has
  min: 0,
....

I also noticed just now, most example have no "value" but some has a "value" key. Should we standardize it?

[cherylli]

I see this on my end, 2 levels of parseConfig

but the actual responses are

A couple of tests are failing for me

[timDeHof]

I see this on my end, 2 levels of parseConfig

but the actual responses are

A couple of tests are failing for me

I updated the mock-data for the tests and fix the double parseConfigs.

[cherylli]

Thanks.

Looks good on swagger ✅
Ran all tests locally ✅