Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Updated: Comment #1
The Views interface locks itself if two users try to edit the same view. The "locked out" user however still has access to the "Save" and "Cancel" buttons. Clicking either button will immediately break the lock and either save the view, or discard the other user's changes. Considering clicking the Cancel button is the most natural thing for a user to do if someone else is already editing the same view, this seems like it could frequently lead to loss of in-progress configuration.
Problem/Motivation
To reproduce:
- Install D8, create a second user with the administrator role.
- With UID1, visit admin/structure/views/view/frontpage/edit/page_1, make any change to the view.
- With UID2, visit admin/structure/views/view/frontpage/edit/page_1. You should get the message "This view is being edited by user [user-name], and is therefore locked from editing by others. This lock is 2 sec old. Click here to break this lock."
- Click the "Cancel" button as UID2. The lock on the View is mistakenly broken. UID1's changes are lost.
Proposed resolution
Unknown
Remaining tasks
Create a patch.
User interface changes
Unknown
API changes
Unknown
Original report by @quicksketch
The Views interface locks itself if two users try to edit the same view. The "locked out" user however still has access to the "Save" and "Cancel" buttons. Clicking either button will immediately break the lock and either save the view, or discard the other user's changes. Considering clicking the Cancel button is the most natural thing for a user to do if someone else is already editing the same view, this seems like it could frequently lead to loss of in-progress configuration.
To reproduce:
- Install D8, create a second user with the administrator role.
- With UID1, visit admin/structure/views/view/frontpage/edit/page_1, make any change to the view.
- With UID2, visit admin/structure/views/view/frontpage/edit/page_1. You should get the message "This view is being edited by user [user-name], and is therefore locked from editing by others. This lock is 2 sec old. Click here to break this lock."
- Click the "Cancel" button as UID2. The lock on the View is mistakenly broken. UID1's changes are lost.
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | interdiff.txt | 1.91 KB | olli |
| #16 | vdc-2156853-16.patch | 2.38 KB | olli |
| #11 | vdc-2156853-11.patch | 2.5 KB | olli |
| #11 | vdc-2156853-fail.patch | 834 bytes | olli |
| #5 | interdiff.txt | 814 bytes | olli |
Comments
Comment #1
jibranTagging.
Comment #2
dawehnerThanks for reporting the issue.
I guess the proper solution would be to not offer a cancel nor a submit button?
Comment #3
olli commentedSomething like this?
Comment #5
olli commentedComment #6
berdirCancel is a destructive action too, unlike other forms, it destroys the temporary changes, it possibly needs a different cancel (iink?) that just goes back.
Comment #7
tim.plunkettI think the back button of a browser is sufficient here. We just remove the cancel button if its locked.
Comment #8
dawehnerI would assume another cancel link would do more harm than good. I cannot see how this cannot be confusing for the user.
Comment #9
dawehner.
Comment #10
berdirFine with me but the current patch is still showing the destructive cancel button that reverts all changes... :)
Comment #11
olli commentedAdded a small test.
Comment #14
dawehnerThank you!
Comment #15
catchWould prefer we set #access than conditionally set/remove the form elements - makes it easier for form_alter() etc.
Comment #16
olli commentedGood point, thank you!
Comment #17
quicksketchTested and it works for me. Nice touch to again check lock status on validation, in the event that the user had access to edit the view but another user saved the view out from under them. The workflow is still a little weird (the validation error comes up in the preview area), but it prevents the potentially config-losing situation where a user overwrites another user's changes.
Comment #18
damiankloip commented+1, this looks good to me.
Comment #19
webchickCommitted and pushed to 8.x. Thanks!