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 Implement a virtual read-only field on the API side to tell the client when something is indirectly trashed- trashed ** -This This would be included not always but when using “include_trash” or passing another special flag- flag * -On On wb2’s side, that would allow us to easily know when any object is trashed.- trashed. * -A 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 strategy ** On this note, Nico’s suggested checking: https://swr.vercel.app/ 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. For this to work well, needs to optimize object access by adding a caching and stale-while-revalidate policy (#17172).