CollectionSpace Tech Team,
Here are some very rough notes (apologies for typos and poor wording) from a design meeting that the Services team had last week to discuss "delete" for the v1.6 release. From these notes, we'll be creating some JIRA service stories and related development tasks. Please feel free to comment and/or send questions about the notes.
SERVICES WORK SCOPE FOR IMPLEMENTING "DELETE"
The CollectionSpace Services will model the "persistent delete" (soft delete) functionality via a state model -essentially, we'll just be marking it "deleted." We'll still support a true delete (hard delete) at the services level but permissions for true deletes will be, by default, only given to administration accounts.
We're going to introduce a new general sub-resource called "workflow" that we'll use to track state. The "delete" workflow sub-resource will have two possible states -something like true/false or deleted/non-deleted. In future releases, we'll probably introduce more workflows for things like "active", "provisional", etc. For the v1.6 release, we're only going to support the "delete" workflow.
With this change, the UI layout for permissions will need to change. We should not longer show a column for hard deletes -so hard deletes can't happen through the UI. Instead of the current "delete" column, we should show a column for something named like "Admin/Delete", "Workflow/Delete", etc. I'll leave it up to the UI and Functional team to pick the correct terms.
DETAILS FOR DESIGN AND IMPLEMENTATION OF "DELETE"
Within Scope for v1.6:
1. Introduce the idea of a "workflow" sub-resource to keep track of state information like "deleted" about the parent resource.
2. Add a new permission handling for the "workflow" sub-resource.
a. Add new permissions to the tenant bindings files for the new "/workflow" sub-resource path
b. To protect the workflow sub-resource separate from the parent resource, add AuthZ code that looks for the "/workflow" URL suffix and removes everything between it and the parent resource.
i. For example, "/collectionobjects/12345679/workflow" maps to "/collectionobjects/*/workflow"
ii. Another example, "/personauthorities/ca90a819-7ae1-4794-83af/items/fd3dd3d7-810b-4246-8839/workflow" maps to
3. Only "GET" AND "PUT" are valid operations for the new "workflow" sub-resources.
4. "GETs" on most resources will now contain a new "workflow" part/section that will indicate the requesters workflow-related permissions. In other words, when a requester performs a get on a resource they will get back information telling them what their workflow permissions are for that resource.
Within Scope for v1.x/2.x
5. Payload for /workflow GET is both workflow id/label and current state (an enumeration?)
a. For example, true
b. Another example, false
6. "/workflows" service provides/defines workflow id/labels and corresponding state enumerations, etc.
7. List "GETs" could/should contain workflow related permissions for the items.