Creating an entity by an update form and sending registration form afterwards results in conflict with missing information

[dbemke]

Problem description

I created an entity by submitting only an update form (waited till it's force-processed) and then I sent the registration form. In the entity detail page there's a conflict but in the "Data updates in parallel" table there's "There are no conflicts to show".

URL of the page

e.g. https://staging.getodk.cloud/#/projects/101/app-users

Steps to reproduce the problem

1. In Collect add user "children” https://staging.getodk.cloud/#/projects/101/app-users
2. Set auto send to "off”.
3. Fill and finalize child-ony registration without age const form.
4. Go to Child update form an update the created entity, finalize the form.
5. Go to "Ready to send” and select the update form and send it.
6. Wait for force-processing the submission/entity in the backlog.
7. Send the registration form

Screenshot

Expected behavior

"Data updates in parallel" table should contain information about the conflict

Central version shown in version.txt

https://staging.getodk.cloud/
versions:
51a3e10 (v2024.2.1-4-g51a3e10)
+bb2b2325c5fde4e1325e0d0fcec9c3db6a58cfd7 client (v2024.2.1-35-gbb2b2325)
+57c4da581a21928eb21fef8097f72870af6e4d4d server (v2024.2.0-83-g57c4da58)

[matthew-white]

@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 getodk/central-backend#1251 has been merged, I think we need to update getWithConflictDetails() in a similar way to how it was updated in getodk/central-backend#1187. There are now three situations in which an entity can be marked as a conflict (described in #805), but getWithConflictDetails() only accounts for two of them (here).

[ktuite]

I tried out what it would look like to take the above scenario but mark the 2nd version as a soft conflict with no conflictingProperties and honestly it's even more confusing:

There's not really a traditional conflict because there isn't a 3-way thing happening (except with the state of entity-non-existence?) so the orange info box on the update submission looks strange.

What I think needs to be communicated is "ALERT! This create action came in late and was applied as an update!"

[ktuite]

I'm trying some other hacks/experiments. In this case, I'm setting conflictingProperties to ALL the properties mentioned in the (create-as-update) submission and it feels like it's on the right track but also buggy.

Because it's a create submission

• it includes things the followup submission (that came in first) didn't have like tag and species
• it also overwrote (and made empty) certain fields like ??? i can't actually find any fields it overwrote here
• weird bug species showing empty -> filled in? oh that's because it's in the form but NOT update by that monitoring form

Augh, I'm a little lost, but I maybe this is doing a reasonable thing:

• mark conflict on version as soft (or even hard)
• set the conflicting properties to all the properties of that submission's data
• those changes will show up in the lower table

[ktuite]

I'm now happy with my approach in PR getodk/central-backend#1319

[dbemke]

Should the steps from the issue result in the hard conflict?

[dbemke]

If there's a conflict (like the one described in the issue above) and there's a change in properties from empty to some values, should there be the red icon with the exclamation mark on this property?

[WKobus]

I created soft conflict by sending update form before registration form, force processing backlog and then sending registration form, both registration form and update form had same entity properties, in soft conflict there is information "There are no changes to show" Is it expected?

[ktuite]

1. I believe so -- if any of the properties change, it should be a hard conflict

Should the steps from the issue result in the hard conflict?

2. This looks ok to me how an empty value that gets filled in as shown but doesn't get the red exclamation mark.

If there's a conflict (like the one described in the issue above) and there's a change in properties from empty to some values, should there be the red icon with the exclamation mark on this property?

3. I decided to make this last part into it's own issue (for a later release) because this soft-conflict case where there isn't really a problem looks extra confusing: Show clearer information about create-as-update conflicts #835 When handling that case, we could also figure out exactly what we want to do for the more conflicting situations, too.

I created soft conflict by sending update form before registration form, force processing backlog and then sending registration form, both registration form and update form had same entity properties, in soft conflict there is information "There are no changes to show" Is it expected?

[dbemke]

Tested with success!

[WKobus]

Tested with success!