Prevents submissions that are being held for later processing (because of offline entity ordering) are not mishandled
not reprocessed an extra time
not re-enqueued
not causing errors
This PR also tests the (expected) behavior that if an offline branch included create and update, and the dataset required approval before creating the update, that the update would be held until the create submission was approved and applied. (Though it gets pretty hairy on the Collect side to think about keeping all of this information/state in sync when combining approval required + offline. See forum post about ideas for syncing.)
What has been done to verify that this works as intended?
Why is this the best possible solution? Were any other approaches considered?
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
Does this change require updates to the API documentation? If so, please update docs/api.yaml as part of this PR.
Before submitting this PR, please make sure you have:
[ ] run make test and confirmed all checks still pass OR confirm CircleCI build passes
[ ] verified that any code from external sources are properly credited in comments or that everything is internally sourced
Small followup to https://github.com/getodk/central/issues/669
Prevents submissions that are being held for later processing (because of offline entity ordering) are not mishandled
This PR also tests the (expected) behavior that if an offline branch included create and update, and the dataset required approval before creating the update, that the update would be held until the create submission was approved and applied. (Though it gets pretty hairy on the Collect side to think about keeping all of this information/state in sync when combining approval required + offline. See forum post about ideas for syncing.)
What has been done to verify that this works as intended?
Why is this the best possible solution? Were any other approaches considered?
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
Does this change require updates to the API documentation? If so, please update docs/api.yaml as part of this PR.
Before submitting this PR, please make sure you have:
make testand confirmed all checks still pass OR confirm CircleCI build passes