laravel-moderation
laravel-moderation copied to clipboard
hootlex
Possibility to use custom status
Hey, very nice package. However, if this flow does not work with your process, you need to hack it.
What do you think about adding a possibility to add a custom status?
E.g.
$post->setStatus('custom');
Post::all()->withStatus('custom');
Maybe the user can set those status and decide if they should be queried in strict mode or not.
You could even use magic methods to build markCustom methods.
What do you think?
Good idea ! Actually, the differents status are hard coded, maybe need a little refactoring.
Why not a markAs method with a parameter ? Personally I prefer it, I don't like magic :wink:, and like idea completion.
Hi @lukasoppermann, this is a very good idea.
The quickest way I can think of, is to use the config file to define the available statuses instead of the Status model.
What do you have in mind about magic methods?
@hootlex I think $post->markNotForChildren() (status = not_for_children), like the markPending method ( See call magic method ).
@stephane-monnot @hootlex exactly. But I would be fine with a markAs() method. It was a suggestion in case you wanted those methods.
Changing the status to be defined in a config file would make sense to me. This would even open it up to be stored in a database, retrieved and set as config variables, so it would make it very flexible!
However it needs a little bit of though as you would need to let the user define if a status is by default retrieved or not. But it should be easy.
I am just thinking that sometimes you need to create a business flow, e.g.
"new Post() created", status: ->
draft ->
waiting for review ->
needs changes ->
waiting for review ->
ready for publication ->
published / queued
Just as an example.
You could change everything to just use more generic functions like setStatus() and hasStatus.
If you want to keep the old behaviour to not break bc you could just create them as "aliases" so markPending() is an alias for setStatus('pending').
Maybe status are better in database (eloquent model), because:
- we could use eloquent relationships with others tables
- if one day I want to remove a status, I will get an error if at least one post has been marked with this status (needed in foreign key constraint).
What do you think ?
Hmm, maybe optionally? I am just thinking if you just have a published/unpublished case a database for just to status would be a bit of an overkill, would it not?
Yes, I agree, that's a bit overkill. As a first step, we should use config files.
Maybe we could require a "default" status or something so if the status that a model had is missing, it will be reset/interpreted as the default status? This could solve the problem you where describing correct?
@lukasoppermann @stephane-monnot I prefer to use config file to define the statuses. They can be defined within an array, which will contain an 'ID' and a 'name'.
+1 for the default status fallback.