You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a submission is a create submission but is applied as an update, we flag it as a conflict because we want to alert a user look at it and verify the data. We also try to choose good information to show (which properties might have been reverted by applying the create later). We use the existing conflict panels as-is, but this means that there is some confusing and inconsistent messaging.
E.g. the author's view and central's view show the same thing and some text reads "This Submission update was applied to version 1 of this Entity, but it was created based on version 1." When the create-as-update causes a soft conflict (i.e. no properties were changed), the conflict panels look extra confusing because they are brightly colored but don't really seem to show any problems. Maybe in this soft-conflict case, it should not be flagged?
Eventually we would like to handle this situation differently. The important thing to alert the user about is that their data came in extremely delated and the create submission was missing for a bit, and they might have some bigger issue with their process.
We want to first wait and see how common a problem this is, though.
The text was updated successfully, but these errors were encountered:
When a submission is a create submission but is applied as an update, we flag it as a conflict because we want to alert a user look at it and verify the data. We also try to choose good information to show (which properties might have been reverted by applying the create later). We use the existing conflict panels as-is, but this means that there is some confusing and inconsistent messaging.
E.g. the author's view and central's view show the same thing and some text reads "This Submission update was applied to version 1 of this Entity, but it was created based on version 1." When the create-as-update causes a soft conflict (i.e. no properties were changed), the conflict panels look extra confusing because they are brightly colored but don't really seem to show any problems. Maybe in this soft-conflict case, it should not be flagged?
https://staging.getodk.cloud/#/projects/103/entity-lists/colors/entities/8fd9ed10-f082-499a-b466-01957c6a2e7d
Eventually we would like to handle this situation differently. The important thing to alert the user about is that their data came in extremely delated and the create submission was missing for a bit, and they might have some bigger issue with their process.
We want to first wait and see how common a problem this is, though.
The text was updated successfully, but these errors were encountered: