When authenticate_easyiq_session cannot produce a child list (_easyiq_children_known stays False), the reads fall back to the old guessed identifiers with no SwitchChild. For a guardian with one child this is harmless and keeps institutions that omit child working, which is why the fallback exists.
For a guardian with several children it reproduces the #68 bug: every child gets whatever the session answers, which can be another child's rows. Wrong data is worse than no data.
Suggestion: gate the fallback on child count. One child, keep the current behavior. Several children, refuse the read with a message saying the portal did not identify the children, instead of showing rows that may belong to a sibling.
When
authenticate_easyiq_sessioncannot produce a child list (_easyiq_children_knownstays False), the reads fall back to the old guessed identifiers with noSwitchChild. For a guardian with one child this is harmless and keeps institutions that omitchildworking, which is why the fallback exists.For a guardian with several children it reproduces the #68 bug: every child gets whatever the session answers, which can be another child's rows. Wrong data is worse than no data.
Suggestion: gate the fallback on child count. One child, keep the current behavior. Several children, refuse the read with a message saying the portal did not identify the children, instead of showing rows that may belong to a sibling.