Idea #12032
Updated by Tom Clegg almost 7 years ago
As a user, I would like deleted projects to be placed in the Trash rather than cluttering my Home project and when the Trash is emptied, the project and all of its contents, recursively, get deleted. Details about desired behavior after the Workbench "trash" button is hit on a project: * The project and everything below it (including other subprojects) stop showing up in the usual places in Workbench, arv-mount, etc., even if there are explicit permission links (like collection-sharing links) Components to the project or its contents. be updated: * The project and its contents can still be retrieved using "get" and "list" - API calls with the include_trash flag. Server * The project appears in its parent project's "trashed items" tab in Workbench. Clicking the project shows the trashed project with its implicitly-trashed contents: there is an obvious indication that the project itself is trashed, and (TBD?) all - Workbench - arv-mount Items of its contents appear in the "trashed items" tab instead of their usual places. * If a user follows an old link/bookmark to the project, the page is not found. Except: (TBD?) The "not found" error page should acknowledge that the project is still available in the trash, and offer a link to the "trashed project" view described above. * The project and all of its previously-untrashed contents can be un-trashed by calling the "untrash" method on the project. However, if the project already contained items which were trash before the project was trashed, untrashing the project does not untrash those items. * Any individual item contained types in the trashed project can be untrashed by changing its owner_uuid field to a project/user that is not trashed. * Data integrity: There is no sequence of API calls that could result in a collection being deleted (or otherwise made invisible to keep-balance) less than blobSignatureTTL seconds after the last time a client read or updated that collection's manifest. The trash/untrash APIs should be similar to the collection trash/untrash APIs. Specifically: * Each project should have a delete_at timestamp that can be set to a time ≥blobSignatureTTL in the future The trash/untrash APIs should work quickly and atomically, even when a large hierarchy of items is affected. This implies that the permission graph gains a "trashed?" flag, which is taken into account when retrieving results for get/list APIs, even for admin users. Components to be updated: * API server * API docs * Workbench * arv-mount are filtered from search.