Laravel-activitylog: store custom fields in "activity_log" table in the database

[Ahmed-Nasser]

Hi there this the my first time using this awesome lib, I want to know if it's applicable to add extra fields in activity_log database table to store more information about the event e.g I want to store the username and phone serial number that logged into my system.

$table->uuid('code'); $table->string('username'); $table->string('imei'); $table->string('sim_nmuber');
the above columns are the fields that I want to add in the log and I want to store some values how can I do such a thing using the library.

[Gummibeer]

Hey,

if you've added these columns to your database you can use an observer https://laravel.com/docs/5.8/eloquent#observers to fill those columns. This will be the best solution if you want to do it for every activity.

If you want to fill specific activities, all related to a given model for example - this package provides a tap() and tapActivity() method.
https://docs.spatie.be/laravel-activitylog/v3/advanced-usage/logging-model-events/#tap-activity-before-logged-from-event

[vaibhavpandeyvpz]

Just like @Gummibeer suggested, you can use observers for this. But better (not best) practice would be that those CUSTOM fields should either be part of causer or the subject. Rest depends on your use case.

[Gummibeer]

@vaibhavpandeyvpz I'm sorry but I have to disagree with your second sentence.
There are valid cases when it's not possible to rely on the values stored in one of the related models. There are cases when it's important to save an email, subscription or anything else with the value it had the moment the activity was created. The related models can change over time.
It's something like the orders table in online-shops, which have to persist everything with the value it had during the moment of the order.
But for sure you shouldn't use the activitylog as some kind of data persistence when these values aren'T persisted in another table.

[vaibhavpandeyvpz]

@Gummibeer For those cases, I added the third sentence. 😉

[Gummibeer]

@vaibhavpandeyvpz just wanted to clarify, because you wrote "best practice" - some not so experienced developers will take this as is and think "if it's best practice I will have to do it like this".
That's why it's sometimes dangerous with those general sentences.
I just remember a bug that survived for over a decade in tripple-A business applications because of such a stackoverflow recommendation.^^

[crThiago]

@Gummibeer Hello, is it possible to rename the 'description' column?
In my application is another name

[wrabit]

@Ahmed-Nasser @Gummibeer Is there a reason why you would't want to utilise the withProperties() method / properties field for this?

Maybe performance concerns if filtering by these attributes, or parsing the json data?

[Gummibeer]

@crThiago at the end it is possible. You only have to change all code places and keep them updated with every release. Possibly it would also work to add description as an appended (accessor & mutator) attribute to your overridden activity model and pipe it to your database description attribute.
But what's wrong with this name? Or why do you need to rename it on this package model?

@wrabit I've never said that withProperties() is a bad idea. 😉
The point I was about is the fact that you sometimes have to persist data in the activity even if it's available on a related model. If you want to do it in a custom column or the already existing JSON one is up to your, your database, what you want to do with the data and for sure your personal preferences.

[crThiago]

@Gummibeer There is no problem with the 'description', but my database is all in Portuguese and I wanted to keep this standard, but I think I will create this exception because this project is awesome, congrats!!

[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