Lock form should indicate if entity no longer locked.

Created on 1 March 2018, over 7 years ago
Updated 15 January 2024, over 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.

  • Pipeline finished with Canceled
    about 1 year ago
    Total: 168s
    #177777
  • πŸ‡¬πŸ‡§United Kingdom ieguskiza

    Attaching static patch after rebasing MR after latest release

  • Pipeline finished with Failed
    about 1 year ago
    Total: 248s
    #177781
  • πŸ‡§πŸ‡ͺ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.

  • πŸ‡§πŸ‡ͺBelgium joevagyok

    Re-rolled the patch from #18 over the latest 3.0.0-alpha3 release.

  • Pipeline finished with Failed
    17 days ago
    Total: 292s
    #527134
  • πŸ‡§πŸ‡ͺBelgium joevagyok

    Rebased the content of the previous MR and opened a new MR against 3.x since I was unable to change the target branch to 3.x.

  • Pipeline finished with Success
    17 days ago
    Total: 213s
    #527140
Production build 0.71.5 2024