I have a somewhat uncommon situation where accountName is not used as the prefix with UPN and Email address. When I put in the conflict filter of /Person[starts-with(Email,'[//Value]@')] the workflow crashes within the SetAttributesToReadForConflictResources method.
I looked into the source code for that function and it seems that is expects the Starts-With to only include the [//Value] and not [//Value]@. In this case the @ is necessary since we're searching only the prefix of the email address. Without the @ included in the Starts-With, a unique value of JSmith may incorrectly return a conflict with an email address of JSmithfield@domain.com.
The code below shows the endToken where it expects only '[//Value]' and won't support '[//Value]@'.
string endToken = "'[//Value]'";
Could someone look at parsing the Starts-With in a better way? Simply removing the trailing ' would work for my situation. Consider using the first index of , after the "Starts-With" string (startIndex value) as another possibility.
I have a somewhat uncommon situation where accountName is not used as the prefix with UPN and Email address. When I put in the conflict filter of /Person[starts-with(Email,'[//Value]@')] the workflow crashes within the SetAttributesToReadForConflictResources method.
I looked into the source code for that function and it seems that is expects the Starts-With to only include the [//Value] and not [//Value]@. In this case the @ is necessary since we're searching only the prefix of the email address. Without the @ included in the Starts-With, a unique value of JSmith may incorrectly return a conflict with an email address of JSmithfield@domain.com.
The code below shows the endToken where it expects only '[//Value]' and won't support '[//Value]@'.
string endToken = "'[//Value]'";
Could someone look at parsing the Starts-With in a better way? Simply removing the trailing ' would work for my situation. Consider using the first index of , after the "Starts-With" string (startIndex value) as another possibility.