Extendable status field

[dkirchhof]

For one of my clients projects I implemented following features:

• soft deletion
• scheduled publishings
• active / inactive pages
• release process (some users have to request a release, since they aren't allowed to publish)

Since I read several times that it wouldn't be a good idea to mess with the native status property, I had to create several workarounds.
For example, I have the native status field, a active field and a released field and a publishingDate field.

To keep the logic simple, I tried to use the native status as much as possible. For example for scheduled publishings, I keep the status as draft and change it to published automatically with a cron job at the given time. So the api doesn't return the unpublished docs, a relationship field wouldn't show it, etc.
Unfortunately I can't depend exclusively on the current status field, because we are only allowed to save a single draft. So older drafts will be deleted automatically.

I have a custom draft and a custom publish button to change the text and logic according to some of these combinations.

---

Well, I am a fan of the paradigm "make impossible states impossible".

Some states which are in this project theoretically possible, but shouldn't be allowed or doesn't mage sense:

1. _status = draft, released = true, active = false
2. _status = published, released = false, active = false, publishingDate = 2025-01-01
3. ...

So to make theses states impossible, I would like to extend the status field to the following one:

type status = 
  | "draft" | "released" | "published" | "unpublished" 
  | "deleted_draft" | "deleted_released" | "deleted_published" | "deleted_unpublished"

(Just an idea)

---

The simplest way to implement a extendable status field is to make sure, every hook etc. which checks the status field (if _status === draft) will be turned around like if _status !== published.

A more complex way would be to configure this behavior in the payload config.

I think a generic solution for the save draft and publish buttons aren't possible.

---

Of cause the best solution would to implement features like soft deletion, scheduled publishings etc. natively.