Repository navigation
Show unlock action for the file owner - #17838
falkloewert wants to merge 2 commits into
Conversation
The server allows the owner of a file to unlock TYPE_USER locks (LockService::canUnlock), so a stale lock created by another client - e.g. the Text app, whose locks have the owner "text" - can be released by the user. The client only offered the action when the lock owner matched the current user, leaving users without a way to clear such locks until the lock timeout expires (which defaults to unlimited). Signed-off-by: Falk Loewert <falk@co-sinus.de>
App locks created by the Text or OnlyOffice apps are of type TYPE_APP. For those the server does not expose a lock owner and reports the lock type as COLLABORATIVE, so the previous check (lock owner equals the current user, MANUAL lock type) never matched and the unlock action stayed hidden even for the owner of the file. LockService::canUnlock accepts a TYPE_USER unlock request from the file owner for TYPE_USER and TYPE_APP locks, so mirror that on the client and only keep TOKEN locks restricted. Additionally the lock info row was appended to the action list before displayActions() ran. That method returns early when the list is not empty, which left the bottom sheet without any action at all for locked files. Render the actions first and append the lock info afterwards. Signed-off-by: Falk Loewert <falk@co-sinus.de>
|
Updated the patch after testing on a real device (Android 16, Pixel 9 Pro, files_lock 34.0.1, server 34). Two things the first revision got wrong or missed:
Verified end-to-end on device: open the actions sheet for a docx locked by OnlyOffice, tap "Unlock file", lock disappears from 🤖 Generated with Claude Code |
|
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
Fixes #17837
Summary
The "Unlock file" entry was only shown when the current user owns the lock (
lockOwnerId == userId). The server also allows the file owner to unlockTYPE_USERlocks —OCA\FilesLock\Service\LockService::canUnlock():Without this, a stale lock created by another client (e.g. the Text app, lock owner
text) cannot be released from the app at all; with the defaultlock_timeout = -1it never expires.Change:
FileLockingHelper.canUserUnlockFile()now also acceptsfile.ownerId == userId.Known limitation: for group folders and external storage the server deliberately skips the file-owner check (
MountProviderallowlist incanUnlock), so the client cannot mirror the rule exactly there; the action can then fail with the existing error snackbar.🖼️ Screenshots
Not applicable — the only visible difference is an additional entry in the file overflow menu.
🏁 Checklist
FileLockingHelperTest, 5 tests)🤖 AI (if applicable)