Skip to content

fix(files_sharing): Hide incompatible actions in shares#60151

Open
nfebe wants to merge 1 commit into
masterfrom
fix/pending-shares-hide-incompatible-actions
Open

fix(files_sharing): Hide incompatible actions in shares#60151
nfebe wants to merge 1 commit into
masterfrom
fix/pending-shares-hide-incompatible-actions

Conversation

@nfebe
Copy link
Copy Markdown
Contributor

@nfebe nfebe commented May 4, 2026

Pending and deleted share entries are not mounted into the user's filesystem, so generic file operations like delete or download cannot succeed and produce a misleading "file is not available" error.

These views now expose only the actions that actually apply: accept and reject for pending shares; restore for deleted shares. All other views continue to show every registered action.

@nfebe nfebe requested review from a team and skjnldsv as code owners May 4, 2026 20:42
@nfebe nfebe requested review from susnux and szaimen and removed request for a team May 4, 2026 20:42
@nfebe nfebe force-pushed the fix/pending-shares-hide-incompatible-actions branch 2 times, most recently from 1245b96 to ad38f46 Compare May 4, 2026 20:43
@nfebe nfebe marked this pull request as draft May 4, 2026 20:44
Copy link
Copy Markdown
Contributor

@susnux susnux left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be handled by the actions in question in the enabled callback of the action itself.

We designed the API so that the files app does not need to know about internals of actions to detangle this logic.
That is why our API now works for so long very well. So the files app itself should not need to know about when something can be downloaded or not. This is the task of the action itself.

@nfebe nfebe force-pushed the fix/pending-shares-hide-incompatible-actions branch from ad38f46 to c73b63c Compare May 5, 2026 10:05
@nfebe
Copy link
Copy Markdown
Contributor Author

nfebe commented May 5, 2026

this should be handled by the actions in question in the enabled callback of the action itself.

We designed the API so that the files app does not need to know about internals of actions to detangle this logic.
That is why our API now works for so long very well. So the files app itself should not need to know about when something can be downloaded or not. This is the task of the action itself.

Approach has been changed but we then we have to remember do this on all actions.

@nfebe nfebe requested a review from susnux May 12, 2026 15:58
…share views

Pending and deleted share entries are not mounted into the user's
filesystem, so generic file operations like delete, download, or
rename cannot succeed and produce a misleading "file is not
available" error.

Affected actions now opt out of these views, leaving only accept
and reject (pending) and restore (deleted) as available row
operations.
@nfebe nfebe force-pushed the fix/pending-shares-hide-incompatible-actions branch from c73b63c to 7e4f4cb Compare May 12, 2026 15:58
@nfebe nfebe added 3. to review Waiting for reviews feature: sharing labels May 12, 2026
@nfebe nfebe marked this pull request as ready for review May 12, 2026 15:58
Comment on lines +42 to +45
if (view.id === 'pendingshares' || view.id === 'deletedshares') {
return false
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this needed? This sounds more like the nodes it self should not have DELETE permission set?

Comment on lines +32 to +35
if (view.id === 'pendingshares' || view.id === 'deletedshares') {
return false
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do those nodes then have READ permission?

Copy link
Copy Markdown
Contributor

@susnux susnux left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the proper fix for most cases (and also for e.g. 3rdparty actions provided by community apps) is to properly set the permissions.
In the pendingshares and deletedshares the returned nodes should not have READ, UPDATE or DELETE permissions then, no?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants