Log only dirty attributes + some attributes always

[borex]

Hi guys!

I couldn't find a solution for this in the issues and discussions, so I'm going to write it here.
My problem: I want to log only dirty attributes and some attributes that should be always be in the log for tracking. For example: if I want to log changes made to a user I want it to always log the username plus the changed data. User changes e-mail address or phone, then the log should contain username, e-mail address or phone number.

I couldn't find a solution for this, so this is what I have done:
I have added a static field to my model:
protected static $alwaysLogAttributes = ['name'];
From Traits\DetectsChanges.php file I have moved the attributeValuesToBeLogged function to my model and made the following change in it:
` if ($this->shouldLogOnlyDirty() && isset($properties['old'])) {
$tmp = array_udiff_assoc(
$properties['attributes'],
$properties['old'],
function ($new, $old) {
if ($old === null || $new === null) {
return $new === $old ? 0 : 1;
}

                return $new <=> $old;
            }
        );
        $properties['attributes'] = collect($properties['attributes'])
            ->only(array_merge(static::$alwaysLogAttributes, array_keys($tmp)))
            ->all();
        
        $properties['old'] = collect($properties['old'])
            ->only(array_keys($tmp))
            ->all();
    }`

This solution works for me for now. I would like to know if it's good to do it this way or is there a better solution to achieve this.
Thanks.
Best regards,
Bx

[Gummibeer]

Hey,

for your specific described scenario: do you really need the username during event or the one the user has right now?
You can always use the causer and subject relationships to retrieve "live" data.
But yeah, if one these is deleted you would end with user#42 afterwards - so I can see your reason.

At the end we've introduced the tap() and tapActivity() methods for exactly this kind of requirements. With these you can manipulate the activity model in every way you want - fill custom columns, add custom properties or whatever. Another solution would be an observer on the activity model.

Because the attribute you want to always log hasn't changed, otherwise it would be dirty, you don't have to manipulate the trait but use one of the described solutions. These are upgrade save and don't conflict with future changes.
I would also recommend you to put the always attribute on the root of the properties JSON instead of the old or attributes sub arrays or even add custom columns like causer_display_name.

As a short retro: the tap() logic was probably the most powerful addition to the package because it allows you to manipulate EVERYTHING on the activity model without altering the package itself.

[borex]

Hi, thanks for the answer, but:
Maybe the username example wasn't so good example :), I didn't refer to the causer. That is getting stored fine for the activity. Let's say we have a Project model, that has a title, description and status. If I change only the status of the project and I have log only dirty turned on, in the activity log I will have only the status change saved.

Having a list where I display the activity logs, I don't really wanna get the project title through the activity subject to make the log more readable and see what project got updated. I was thinking to always store the title of the project in the log next to the dirty attributes. Also, using the activity subject to get a live object and display the title requires additional code in the activity list. If you have a lot of models, you have to write code for each of the to display a title, a name or whatever important attribute you need to display so the user viewing the activity knows which model got updated.
If I use the tap methods then I will have to add the tap logic to all my models to store an attribute that I always want it to be in the log, even when it hasn't changed. I hope I got the tap logic right or did I miss something?
This is why I was thinking to have an array on the model, set the fields that I always want to get logged and the rest is taken care by the activity module. I don't have to add extra logging code to the controller or model. I love this part of the module.

[Gummibeer]

Why I don't recommend to alter the package logic in a direct way is that you will have to update it everytime the package changes it.

Some ideas to make it easier for:

• Use the observer instead of the tap method and check for the subject (it's optional)
• Add a subject_display_name column to the activity model (you have to use your own model and tell the package to use it in the config) it only has to add the new column to fillable
• Add an interface like Displayable which defines a getDisplayName() method
• Check if subject implements the interface and fill the column

If you want to use life data the interface would solve this too because in view you only call the method.

Last but not least I would also accept a PR adding your property to the package itself.