ryanthompson - 1 year ago

I often find the need to save any random entry as a draft. Custom addons and core alike. Some core addons like Pages and Posts handle it custom per their own API. But to do so requires that you build it yourself each time.

I propose a core status utility. Where we can define status groups (with a default) and some simple rules like hiding them from queries.

The simplest form of this would be "draftable" for example. Similar to trashable it would simply be a flag and draft boolean would be added to the table and drafts omitted from queries unless withDrafts is included. Very similar to trashable.

I am OK with fixing options too - I thought perhaps we'd use config for statuses / groups if not using a single draftable approach. I forsee again banks / larger entities wanting to have draft, ready for review, approved, type workflow and simple draftable would not accommodate that. Personally I am in favor of the config status definitions and perhaps detect draft and perhaps some others automatically to prevent them from being in queries unless withStatus('draft')->withStatus('pending') for example.

edster - 1 year ago

Agreed, make it extension based imo. Allow extensions to be created that will allow different option/categories. that way if a custom workflow needs to be added in, then someone can easily deploy that.

ryanthompson - 1 year ago

I could then see adding a stream form option when applicable for "status group" to pick default, custom status groups.. but then how to change status groups for streams that don't expose a form like pages / posts / etc. Those are core streams with no direct stream editing.

ryanthompson - 1 year ago

@edster hmm.. I try not to use extensions for core stuff but we could allow extensions to alter it by use of a registry type pattern like asset paths / image paths / icons:

$statusRegistery->addGroup($slug, $statuses); // In your service provider.

edster - 1 year ago

@ryanthompson yea I could see the concern. I like the idea of a registry, there has to be a way to easily add in groupings/options if need be. Otherwise you need to try and capture all the use cases (which we know won't happen).

If your doing extension then we can also tie in functions to remove the added options into withStatus('draft') etc

ryanthompson - 1 year ago

@edster nailed it.

ryanthompson - 1 year ago

Let’s assume the config route. And we have an instance where we add a status to the default (live and draft) or the otherwise status group used by pages. So now we have live, draft, and pending approval.. how do we determine what statuses are ok to display and which are not? EE I think did a good job with this I’ll loom at what they did for starters.

How to override / define status group used by a stream? Needs to be overridable which screams config / publishing.

ryanthompson - 1 year ago

This is cool: https://github.com/spatie/laravel-model-status

Might be cool to be able to add a field macro that adds reasoning below the status drop down when applicable.

finnito - 4 months ago

I have been building out some modules and often have thought that having draftable as core would be super great @ryanthompson!

Is this still an idea or is it on its way to being implemented? It’d be great to know so I know whether to roll my own super basic statuses for modules at the moment.

ryanthompson - 4 months ago

I am leaning heavily towards a v3.6 release to wrap up some remaining "big deal" features. In which case it would be forthcoming relatively soon.

ryanthompson - 1 month ago

Soooo just hit me a bit ago.. I think this feature would best be handled as a field type. Pretty stoked about it!

You would add your field - let's call it status for the hell of it. Choose your statuses (can be translatable strings) and configure which one is considered live. We'd have option handlers to make things in modules like pages configurable (add your own status). Then we'd use the little known, undocumented (currently :-P), and highly awesome feature called field type criteria hooks to hook into the query builder.. we can hide things that aren't live by default from the front too..

I think there is some traction here. Thoughts?