fix(files_sharing): Hide incompatible actions in shares#60151
Conversation
1245b96 to
ad38f46
Compare
There was a problem hiding this comment.
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.
ad38f46 to
c73b63c
Compare
Approach has been changed but we then we have to remember do this on all actions. |
c73b63c to
7e4f4cb
Compare
There was a problem hiding this comment.
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?
… shares Pending and deleted shares are not mounted into the user's filesystem, so generic file operations like delete or download produced a misleading "file is not available" error. These shares now carry no permissions, so every permission-aware action hides itself automatically, without the files app having to special-case each view. Conversion additionally requires read permission, matching the server-side readability check. Assisted-by: ClaudeCode:claude-opus-4-8
7e4f4cb to
272a8e8
Compare
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.