Open VKambulov opened 3 years ago
For example, now I use this Trait
to control an element.
trait CanDisabled
{
/**
* Determine if the model has disabled.
*
* @return bool
*/
public function isDisabled(): bool
{
return (bool) $this->disabled_at;
}
/**
* Determine if the model has enabled.
*
* @return bool
*/
public function isEnabled(): bool
{
return is_null($this->disabled_at);
}
/**
* Mark the given model as disabled.
*
* @return bool
*/
public function disable(): bool
{
return $this->forceFill([
"disabled_at" => $this->freshTimestamp(),
])->save();
}
/**
* Mark the given model as enabled.
*
* @return bool
*/
public function enable(): bool
{
return $this->forceFill([
"disabled_at" => null,
])->save();
}
/**
* Mark the given model by depending on given value.
*
* @param bool $value
* @return bool
*/
public function switch(bool $value): bool
{
if (!$value) {
return $this->disable();
}
return $this->enable();
}
}
In my case, I account for showing and hiding disabled items in queries. Ideally, it would be nice to be able to call withDisabled
or withoutDisabled
as in SoftDeletes and hide disabled items by default on any request.
I would like to suggest adding a
disabled_at
field that will disable the item. A disabled item will not be available for display by default (as, for example, with thedeleted_at
field in the Soft Deletes). Why not just use Soft Deletes? Sometimes you need to keep deleted items that almost no one will see (except for the Administrator, for example), but at the same time be able to disable (perhaps temporarily) some items that other users (for example, editors) can see and manage. For example, there is an article that still needs to be completed and published. It could have been simply disabled temporarily (perhaps too trivial an example). In fact,disabled_at
will almost completely repeat the functionality of Soft Deletes, with the exception of a more understandable name for the field and, as it were, a fallback option, if you need to have both functions.