Idea #3150
Updated by Tim Pierce over 9 years ago
"Trash" button should make an object disappear from the current view, but it should be possible (ideally easy) to get it back. *API server behavior* (Consider requirements in terms of Workbench behavior, but we'll need some API changes too.) Notes: * Jobs in particular, and probably all objects, should never be deleted outright during normal use -- just moved out of the way. (The exception is the underlying data blocks referenced by deleted collections.) * Add a "expires_at" flag to each model (just like collections have now). ** Feature: an expired/deleted object's UUID cannot be reused by a different object. * By default, do not return rows with @expires_at is not null and expires_at < CURRENT_TIMESTAMP@ null@ * Trash lifetime is button → set in @Rails.application.config.default_trash_lifetime@ (default: two weeks) expires_at to now + {configured trash period} * application controller method @delete(optional_ts=nil)@ Empty trash → set expires_at to _optional_ts_ (if nil, use @Time.now + Rails.application.config.default_trash_lifetime@) now Permissions: * If I delete an object from a project that is shared with other users, other users can still read it by looking at the project's "trash" view Trashing a project: * Recursive delete would be slow, and awkward to undo. (Which contents were already in the trash before the project was trashed?) * Skip trashed projects in site-wide search (like @collections.index@, and @groups.contents@ with no group_uuid). *Workbench* * Trash button → invoke DELETE method on API server * Empty trash → invoke @/:object/:uuid/delete/{Time.now}@ on each object in the user's trash *SDK* The default SDK view should be to hide items in the trash, to make SDK results consistent with those seen in Workbench. But the user should be able to override this setting to view items in the trash. Possible solution: a @show_trash@ option (defaults to _False_) to the @list@, @update@, @show@ and other methods.