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
Removing contributors from a publication/dataset works position based. This could lead to wrong data if two users decide to remove the same contributor at the same time (eg. during a meeting).
Steps to Reproduce
Open a publication/dataset with multiple contributors (authors/creators, editors & supervisors) in the contributor view.
Duplicate the page in a new tab.
From both tabs, delete the same contributor.
The result depends on which positional contributor you removed:
If you didn't remove the last contributor, two different contributors will have been removed. This is a big problem since the second person executing the remove, actually removed a different contributor than the one they clicked the delete button on.
If you did remove the last contributor, the second user to do so will see that the confirm dialog does not close and nothing is refreshed. The AJAX call to confirm the remove will cause an internal server error (that HTMX won't process) because they delete a contributor at a position that doesn't exist.
Risk classification
Likelihood
2: Probable
Consequences
2: Critical
Expected behavior
Not sure if we also want to show the concurrency error dialog here (for the second user executing the remove), or if we just want to refresh the contributors with the current state, which is the state that the user expects anyway.
Additional context
Bug discovered while working on reordering concurrency bug (#1568).
The text was updated successfully, but these errors were encountered:
Found an additional problem here (probably caused by the same bug): when one user reorders contributors and another user removes a contributor from an unrefreshed view, the wrong contributor is removed. This should result in a conflict error dialog I guess and force the second user to refresh first.
Bug description
Removing contributors from a publication/dataset works position based. This could lead to wrong data if two users decide to remove the same contributor at the same time (eg. during a meeting).
Steps to Reproduce
Risk classification
Likelihood
2: Probable
Consequences
2: Critical
Expected behavior
Not sure if we also want to show the concurrency error dialog here (for the second user executing the remove), or if we just want to refresh the contributors with the current state, which is the state that the user expects anyway.
Additional context
Bug discovered while working on reordering concurrency bug (#1568).
The text was updated successfully, but these errors were encountered: