Missing conflict handling when editing / adding / removing contributors

[netsensei]

Bug description

When I add, remove or order a contributor from a publication or dataset which was being edited by someone else; I don't see a warning that a conflict error has happened. However, when I reload the page, I notice that my change weren't saved: I see the changes made by the other person who was editing instead.

Steps to Reproduce

1. Open the detail page of a publication & go to the "people & affiliations" tab (A)
2. Add three new authors.
3. Duplicate the page in a separate browser tab (B)
4. Remove the authors in B.
5. Go back to A and reorder the 3 authors you're seeing.
6. Now add an author in A.
7. Upon hitting the "save" button in the suggest box; notice how the table refreshes however your changes to the ordering are suddenly gone along with the authors who were just there a minute ago.

Automatic testing scenario

Write a high-level way to test this with Cypress if applicable.

Risk classification

Likelihood

Probable

Consequences

Critical. If multiple people add, remove & reorder contributors at the same time, they'll see contributors inexplicably appear and disappear because there's no indication someone else is working on the same record at the same time.

Expected behavior

All mutative actions should give you a conflict error dialog whenever someone else made a change.

[nicolasfranck]

What I noticed in the logs is that NOT conflict resolution is hit, but far before that, the code that checks if the length of the supplied position equals the length of the current contributors:

• https://github.com/ugent-library/biblio-backoffice/blob/dev/handlers/datasetediting/contributors.go#L565
• https://github.com/ugent-library/biblio-backoffice/blob/dev/handlers/publicationediting/contributors.go#L570

That is also a kind of conflict resolution, not? Any way that fails silently indeed.

Possible solution could be to compare the supplied _version against the stored publication/dataset.

Or remove the check on length altogether, and let the version-conflict handle the rest?
If the length is not equal to length in the database, then there is probably a different version, not?
The table of contributors is always reloaded for every action (edit/delete/order) any way.

[netsensei]

Or remove the check on length altogether, and let the version-conflict handle the rest?

Changing the order should create a new snapshot each time. So, this should be treated as a version conflict. I don't think the extra check on length adds value here.

Make sure cypress tests are adjusted accordingly to catch the above case as well.

[verheyenkoen]

Or remove the check on length altogether, and let the version-conflict handle the rest?

Changing the order should create a new snapshot each time. So, this should be treated as a version conflict. I don't think the extra check on length adds value here.

The extra check for length did have it's purpose, since index-based copying over to a new slice without precaution would result in index-out-of-array-bounds errors. I improved the copying to make it safe and removed the check. Now it does display the concurrency error (+ small extra HTMX swapping fix for dataset creators).

[verheyenkoen]

Found another somewhat related bug, described in #1701.