Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The events (DispatchAudit) are missing the SerializesModels trait #890

Closed
mjawad096 opened this issue Dec 22, 2023 · 9 comments · Fixed by #893
Closed

The events (DispatchAudit) are missing the SerializesModels trait #890

mjawad096 opened this issue Dec 22, 2023 · 9 comments · Fixed by #893

Comments

@mjawad096
Copy link

Q A
Bug? yes
New Feature? no
Framework Laravel
Framework version 10.38.1
Package version 13.6.3
PHP version 8.2.13

Actual Behaviour

The constructor of the model is not being called for a queued audit event. As I'm initializing a protected property in the constructor. So, as the contractor is not called that property is never initialized.

This is due to, the OwenIt\Auditing\Events\DispatchAudit listener missing the Illuminate\Queue\SerializesModels trait which results in a large payload for the queue. Also without this, the models are just hydrated/unserialized without calling the construct. Which also makes an issue for me. As I'm initializing a protected property in the constructor. So, as the contractor is not called that property is never initialized.

Expected Behaviour

The model should be hydrated from the database instead of just unserializing from the job payload.

Steps to Reproduce

Create an auditable model with a constructor to perform some action. .e.g. to initialize a protected model property.
Then perform some action on model create/update.
You'll notice that the constructor is not called.

Possible Solutions

Please use the Illuminate\Queue\SerializesModels trait for both events or at least for OwenIt\Auditing\Events\DispatchAudit.

@parallels999
Copy link

#884 (comment)

@mjawad096
Copy link
Author

mjawad096 commented Dec 22, 2023

I already check this config. But I want to use the queue. For now, I manage it by modifying the serialization's magic method but it does not seem a proper solution. So, it will be appreciated if the SerializesModels trait can be added to the events.

image

@parallels999
Copy link

Question; with that, wouldn't the dirty be lost in case of updating event?

@cangelis
Copy link

cangelis commented Dec 28, 2023

This is also causing Sanctum tests to fail with the error below after upgrading to the latest version of the package.

ErrorException: serialize(): Mockery_1_Laravel_Sanctum_PersonalAccessToken::__sleep() should return an array only containing the names of instance-variables to serialize

Example code:

Sanctum::actingAs($user = User::factory()->create());

// Account is auditable
Account::factory()->for($user)->create();

I can confirm that using SerializesModels trait within OwenIt\Auditing\Events\DispatchAudit solves the issue.

The ones that have this issue should either downgrade or disable the queueing audits by setting audit.queue.enable to false

@parallels999
Copy link

Question; with that, wouldn't the dirty be lost in case of updating event?

Could you test that?

@cangelis
Copy link

the dirty values will get lost once a job with SerializesModels is pushed to the queue as the model is retrieved from the database in the process of restoring the model so the DispatchAudit event should also contain the dirty and the original values seperately instead of using the model as a container.

@angeljqv
Copy link
Contributor

Feel free to make a PR fixing it

@parallels999
Copy link

There are other properties that would be lost besides auditEvent, I don't see it as possible, example auditExclude

$article->auditExclude = [
'reviewed',
];
$article->reviewed = 1;
$article->save();

@parallels999
Copy link

the dirty values will get lost once a job with SerializesModels is pushed to the queue as the model is retrieved from the database in the process of restoring the model so the DispatchAudit event should also contain the dirty and the original values seperately instead of using the model as a container.

@cangelis, you seem to understand the problem well, please review #893

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants