How to track changes through the model's static::creating() method?

[oleksandr-roskovynskyi]

How to track changes through the model's static::creating() method?

The sample code from the model, logic execution and data change in the database is not tracked here:

public static function boot()
    {
        parent::boot();

        static::creating(function (Cost $cost) {
         // 
                User::update[
                //
                ];
        }
  }

[Gummibeer]

Hey,
so the creation of Cost is tracked but not the update of User?
Do both models use the Spatie\Activitylog\Traits\LogsActivity?
https://docs.spatie.be/laravel-activitylog/v3/advanced-usage/logging-model-events/

[oleksandr-roskovynskyi]

Hey,
so the creation of Cost is tracked but not the update of User?
Do both models use the Spatie\Activitylog\Traits\LogsActivity?
https://docs.spatie.be/laravel-activitylog/v3/advanced-usage/logging-model-events/

Yes, both models use a trait, but operations with the intermediate model (User) are not logged

[github-actions[bot]]

This issue is stale because it has been open 21 days with no activity. Remove stale label or comment or this will be closed in 7 days

[oleksandr-roskovynskyi]

The problem remains relevant

[Gummibeer]

Hey, sorry for the delay.
I've added a testcase for the described scenario 65a454c and it passes.
Do you have any logic or other package that suppresses events on the User model?

[oleksandr-roskovynskyi]

Hey, sorry for the delay.
I've added a testcase for the described scenario 65a454c and it passes.
Do you have any logic or other package that suppresses events on the User model?

extends from others model (not model with this table where you add static::creating() method)
Model User for example...

[Gummibeer]

That the Issue719Sub extends the Article model isn't important for this test. The Article model only unguards itself and defines the table to use.
And that both models use the same table is also not important because the events are triggered per model (php class) and not related to the underlying database in any way.
So the test remains still valid. But if you post a full code example (including all used models and the calling logic) or PR a failing test yourself it would be easier to find the issue. As long as there's no failing test in this repository it's impossible to fix a possible bug.