Open-event-server: Propose and Implement a schema for complex custom forms

[CosmicCoder96]

Current custom forms are really restricted, and rigid. Only text fields are available, along with hardcoded dropdowns. Further, the user is only able to select from among the hardcoded fields and toggle them on/off for his/her event.

We already have the framework to associate simple custom fields with individual events or orders, and an API to create them. The custom forms schema needs to be now expanded to allow more complex fields. Taking Google forms and our use case as an inspiration, the user should be able to create the following fields:

• Simple text *
• Paragraph *
• Radio Buttons (single choice)
• Checkboxes
• Dropdown
• File upload *
• Time
• Date
• Date & Time

* Already implemented

The schema needs expansion to accommodate options for fields like dropdowns, checkboxes and radio buttons.
Also, to store custom labels to the fields, which the user assigns. Currently, they are hardcoded by comparing the name of the field with if-else.

-- First, plan the schema refactor completely, before beginning to code it. Get @niranjan94 and @iamareebjamal to review it, and once it's finalized, proceed with it.

-- Design the schema while writing appropriate migrations to take care of legacy data on the server.

-- use this parent issue as for all discussions, and queries.

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label feature to this issue, with a confidence of 0.98. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[CosmicCoder96]

CustomForms are not truly custom, they can only be toggled on and off, as the field options available in custom forms are hardcoded in the user, event and attendee schemas.
Here onwards, complex custom form fields refer to fields which are not predefined in the system, but the user will create them.

Proposed Schema Changes
Add a separate model called customFormOptions to store various options of radio buttons, checkboxes, and dropdowns.

They will have the following fields:

| Column | Description |
|---------|-------------|
| ID | default unique ID |
|value| value of the custom form field options like 'XS, XL'
|custom_form_id | foreign key - the id of the custom form field this option belongs to |

CustomForm model will have a hasMany relationship with customFormOptions.

For text fields, and other fields which don’t require options within them can have the relationship as null.

The changes to customForm Model itself:

| Column | Description |
|---------|-------------|
| description | An optional simple string column to store the custom messages/info the user may give to the custom form field like T-shirt Size Chart link etc.|
| isComplex | Boolean field to indicate if a particular field is complex |

The changes to user Model:

@niranjan94 Advised using a JSON column, to store the values of all the complex custom fields present for a model.

| Column | Description |
|---------|-------------|
| customFormValues | A JSON type column which stores all the complex custom form values(currently all the fields offered are hardcoded in the schema) |

@iamareebjamal Please provide your feedback.

[iamareebjamal]

Yes, a JSON field will be more efficient than having to join all the options everytime a fetch happens. This field can be null for text type form option.

Also, I'd like to club the default form options issue with this one. For example, in attendee custom form, the required fields like first name, last name and email are only required in FE, not in server, which breaks the model when the custom form is created using only API

6235 will fix it for attendee form, but a better and general solution is needed