feat: Stage 1 - add parseConfig field to Question and OptionChoice models

[timDeHof]

Description

Added parseConfig JSON field to Question and OptionChoice models to support dynamic text parsing functionality. This enhancement allows for configurable text substitutions in form questions and option choices, improving the flexibility of form content management.

Key changes:

• Added parseConfig JSONB column to Question and OptionChoice tables
• Updated seed data to include parseConfig mappings for:
  • Sprint check-in form emojis (🚀)
  • Yes/No response mappings
  • Likelihood scale labels
• Updated related test files to accommodate the new field

Issue link

Fixes # clickup task 86b3u7wv2

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?

1. Database Migration Tests:

   • Verified successful migration of parseConfig fields
   • Confirmed existing data integrity

2. Unit Tests:

   • Updated and ran sprints controller and service tests
   • Verified mock data handling of new parseConfig field

3. Seed Data Validation:

   • Confirmed proper parsing of template strings in check-in forms
   • Validated Yes/No mappings in form questions
   • Tested emoji substitutions in sprint status options

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

[cherylli]

I don't think form needs a parse option (I know it's in the docs, maybe I was thinking something else when I wrote that, sorry)

The parseOption for choices should be in the option choice model as the options are pulled from there, the group itself won't need one (it's used to group all the options for the same question)

[timDeHof]

I don't think form needs a parse option (I know it's in the docs, maybe I was thinking something else when I wrote that, sorry)

The parseOption for choices should be in the option choice model as the options are pulled from there, the group itself won't need one (it's used to group all the options for the same question)

So we only want it on the OptionChoice model in form.prisma?

[cherylli]

I don't think form needs a parse option (I know it's in the docs, maybe I was thinking something else when I wrote that, sorry)
The parseOption for choices should be in the option choice model as the options are pulled from there, the group itself won't need one (it's used to group all the options for the same question)

So we only want it on the OptionChoice model in form.prisma?

That and question. Anywhere with these things {{ parseOption }}
examples

OptionChoices:

Questions:

So when frontend pull the questions, they will also pull the parseOption Json field in the same table, they use use that to reconstruct the questions

like so,

GET /forms

the response will look like this

"optionChoices": [
      {
        "id": 17,
        "text": "We have had a good start!",
        "parse": { icon: "greenRocket" }
      },

instead of what we have now,

"optionChoices": [
      {
        "id": 17,
        "text": "{{greenRocket}} We have had a good start!"
      },

[cherylli]

code looks good
db push and re-seed ✅
ran all tests ✅