In content list, the Break Lock action is visible for anyone, and the access function doesn't check for the `break content lock` permission. If a user tries to do batch with that on nodes where he doesn't have permission to edit, it returns a message Permission denied. Also, the user shouldn't be able to break content lock without this permission.
Here's a bug where a user can break locks without the `break content lock` permission:
1. Create editor role without `break content lock` permission and access to edit nodes created by users with this role.
2. Create editor user (username editor, password editor)
3. Log in with editor user and create a node
4. In another browser log in with the super admin and open the node created by the editor user, this will create the lock.
5. Back in the browser for the editor user, go to the Locked Content view and select the node created by this user (editor user) from the bulk operation column and apply the "Break lock node" action.
6. Expected, as this role lacks the `break content lock` permission, they should not be able to break the lock under any circumstances.
7. Because the user has update access to their self created node, the `break content lock` action passes the access function and they are able to break the lock.
Update access function to check for the `break content lock` permission as well as the update access.
Needs work
2.0
Code
The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Change makes sense to me. Not sure if the permission check should happen first though. Will leave in review.
Given this is about access it's always great to see some automated test coverage.