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. |
…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.
c73b63c to
7e4f4cb
Compare
| if (view.id === 'pendingshares' || view.id === 'deletedshares') { | ||
| return false | ||
| } | ||
|
|
There was a problem hiding this comment.
Why is this needed? This sounds more like the nodes it self should not have DELETE permission set?
| if (view.id === 'pendingshares' || view.id === 'deletedshares') { | ||
| return false | ||
| } | ||
|
|
There was a problem hiding this comment.
Why do those nodes then have READ permission?
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?
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.