Indirectly trashed item's context menu show editable actions
Projects or collections belonging to other projects that happen to be trashed are accessible on WB2 via the "Trash" section on the left panel, by navigating through those trashed projects.
The context menu code on wb2 assumes that something is trashed only when its
is_trashed field is set to
true, but that's not always the case. On wb2, when this happens, a "Restore" menu item is offered that calls the
untrash API call, and that's possible only on directly trashed objects, and it isn't on objects that belong to trashed projects.
So, we should come up with a way of fixing this behavior difference, as users will surely want to recover some objects from within trashed projects.
Talked on eng meeting:¶
Implement a virtual read-only field on the API side to tell the client when something is indirectly trashed This would be included not always but when using “include_trash” or passing another special flag
On wb2’s side, that would allow us to easily know when any object is trashed. A virtual field won’t necessarily be useful as an event from websocket, so we may need to use some cache invalidation strategy
More discussion 2020-12-01¶
Nico’s suggested checking: https://swr.vercel.app/
Workbench2, when displaying a collection, project, or other record (technically this could apply to container requests and workflows too), should be aware of the entire ownership chain (that is visible to the user). Then wb2 can determine if any of the owners have "is_trashed" set and determine the correct behavior. (It's also possible the parent project is not readable unless include_trash is set and that's also a signal that it belongs in the trash).
For this to work well, we'll want to start caching requests and use a stale-while-revalidate policy (#17172).
Updated by Peter Amstutz almost 2 years ago
Workbench2, when displaying a record, should be aware of the entire ownership chain. Then the app can determine if any of the owners have "is_trashed" set.
Related: should optimize object access by adding a caching and stale-while-revalidate policy.