ideas icon indicating copy to clipboard operation
ideas copied to clipboard

Make Entry status extendable

Open jonassiewertsen opened this issue 3 years ago • 14 comments

We would wish for an option to make an Entry Status extendable. I would guess we might need an extendable PHP and Vue solution, depending on how this should work.

We are talking about those dots:

Bildschirmfoto 2022-01-28 um 16 53 10

For many cases the defaults are great, but making them extendable (or giving the option to overwrite them, would be really helpful). This would open up for projects, to extend an entry status.

Possible usecases for an article could be:

  • unpublished
  • prepared
  • review
  • approved
  • published

Possible usecases for an orders collection might be:

  • unpaid
  • pending
  • expired
  • ...
  • paid

Statamic should not offer them, just making it possible to extend the behaviour.

jonassiewertsen avatar Jan 28 '22 16:01 jonassiewertsen

This would be a great addition! Probably connected to this idea.

aerni avatar Jan 28 '22 16:01 aerni

I'd love to see this. Here are some examples of content workflows from GatherContent: image image

mikemartin avatar Jan 29 '22 00:01 mikemartin

Questions for those that are interested in this:

  • what should the status be if an entry has an existing status (published, expired, etc) and has a custom status?
  • should this be a different method, instead of status? If so, ideas on name?

edalzell avatar Jul 05 '22 02:07 edalzell

It would be my personal expectation to only have one state/status. This does avoid making things too complex.

In that case, an entry has a 1 to 1 relation with the state. If an entry is published, it's published. Not for example approved && published, ONLY published. As shown above in a few examples, an entry could only have one of those states.

I would think that the published state does some publish action behind the scenes and that all other states, are some kind of internal draft status with a custom label, custom icon and custom status name. On top of that, it would be super helpful to fire an event if a status does change with the entry and belonging status information.

By having that event, we can listen to a change and specific states, to add custom behaviour via Event listeners.

For other use cases, you can always add another fieldtype to collect som extra information, which isn't coupled that strong to the entry itself.

jonassiewertsen avatar Jul 05 '22 08:07 jonassiewertsen

On top of that, it would be super helpful to fire an event if a status does change with the entry and belonging status information

@jonassiewertsen couldn't we use the existing EntrySaved event? What's the use case for a new event?

edalzell avatar Jul 05 '22 13:07 edalzell

@jonassiewertsen couldn't we use the existing EntrySaved event? What's the use case for a new event?

Actually, I think that might be the best option.

jonassiewertsen avatar Jul 05 '22 13:07 jonassiewertsen

What about entries that don't fall into a publishable workflow, e.g. a collection of orders. They should never appear on the frontend and don't need a status of published but an equivalent status like paid.

aerni avatar Jul 05 '22 13:07 aerni

Good point!

If no slug is provided, a published order can't be visited anyways. But it's the last status, as it's finished and I think you want the green dot to show up as well.

Might that be solvable via an alias or a different label, to keep the same workflow somehow? Just thinking out loud here :-)

jonassiewertsen avatar Jul 05 '22 13:07 jonassiewertsen

No reason you couldn't rename the published status, similar to how you can rename the title field

edalzell avatar Jul 05 '22 15:07 edalzell

Should these custom statuses be handled separately from our internal status? The reason I mention is that the status field is meant to be dynamic, and Statamic references the 4 existing statuses in multiple places...

I'm thinking the custom statuses you're adding are more for team flow, whereas the status field is used to determine when to actually show/hide entries by Statamic. If we allow extention of status, we'd have to be super careful of where it's used by Statamic.

Conversely, if you had your own separate team_status field or something, it can still be filtered, queried against, etc.

Curious what @jasonvarga thinks đŸ‘‹

jesseleite avatar Jul 05 '22 17:07 jesseleite

What do you think @jasonvarga ?

jonassiewertsen avatar Jan 17 '23 08:01 jonassiewertsen

Is there any ETA on this? This sounds super promising and would be a great addition that sometimes is asked for (because it's known from other CMS).

dominikfoeger avatar Apr 01 '23 14:04 dominikfoeger

I just stumbled upon this in the docs and I would need the status depend on a start date(time) and end date(time) for some (a lot of different) time sensitive collection entries. Currently this doesn't seem possible with Statamic but I'd kinda want to avoid implementing complete custom logic of showing/hiding entries everywhere when there's already similar functionality in the CMS itself (publish date)

bernhardberger avatar Oct 17 '23 12:10 bernhardberger

Hi from 2024 đŸ™Œ , is there any updates on this idea ??

emran-alhaddad avatar Jan 11 '24 09:01 emran-alhaddad