List how changing a question type will affect existing data

[pld]

The help, http://help.ona.io/faq/replacing-forms-that-have-submissions/, says,

Changing question types; changing the question type of a field should be avoided, because it can affect existing data. For instance, if a question changes from an integer to a select multiple question in the updated form.

• [ ] enumerate all the possible ways that this will affect existing data

[joehand]

@smusula we are interested in changing the field type from text or integer to a select_one.

Two Questions:

• Can we do this without breaking the form (both old data and newly collected data)?
• Will there be any way to edit the existing data after the field type is changed?

Thanks.

[joehand]

@pld @smusula is there any timeline when this will be resolved? We need to update our form and test it before the end of the project (i.e. next two weeks).

Thanks.

[denniswambua]

@joehand @smusula Changing field type from text/integer to select_one does not break the form. But if you want to edit the old data you will only be able to do using the new type i.e select_one.

For a more detailed report see the below link. https://docs.google.com/document/d/1rPDlVpdRAXBqCV_2VdDEnK403CKYs0a9dKDK4LdXXz0/edit?usp=sharing

Note: Changing from text/integer to select_multiple does breaks the form.

[msschroeder]

@pld @rowo @denniswambua It almost seems that this issue was created for a specific project. However, I have some concerns about posting the document with these specific examples for general users. I think the content on the help site: http://help.ona.io/faq/replacing-forms-that-have-submissions/ is sufficient and provides the best guidance to our general user. Thoughts?

[rowo]

@msschroeder Why do you feel this issue was only for a specific project? I kind of see how it could be applicable to all situations where someone wants to replace a form with data and change a question/field type. More detail in this kind of situation where you have a bunch of warnings not to do it is good because it helps the user avoid those problems. The only warning there now, about how "...[changing question type] can affect..." is pretty weak.

Perhaps this doesn't belong in a FAQ, but having it documented somewhere seems desirable. If it's the only place it can go right now, adding another section in that FAQ seems okay. Clear headings will help a reader know if the content is applicable to them. There's no harm in more documentation as long as it's organized well.

[msschroeder]

@rowo This document feels specific to a project with only these specific examples. The effects on the data would be different depending on the change made. We could make this more apparent in the document who the user is so they don't assume any changes made to the question types would have similar effects. However, we may also want to enumerate all/other possible data effects based on how the questions are changed, possibly including the ones that break the forms, if we include these specific examples too.

I agree that right now the faq is still the best location with the current set up of the help site.

[rowo]

Chatted with @msschroeder in Slack. Summary is the doc only covers integer to select one and text to select one which is seems limited to a specific use case.

If we don't want to wait until we enumerate all potential changes (and I don't believe we should) to publish, we can format the flow of https://help.ona.io/faq/replacing-forms-that-have-submissions to be open for continuous edits and seeded initially with the doc content. This means, perhaps:

• two sections for "Okay field type changes" and "Definitely not okay field type changes" (wording up to author)
• cut up doc content and paste into the former category
• putting a few known no-no's, like integer/text to select_multiple into the latter category
• Clear message that all other field type changes not listed in either category aren't tested yet.
• Keeping the communication around everything is still at your own risk

[msschroeder]

@rowo I think for https://help.ona.io/faq/replacing-forms-that-have-submissions to house the effects of the potential changes to field type as in document would make it really long especially over time if we continue to add the potential effects of all changes. Therefore I propose (adding to your proposal):

• Having a separate document such as the later that will be a continuously edited document
• Generalize that document:
  • Have the two categories "Okay Field Type Changes" and "Definitely Not Okay Field Type Changes"
  • Add known dos/don't into respective categories
  • Clear message that all other field type changes not listed in either category aren't tested yet. Keeping the communication around everything is still at your own risk
• Link the first document to the later for those interested.

[msschroeder]

@rowo The changes as listed above have been changed to the document. Please review.

Google Doc: https://docs.google.com/document/d/1rPDlVpdRAXBqCV_2VdDEnK403CKYs0a9dKDK4LdXXz0/edit?usp=sharing

[rowo]

@msschroeder Overall structure looks fine. I don't think I understand the specifics enough to identify errors, so if that needs to be done, please have someone with more background review it.