Bug #16510
Updated by Peter Amstutz over 3 years ago
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. h3. 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- h3. 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), record, should be aware of the entire ownership chain (that is visible to chain. Then the user). Then wb2 app 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). set. For this to work well, we'll want needs to start optimize object access by adding a caching requests and use a stale-while-revalidate policy (#17172).