Deleted_By remains null on softDelete

[Munsterlander]

With Laravel 8.x (at least I observed this after the upgrade), the deleted_by field is remaining null. Specifically, for a generic model:

class EmailTemplate extends Model
{
    use SoftDeletes;
    use \Insense\LaravelUserAuditTrails\HasUserTrails;
    use \Insense\LaravelUserAuditTrails\HasDeleteTrails;
    protected $guarded = [];
}

That has this call in a controller:

EmailTemplate::where('id', $id)->delete();

Deleted_by remains null yet deleted_at gets the current date and time. In debugging this, in HasDeleteTrails.php, it appears the isSoftDeleting() function is not working as expected. Specifically, $this->isForceDeleting() is returning as null even though the default is false. I changed the function to this:

public function isSoftDeleting() {
        $forceDelete = false;
        if($this->isForceDeleting()) $forceDelete = true;
        return in_array('Illuminate\Database\Eloquent\SoftDeletes', class_uses($this)) && !$forceDelete;
    }

Which is dumb, but it works and deleted_by now has the user id. I don't know why, so hopefully someone with more Laravel framework knowledge can say why my fix is stupid and how to do it the right way. None the less, I figured best to share in case someone else is having issues.

[Paras Malhotra]

@munsterlander it seems you are performing a hard delete on a soft deleted model like so:

$model->forceDelete();

Or alternatively you have overriden the isForceDeleting method. That is the only explanation I can give.

As you can see with #6, all tests are passing on Laravel 8.x. We already are testing for deleted_at updates:

https://github.com/insenseanalytics/laravel-user-audit-trails/blob/master/tests/AuthDeleteAuditTrailTest.php#L20

So, if you can provide a failing test that would be great but I'm unable to reproduce this for now.

[Paras Malhotra]

Closing this issue for now. If you're able to provide a failing test or any steps to reproduce this, feel free to open a new issue. Thanks!

[Munsterlander]

I have done neither of those assumptions. I provided you the exact code. I am not doing a forceDelete on the model. As I provided in the controller, it is simply ->delete(). It is not the deleted_at that is failing. It is the deleted_by that is being set as null. Yes the tests pass but I am telling you, it fails in production. As I said, the object is being returned as null instead of false as you would expect it to be. Regardless, the bypass code works so we can live with that.