fix: disable rename action in password-protected folder view#13512
fix: disable rename action in password-protected folder view#13512priyanshuharshbodhi1 wants to merge 2 commits intoowncloud:masterfrom
Conversation
Fixes owncloud#12365 - Added isLocationPublicActive check to useFileActionsRename - Prevents rename action from showing in public link context - Aligns with documented behavior that link files shouldn't be renamed from webUI
|
@LukasHirt PTAL, could you please review this and confirm whether this approach looks correct? |
|
LukasHirt
left a comment
LukasHirt
left a comment
There was a problem hiding this comment.
The rename action is now hidden in public link contexts, which aligns with the documented behavior that link files should not be manipulated from this view.
Could you please point me where is this documented?
|
Hey! The doc reference is in packages/web-app-password-protected-folders/README.md on line 59:
Though I realize it refers to the link file itself, not actions inside the modal. The main reason for this fix: renaming from inside the PPF modal (public link iframe) operates on the wrong context, causing the folder to fork instead of rename. Hiding it follows the same pattern as useFileActionsDelete (line 50) which already disables delete in public links. Let me know if you'd prefer a different approach! |
|
Alternative fix (more complex):
|
|
The main problem is with the shared context for PPF and public links in general. Since PPF "abuses" the public link functionality, simply preventing renaming breaks the regular links. Regarding backend changes, as of now, this is only frontend feature. This was done on purpose to leave backend out of this topic. If it would need to be touched, it would probably be better to do a real PPF implementation on the backend. |
2 participants
Description
Disables the Rename action in the breadcrumb context menu when viewing a password-protected folder (public link context).
Related Issue
Fixes #12365
Motivation and Context
When renaming a folder from inside a password-protected folder view, the action operates in the public link context. This causes the rename to create a duplicate folder instead of renaming the original.
The fix aligns with:
useFileActionsDelete.tswhich already disables delete in public linksHow Has This Been Tested?
Types of changes