[Workbench] Interface to list and untrash trashed collections
|Status:||In Progress||Start date:||07/12/2016|
|Assignee:||Radhika Chippada||% Done:|
|Target version:||2017-06-07 sprint|
|Story points||2.0||Remaining (hours)||0.00 hour|
|Velocity based estimate||-|
Use case: Provide a simple interface for users to review what collections are trashed, and undelete them if desired.
- Add a /trash index page that lists collections with is_trashed=true.
- Display columns: checkbox, Name (with a link to object name / uuid), Contents (similar to /collections page), Trashed at (when it was trashed at), Created at, Un-delete button
- Selection drop down has one item to "un-delete" the selected items in the checkbox
- Search box
- Infinite scrolling (rather than paging - desirable)
#10 Updated by Radhika Chippada 11 days ago
Branch 9587-include-trash-in-group-contents @ 461b3f5a2edb53adda4f3b703d77e9efc0c262e9
Added support for include_trash param in groups_controller -> contents method. This is API server update only.
#12 Updated by Peter Amstutz 6 days ago
is_trashed is set once trash_at is in the past. In the case of temporary files, trash_at is in the future.
I think we want workbench treat files with trash_at in the future similarly to the trashed files (trashed_at in the past).
If we show temporary files (trash_at in the future) as "normal" files, then (a) it defeats the goal of decluttering the workbench listing and (b) means they can't actually be undeleted until trash_at passes.
So, instead of looking for is_trashed=true, Workbench should filter for "trash_at != nil" in the Trash tab and "trash_at == nil" in the regular Collection tab.
#13 Updated by Tom Morris 6 days ago
This is conflating two different things - 1) something which has been deleted/trashed and 2) something which is expiring and will be deleted/trashed in the future.
These aren't the same thing and they mean different things to the user. We need to stop thinking about this from the point of view of technical limitations cause by our particular token expiration strategy and look at it from the point of view of the user.
The story as written was fine. If we want to also implement a filtering strategy for things which will be expiring at some point in the future we can do that, but it isn't the same thing.
#16 Updated by Radhika Chippada 6 days ago
TomM and Peter, the more I look into it, the more this UI design is not making sense to me. Are we sure what we want is a project#Trash tab? It feels like an index page /trashed_collections (or something like that) would be lot more useful for the users.
This project#Trash tab is not making sense because if a user wants to look at trashed collections and untrash, he needs to go into each project and look for these collections. Adding another tab that is not very useful seems like a major wasted investment in a wrong place than doing the more useful /trashed_collections page. I think a /trashed_collections page and a link to it in the "Recent collections" panel on Dashboard might be a better UI design.
#17 Updated by Peter Amstutz 5 days ago
I had a similar thought. Once an object is trashed (not just future trash) it's going to be very hard to find in order to recover it, because the default behavior is to deny that it exists.
One thought I had is if you know the uuid and request the show page in workbench, it could request the record with include_trashed=true and present you with a "do you want to untrash this" page.