Lock form should indicate if entity no longer locked.

Created on 1 March 2018, about 7 years ago
Updated 15 January 2024, about 1 year ago

If user 1 is currently editing a page, and user 2 unlocks the page, and then user 1 clicks on the unlocks the page button, the form doesn't indicate that the entity has been unlocked.

if user 1 lacks the permission to break a lock, user can still can break his/her own lock and therefore see the "break lock" button on the edit form while editing. So if user 2 breaks the lock while they are on the edit page, and then user 1 clicks on the break lock button, they get an access denied error.

πŸ› Bug report
Status

Needs work

Version

1.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States oknate Greater New York City Area

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡΅πŸ‡ΉPortugal hernani

    Attaching static patch from current MR.

  • πŸ‡¬πŸ‡§United Kingdom ieguskiza

    Attaching static patch after rebasing MR after latest release

  • πŸ‡§πŸ‡ͺBelgium keszthelyi Brussels

    Attaching a reroll of #15 for 3.0.0-alpha2.

    Fixes an issue with the original #15 patch that causes error when the redirect Url generated from the destination parameter is not a routed Url (so the getRouteName() method can't be called on it). This can happen for example if the base path of the site contains a subdirectory, but there might be other cases when it's not possible to convert the destination parameter to a routed Url. This patch only uses the Url from the destination parameter to redirect if it's a routed Url, otherwise falls back to the entity canonical route.

  • πŸ‡§πŸ‡ͺBelgium keszthelyi Brussels

    Re #11: it seems that in this scenario the content is always locked. After breaking user B's lock, user A is redirected to content edit form, locking the content again (by user A). When user B visits the break lock form the content is locked by user A and user B doesn't have permission to unlock the content, so the access denied is technically correct. User B can only avoid the access denied (with this patch) if in the meantime user A also unlocks the content after breaking user B's lock.

    The access denied in the scenario described in #11 could only be avoided if access is always allowed to the form and everything is handled in buildForm() with redirects, but not sure if that's the better solution.

Production build 0.71.5 2024