[Fix] Node pending state when choice is attribute ancestor

[BPierrick]

Fixes

• Fixes #719

Definition of Done

• [x] I followed the Arkhn Code Book (I swear!).
• [x] I have written tests for the code I added or updated.
• [x] I have updated the documentation according to my changes.
• [x] I have updated the deployment configuration if needed.

[simonvadee]

I don't understand the fix sorry, can you explain a bit more ? maybe a small unit test would have helped me to understand

[BPierrick]

I don't understand the fix sorry, can you explain a bit more ? maybe a small unit test would have helped me to understand

The problem was not related to the text length, but to the useIsNodePending algorithm.

• At first, we checked all attributes' paths and if the current node's path is contained in the attribute's path, then this means the current node is pending.
• For multiple-choice nodes, this logic doesn't work because if node's path is value[x] and that the attribute one is valueBoolean, the node's path is not part of attribute's path.
  • So this algorithm has been made to support this edge case. But it supported it ONLY if the attribute was a DIRECT child of the current node. This fix should allow having N levels between the attribute and its current node ancestor.

• If we take this example, current node path is value[x] and attribute's path is valueQuantity.value
• At first, to check if current node is parent of attribute we checked in its children if there is one having the same path, ie if one of its child has path valueQuantity.value.
  • In this case it doesn't work
• So instead, we check if one of its children has a path that is included in attribute's path : ie value[x] has a child path valueQuantity that is included in attribute's path valueQuantity.value

[simonvadee]

ok thanks for the clarification. I have one question though: don't you think that multiple attributes can start with the same string without sharing the same ancestor ? Sorry I don't have a real world example but I can make up one:

• Observation.value[x]
• Observation.valueAbsentReason (does not exist for real but imagine) they start with the same path Observation.value yet they do not share a common ancestor. wouldn't that be a problem ?

[BPierrick]

This example wouldn't raise any issue in my opinion. Moreover I'm not sure I completely got it because Observation.value[x] and Observation.valueAbsentReason do share a common ancestor, which is Observation.value[x] right..?

This one though would be a problem :

• Observation.value
• Observation.valueAbsentReason
• Observation.value is NOT an an ancestor of Observation.valueAbsentReason.

I don't really identify any other edge case. And I don't think this one is likely to happen..?

[simonvadee]

no I was talking of the case where Observation.value[x] and Observation.valueAbsentReason would not share a common ancestor (be 2 different attributes) --> the same case as your example. I don't know if this is likely to happen but I would say it's possible

[BPierrick]

Well yes, in that case if Observation.valueAbsentReason is not a choice of Observation.value[x], then this would lead to a bug.

I think either we consider this algorithm and we suppose this would never happen. Or we would need to perform a tree search to effectively check if the nodes are common ancestors, but this solution would be more expensive.