after initial sync completes click Sync button again
expand Sync diagnostic panel
Expected result
no checksum mismatches.
Actual Result
checksum mismatch on a childForm always shown (see attached)
Analysis
A long time ago, a predicate was added to all sync soql queries – Job__r.Id != null
This applied to any job relationship regardless of name.
This was created to enforce sharing of Jobs against FxForms which did not have a master detail relationship with job.
Later, we added FX5__Job__c to all packaged grandchildren of Job. So long as the field was not accessable or it had a value, the checksum would work correctly. But when the Job field is exposed and it is empty, it will force the checksum to fail.
On top of this we are also adding a predicate for FX5__IsArchived__c, so the checksum code will have to change regardless.
Related Cards
Test Plan
card rejected
installed beta MP
04t1Y000001I9DqQAK
checksum mismatch after incremental sync was still shown on sync diagnostic (see attached checksumMismatch.JPG)
Mingle Card: 5980 Steps to reproduce
Expected result
no checksum mismatches.
Actual Result
checksum mismatch on a childForm always shown (see attached)
Analysis
A long time ago, a predicate was added to all sync soql queries – Job__r.Id != null
This applied to any job relationship regardless of name.
This was created to enforce sharing of Jobs against FxForms which did not have a master detail relationship with job.
Later, we added FX5__Job__c to all packaged grandchildren of Job. So long as the field was not accessable or it had a value, the checksum would work correctly. But when the Job field is exposed and it is empty, it will force the checksum to fail.
On top of this we are also adding a predicate for FX5__IsArchived__c, so the checksum code will have to change regardless.
Related Cards
Test Plan
card rejected
installed beta MP