Support changing of form element type

[mahalakshme]

Need:

Should do when we think we 'll scale up else will become difficult to manage.

Issue:

During testing or when self-service organisations change the form element configuration(Single to Multi-select, repeatable to non-repeatable) of question type(Coded or QuestionGroup) without knowledge, the app breaks.

Approach:

We will introduce new data types(new versions of the concepts) to support the above change. In the current version, we store them differently(eg: single select vs multi select) and hence we cant change. If we store both in similar fashion, it is possible to change. We cant migrate the existing data type to store in similar fashion since migration in mobile app has not provided us with successful results.

AC:

• In the UI(in Concepts page) when Coded or QuestionGroup data type is selected, store it as v2 type(CodedV2, QuestionGroupV2)
• We will deprecate the older one with time. Going forward this new kind of coded concept and question group form elements need to be used
• In the Concepts page, when Coded or QuestionGroup is selected, internally store their new version of data type
• When opening a concept that has v1 of Coded or QuestionGroup used, show it as QuestionGroupOld and CodedOld

• How to display the form element in forms page and how to access the data for rule evaluation, should be determined by the configuration at the form element level

Technical details:

• In this new type, store the data of question group(even for non-repeatable) and coded(even for single select) as an array

Testing:

• Glific message rule that uses value from 2 old and 2 new versions of data types
• form element group rule that uses from 2 old and 2 new versions of data types - in DEA and mobile app
• visit schedule rule that uses 2 old and 2 new versions of data types - in DEA and mobile app

Analysis notes:

• Should we do this as bg job? No, since difficult to migrate client data
• or just disable, - No, might cause confusion
• Handling in product(without migration) doesn't seem to be a good idea since we need to do at rule execution, displaying in both mobile and web app - many places to handle - so No
• disallow only for prod - No, confusion bcoz inconsistent across orgs
• allow when there is no data - No, if allowed, then need to handle during bundle upload since the destination org, may have data
• so just disallow with proper error message(try with new form element/concept) on the workaround

Suggestion:

• One thing I see we can do is, store multi-select, single-select, RQG, QG etc., in the same format ie., array or whatever, and use an attribute to determine the logic what to do
• Need not migrate the existing data, instead when we see a object in place of array, treat it accordingly.
• We cant by default have everything as multiselect since it depends on the business use case.

Inputs:

• concrete egs why it was needed to change
• we 'll not scale now
• There are work arounds for this though it is difficult.