Add the Deletion Process to the Editorial Workflow

[dbinetti]

This request is related to:

• "Delete published entry" button bypasses editorial workflow #5650
• Extend publish mode to deleting of content #6610

Is your feature request related to a problem? Please describe.

TL;DR: The problem is that making changes and releasing changes are two different things, which are identical in the current Delete workflow.

In our use case, we have a committee that uses Decap to work on proposed changes to a file, which are then presented to another body that makes the actual decision to accept or reject those PRs. We use the Editorial Workflow to manage this internal committee work, and once we are ready to suggest official changes to the main body we put things in the Ready state.

If the main body approves those changes, we Publish, the changes are merged, and deployed to production. If the main body rejects the changes, we either return to Draft to adjust, or delete the work entirely through the "Delete unpublished changes" button. This works flawlessly for Create and Update, as those changes remain on branches even as the trunk (ie, production) remains untouched.

But we have no such analog when we want to Delete a file. Using the current interface, there is no difference between Unpublish and Delete. Both result in the same thing: the file in question is immediately deleted in the trunk. This is redundant, confusing, and unexpected.

Describe the solution you'd like
Extend the Editorial Workflow to include Delete in addition to Create and Update.

Describe alternatives you've considered
We currently use the GitHub backend to create delete-only Pull Requests and manage the flow outside of Decap.

Additional context
Please note this isn't about preventing accidental deletion, forgetting to push deletions, or privileges on who can make deletions (as in the issues cited above). To me, the value of the Editorial Workflow is that it decouples making and releasing changes. These are two very different things in most publishing environments, but in Decap when it comes to file Deletion they are inseparable.

I'm proposing that under "Delete", the action be:

1. Creation of a new Branch and corresponding Pull Request, which does nothing more than deletes the file on the branch.
2. Present in the UI that the file is slated for deletion, which could be either through a banner or markup over the existing (ideally disabled) interface, or perhaps simply a message that the file is pending deletion, with perhaps a "Load Diff" to render the proposed deletions similar to how it is done on GitHub.
3. On Publish, merge the PR, which deletes the file from the trunk and on deployment removes it from the live site, OR ---->
4. Go back to status quo ante by clicking the Delete unpublished changes, which deletes the branch and PR, and brings you back to where you were before.

Side Note: To me, the Unpublish button is misleading, and the entire concept should be removed. Publishing on Decap (as best as I can tell) merges the PR to trunk, and there is no such thing as git unmerge. There are many ways to revert commits, of course, but that's something different and will always be available on the backend to those who need to overwrite something later. That said, if the thought of saying "Delete the unpublished deletion" is too confusing then that's fine. The main point is to decouple persisting changes from releasing changes. So if anything, the Unpublish button should revert the committed changes on the trunk, and re-create a branch/PR with them. This is probably unnecessarily complicated and certainly out of scope for this request, but I offer it FWIW.

Thank you -- your efforts are valued and appreciated.

[dbinetti]

Not sure if this happens automatically, so pinging @bytrangle and @erezrokah just in case since they are collaborators who commented on the other related issues. Thanks...

[martinjagodic]

@dbinetti, thanks for your submission and for being a user. The people you mentioned are not maintainers anymore. We were notified about your feature request. We have a list of priorities that we focus on, so it might take a while before we consider this. If you want to speed it up, you can open a pull request or sponsor the development of the feature.

[dbinetti]

Understood -- thank you.