Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Log create-as-update as a conflict #1319

Merged
merged 5 commits into from
Dec 7, 2024
Merged

Conversation

ktuite
Copy link
Member

@ktuite ktuite commented Dec 3, 2024

Closes getodk/central#815

From here:

@ktuite, I think what's happening here is that the entity as a whole is being marked as a conflict, but the API is not returning v2 as a conflict (its conflict property is null). Now that #1251 has been merged, I think we need to update getWithConflictDetails() in a similar way to how it was updated in #1187. There are now three situations in which an entity can be marked as a conflict (described in getodk/central#805), but getWithConflictDetails() only accounts for two of them (here).

Screenshot 2024-12-06 at 4 45 39 PM

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

submission: { instanceId: submissionDef.instanceId }
submission: {
instanceId: submissionDef.instanceId,
...createSubAsUpdate ? { action: 'create' } : {}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe go outside of submission because this is like a Submission object.

Comment on lines 510 to 511
if (createAsUpdate)
v.conflictingProperties = Object.keys(v.dataReceived);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Look at how conflictingProperties is computed and saved in the database over here: https://github.com/getodk/central-backend/blob/master/lib/model/query/entities.js#L307-L320

Don't artificially make up conflicting properties!

.expect(200)
.then(({ body }) => {
body.map(v => v.conflict).should.eql([null, 'hard']);
body[1].conflictingProperties.should.eql(['age', 'label', 'status', 'first_name']);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These will probably change

// Check that entity as a whole is a conflict
await asAlice.get('/v1/projects/1/datasets/people/entities/12345678-1234-4123-8234-123456789ddd')
.then(({ body }) => {
body.conflict.should.equal('soft');
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will change to hard.

@ktuite
Copy link
Member Author

ktuite commented Dec 7, 2024

soft conflict case

Screenshot 2024-12-06 at 4 48 45 PM

@ktuite ktuite merged commit 232a476 into master Dec 7, 2024
6 checks passed
@ktuite ktuite deleted the ktuite/createAsUpdateConflict branch December 7, 2024 01:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants