GR-Lot-SelectionCriteria rules are only shown for the first group

[luispozoWS]

For the fields of GR-Lot-SelectionCriteria that are mandatory the schematron only gives us an error the first time, for the first group. There are no errors shown for a second GR-Lot-SelectionCriteria
Our developers tell us that is due to how the rule is written :

rule|text|BR-BT-00747-0022

Schematron control is linked to " eFormsExtension" that is not a group. The control can only happen once (for the first group), no matter how many GR-Lot-SelectionCriteria groups are created.

Is it normal ?

Best regards

[YvesJo]

Hi,
Groups are in fact defined for display purpose and may or may not be associated to nodes, Sometimes also the node associated to Group a field is in, may not actually be the one defined for the rule/field.
Rules are triggered based on contexts which could be nodes or fields, not Groups.
To be able to answer your question, I invite you to get in touch with the helpdesk and provide the XML instance along with a short description of how you proceed, and what you expected but didn't observe.
KR

[luispozoWS]

I can give an example

"BT-500-Organization-Company is mandatory in notice type 16" is shown 3 times if 3 organizations are created and the 3 fields aren't filled.

For "Type (BT-747-Lot)" in GR-Lot-SelectionCriteria the schematron error "BT-747-Lot is mandatory" is only in the first group, not for a second group. Is it normal ?

[YvesJo]

Hi,
The context for the BT-500-Organization-Company is the parent node and every time that node exists, the presence of the field is checked.
The context for the rule on BT-747-Lot can not be the parent node and has to be an ancestor because it is the entry point for selection criteria from which the existence of all other related fields is not allowed. If the rule would apply on the parent node, then in absence of the parent, the rule wouldn't get fired and the absence of BT-747 wouldn't get detected. The use of an ancestor allows to enforce the presence of that field.
The selection criteria CM/CF rules (dependency rules) prepared with the early SDK are one of the rare cases not part of the progressive "Conditional Rules" reactivation process, because of the latest amendment. These rules would have prevented the specification of any other selection criteria field (and de facto the one of the shared parent) in the absence of BT-747.
I guess this is the ground cause for the observed behavior. For confirmation and/or further details, do not hesitate to share the XML instance and any other useful information via the helpdesk.
KR