Cascading list question type

[rocketboy76]

Create a new question type that allows selection from a cascading list of choices. Each level of choices could be columns of a grid where the rows are unique combinations. For example:

Question 1 Question 2 Question 3 A x i A x ii A y iii B z iv B z v B z vi

So, when using the question in a form, it could go like:

Question 1: A / B Question 2: x / y Question 3: i / ii

Or other sensible combinations.

[grassick]

My proposal after discussions with @Autio this morning:

• Allow adhoc tables that can be uploaded from XLSX and edited in portal. Data for cascading questions must be stored in one (do we allow inline data as well as an alternative? would need to be quite limited in size. Also, can data be re-uploaded? How to keep ids consistent?)

• Cascading questions reference a particular table, perhaps with a filter

• Caching is not automatic (unless flag is set in question? tricky if so) but is done in app config which has expanded caching abilities that can be set by user/group and can include a subset of data.

This is quite involved altogether:

• Add adhoc tables to server (mongo interface, jsonql, schema, create/alter)
• Add adhoc table upload/editing/management to portal
• Expand forms and form designer for new question type
• Extend caching capabilities of app configs

[grassick]

For simpler, inline version that supports ~1000 rows, questions are:

1) Is this about a) selecting a particular option from the list, or is it b) cascading questions? e.g. if a user selects province/district/city, can a later question be conditioned on province? Does each combination have a unique name, or is it really 4-5 distinct questions crammed into one question?

2) Can levels be skipped? e.g. can some options only have province/city, skipping district?

3) If 1(b), then does this need to be robust to spelling fixes? e.g. if a province spelling is corrected, does that invalidate all options? If not, then each level will need a stable id as well as the overall selection.

4) How is the list updated? Is there an editor or is a re-upload required? If re-upload, how are options reconciled with existing options to keep the ids stable and prevent orphaned response values?

5) Options are localizable, right?

6) Can a user select only a province with no district or city if such a combination is not in the uploaded data?

If we go with 1 (b), then this makes the adhoc version much more complex, as that one is fundamentally about selecting a single row from a table. We could maybe select a single option under the covers and then expose the parts (province/district/city) as enum fields for the local version.

[grassick]

Sizes: 1400 villages with 4 levels: 50K uncompressed, 10K compressed. Some surveys are already 1.5MB uncompressed, so perhaps this isn't too bad for scaling.

[grassick]

After speaking with @rocketboy76, we should definitely do 1(a). We can expose the various levels as well to simplify conditional questions.

• Level names need to be localized
• Editing is tricky and needs to distinguish between editing a label and changing it.