Laravel-activitylog: Set causer globally (inside Jobs)

Created on 13 Aug 2019  路  8Comments  路  Source: spatie/laravel-activitylog

Is there any way to set the causer, globally, to be something else than the logged user? I know is possible to manually log an activity and specify the causer, but I have a Data Importer model that should be related to the events while running inside a Job.

This is what happens when the user creates a Data Importer:

$dataImporter = DataImporter::create(...); // Logs created for DataImporter caused by the user.
\App\Jobs\StartDataImporter::dispatch($dataImporter); // Will queue for processing.

The StartDataImporter will perform all tasks and generate all related models. The causer on those created/updated events should be the DataImporter.


My question is, is there any way to accomplish that? So all models created/updated by the DataImporter will have it as the causer.

enhancement hacktoberfest help wanted revisit for next major version

Most helpful comment

Hey,

atm there's no easy out of the box way. This also duplicates #560 in some parts.
The current dirty workaround could be to use the tapActivity() and associate the causer by reading any global value like a static variable/property, class bound to DIC.

So for example adding a static setActivityCauser() method (via trait) to all models which need it. This sets s static property and during tapActivity() you read this value and if it's a model instance you associate it. And at start of the queue job you call this method for all models with the DataImporter model instance.

For sure we will count your vote on this feature request and think about a better solution to solve it. Because in all three issues there are also other things request which heavily relate to each other it could need some time to find a good way which could solve them.

All 8 comments

Hey,

atm there's no easy out of the box way. This also duplicates #560 in some parts.
The current dirty workaround could be to use the tapActivity() and associate the causer by reading any global value like a static variable/property, class bound to DIC.

So for example adding a static setActivityCauser() method (via trait) to all models which need it. This sets s static property and during tapActivity() you read this value and if it's a model instance you associate it. And at start of the queue job you call this method for all models with the DataImporter model instance.

For sure we will count your vote on this feature request and think about a better solution to solve it. Because in all three issues there are also other things request which heavily relate to each other it could need some time to find a good way which could solve them.

This is actually completely possible as I'm doing it right now. If the Job is running in a queue, then just run the job and pass through the user/id that should be then have an Auth::login call, just be sure to run the associated Auth::logout() call. This will ensure that the user is associated to the generated activity logs and the logout is to ensure there isn't any "session" leakage to other jobs in the same worker. Either way it's totally possible right now.

how does one change the causer inside tapActivity() ?

seems like $activity->causer()->associate($user); does the trick

There is a way to not log the activity if the causer is null ? I just want to log the activity for logged users.

@CharlieRa you could use an observer which returns false in the saving event if the causer is null.

// If the "saving" event returns false we'll bail out of the save and return
// false, indicating that the save failed. This provides a chance for any
// listeners to cancel save operations if validations fail or whatever.

@CharlieRa you could use an observer which returns false in the saving event if the causer is null.

// If the "saving" event returns false we'll bail out of the save and return
// false, indicating that the save failed. This provides a chance for any
// listeners to cancel save operations if validations fail or whatever.

Works perfectly, thanks!

I will close this issue even if v4 isn't released yet. But the task itself is done and I want to check which tasks are really open. Please keep an eye on #787

Was this page helpful?
0 / 5 - 0 ratings