Start thinking about backward compatibility!

[asoskic]

No description provided.

[asoskic]

• loading old files into new web-app
• security if JSON files can uploaded (should JSON files be legible or protected)

[asoskic]

One major thing: adding or removing top levels of branching structures can create a problem because lower-level things become dependent and e.g. can be missing from a report and should be loaded in a new version

[asoskic]

Suggestion from Lazar for adding and editing new questions to allow for compatibility between versions - question editing happens in an admin panel, so that even the person editing the template contents does not have control over the unique ID and it is crystal clear when a new question is added or when an existing one is edited (or even discontinued, when the order is changed etc)

[asoskic]

See also issue #30

[asoskic]

Johannes had the following comment about this when we were writing the paper on ARTEM-IS for ERP, which might be worth saving for later:
"How about backwards compatibility/ unique identifiability of each question/ response? We talk earlier about the ARTEMIS template facilitating the comparison of different studies. But if someone answers "other" now and someone two years later answers something else that was previously included in the "Other" category, does the app break? I think you mentioned that every question/ response got it's unique identifier, so I believe this can be handled somehow... But it's for sure something reviewers might be concerned about)."

@Remi-Gau also mentioned another thing worth keeping in mind: it may make sense to give answer options that should go in the end of a multiple choice list, such as "Other", very high ID numbers (e.g., 99), which we are unlikely to reach ever. That way, these values would not change from version to version if we add new options before "Other".