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

Set causer globally (inside Jobs) #582

Closed
neeonline opened this issue Aug 13, 2019 · 8 comments · Fixed by #866 or #787
Closed

Set causer globally (inside Jobs) #582

neeonline opened this issue Aug 13, 2019 · 8 comments · Fixed by #866 or #787
Assignees

Comments

@neeonline
Copy link

neeonline commented Aug 13, 2019

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.

@Gummibeer
Copy link
Collaborator

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.

@ragingdave
Copy link
Contributor

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.

@lsmith77
Copy link

lsmith77 commented Jun 5, 2020

how does one change the causer inside tapActivity() ?

@lsmith77
Copy link

lsmith77 commented Jun 5, 2020

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

@CharlieRa
Copy link

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

@Gummibeer
Copy link
Collaborator

@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
Copy link

@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!

@Gummibeer Gummibeer mentioned this issue Sep 16, 2020
Merged
9 tasks
@nagi1 nagi1 mentioned this issue Apr 9, 2021
10 tasks
This was linked to pull requests Apr 19, 2021
Merged
nagi1 referenced this issue in nagi1/laravel-activitylog Apr 24, 2021
@Gummibeer
Copy link
Collaborator

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

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

Successfully merging a pull request may close this issue.

5 participants