...
The Feature will be enabled/disabled for a particular category using the flag “allowBranching“ with the value “Yes/No“
The flag allowBranching will be stored at object level schema with default to “No“ and same can be overridden for specific category at category definition level.
A dependent question can be added only for questions available within the immediate parent. It means we can't target question available with other parents within observation/survey hierarchy.
The rule (branchingLogic) will be available with the immediate parent (section or root node)
The branchingLogic will be stored
in the hierarchy itself, if available at section/unit level.
in the hierarchy & graph, if available at root level (Observation/Survey)
“branchingLogic“ will be added to QuestionSet object level schema as an optional property.
“branchingLogic” will be accepted by the platform only if “allowBranching” is set “Yes”.
Sample value of branchingLogic is as below:
| Code Block | ||
|---|---|---|
| ||
{{ "allowBranching": "Yes", "branchingLogic": { // Renamed from render config "questionId_do_1": { // Only parent or child questions will be stored here. "target": [ "questionId_do_2" ], "preCondition": {} }, "questionId_do_2": { "target": [], "source/parent": ["questionId_do_1"], "preCondition": { "and": [ // Use of JSON Logic library { "eq": [ // eq, ne, lt, gt, exists, not_exists, and, or { "var": "do_1.response1.value", ""type": "responseDeclaration" }, "0" ] } ] } } } } |
target : all target question id's will be stored here.
preCondition: rule or set of rules for question response assertion
“branchingLogic” will have entries for only those objects which have a dependent question and a dependent one.
Dependent Question should be added only through update hierarchy api as well as addNodeToHierachy api.
Question with visibility Parent/Default can be added as a dependent question.
ES Syncing will be disabled for the field “branchingLogic” through an existing config in search-indxer job.
Platform will support the merge operation for “branchingLogic”. So any partial update for branchingLogic will be supported.
compatibilityLevel for observation & survey categories will be set as current + 1 . i.e: 6. So that user will be forced to update the app, when observation/survey consumption will go live.
When The player starts playing a survey/observation, It should start rendering using hierarchy index as well as branchingLogic.
Question Index needs to be handled explicitly at player end as hierarchy index may be different for question which becomes visible first. the same will be applicable for dependent question as well.
Solution of Progress tracking/score computation for dependent question will be designed and taken up later before consumption start.
...
Sample Request for adding dependent question (q2 depends on q1):
| Code Block |
|---|
{
"request": {
"data": {
"nodesModified": {
"section1": {
"isNew": false,
"root": false,
"metadata": {
"branchingLogicallowBranching": {
"Yes",
""branchingLogic": {
"q1": {
"target": [
"q2"
],
"preCondition": {} // this will be empty
},
"q2": {
"target": [], // this will be empty
"preCondition": {} // this will have required rule.
}
}
}
},
"q2": {} // metadata for question q2
},
"hierarchy": {
"survey-1": {
"name": "survey 1",
"primaryCategory": "Survey",
"children": [
"section1"
],
"root": true
},
"section1": {
"name": "Section 1",
"primaryCategory": "Survey",
"children": [
"q1",
"q2"
],
"root": false
}
},
"lastUpdatedBy": "5a587cc1-e018-4859-a0a8-e842650b9d64"
}
}
}
|
deleteFromHierarchy:
deleting a dependent question:
delete from hierarchy
<update all the targets> - using the source property
delete the entry of the question from branching logic
deleting an independent question:
if the question has targets, throw an error…
the dependent questions should be deleted first and then the delete should be triggered again
if there are no targets, delete the node from hierarchy, remove the entry from branchingLogic
HierarchyManager.removeLeafNodesFromHierarchy() function will be modified.
...
Syncing for sections needs to be enabled (not yet implemented).
The job needs to validate the object by using combined schema (object + category)
DSL for branchingConfig
With reference to the third-party library JSONLogic, we will compose the logic for precondition as shown below:
...