Hi Yura -

We're going to tweak the way permissions are handled for workflow changes.
Where there is now a resource (and an associated permission) for */workflow,
there will be a resource and associated permission for each workflow
transition that we support. So, for now, records except Movement will
support ".../workflow/delete", where Movement will support both
".../workflow/delete" and ".../workflow/lock".

However, we also have to handle the workflow logic (in addition to the
permissions). I.e., a user can have the right to delete a record, but the
workflow definition may not allow the transition from "locked" to "deleted"
(users cannot delete locked records).

To handle this, we're proposing to add to the payload for a record, a new
section that includes the support workflow transitions for that record.
Thus, normal records will support "delete", and unlocked Movement records
will support "lock" and "delete" but locked Movement records will not
support any workflow transitions.

This will be based upon the workflows defined, so if at some point Megan et
al. want to support "unlocking" of records, or "delete_locked," we would
adjust the workflow definition and the new permissions and transitions would
show up.

I think we can handle this in both the services and app layer. Where
permissions are a function of the user's login status, the workflow
transitions are a function of the current document (state). So we're
thinking it should be in the record payload, as a new section alongside
"fields," "relations," etc.

Does this make sense?

Patrick