Integration with spatie activity log

[pxpm]

log model attribute changes

Objective: Developers should be able to log attribute changes on their models, and we should provide interfaces to interact with said logs.

At the moment this package provides a trait LogsActivity that provide some log defaults. I think that's ok - ✔️

TODO: [ ] - create LogsActivityOperation

• must create a line button (View Activity) that can be added to the CRUD ListOperation to display on each entry actions column
• must create a top button (View Model Activity) that can be added to the CRUD ListOperation to display all model activity

Developers should be able to add the operation to their UserCrudController and have the following options:

// UserCrudController.php

public function setupLogsActivityOperation() 
{
    $this->crud->setOperationSetting('showTopActivityButton', true);
    $this->crud->setOperationSetting('showEntryActivityButton', true);
}

I think it's also important that developer is able to configure the "display" of said activities. So that he can add filters/columns/buttons in those pages.

We can have sensible defaults like we have for show operation, so the setup methods should be similar like:

public function autoSetupLogsActivityOperation() 
{
    $this->crud->setOperationSetting('showTopActivityButton', true);
    $this->crud->setOperationSetting('modelActivityPageSetup', function($crud) { $crud->addColumn(...); $crud->addFilter() });

    $this->crud->setOperationSetting('showEntryActivityButton', true);
    $this->crud->setOperationSetting('entryActivityPageSetup', function($crud) { $crud->addColumn(...); $crud->addFilter() });
}

public function setupLogsActivityOperation()
{
    $this->autoSetupLogsActivityOperation();
}

Those buttons can call routes pointing to the ActivityLogCrudController passing the "parent controller", in our example UserCrudController as a parameter.

We will then init that class an call the entryActivityPageSetup / modelActivityPageSetup callbacks and display the list to the user with the appropriate columns/filters etc.

Another thing that this package don't cover is the Batch Logs and Multiple Logs, but we can work those out after the "main functionality" implementation.

[tabacitu]

I love that we're finally writing out what we want out of a package, instead of just winging it ❤️

This isn't the format I expected, though. This explanation focuses A LOT on code, HOW a developer can do some things. But it does not explain WHY and WHAT. Without those, it doesn't really make sense. I've read it 3 times and I still don't understand what it means. To properly explain what to do, we need to speak about functionality first. In visuals. What an admin can see and do. That's what matters. The WHY. So let's please rephrase this please.

I think it's also important that developer is able to configure the "display" of said activities. So that he can add filters/columns/buttons in those pages.

I have no idea why we'd add buttons, columns, filters to those operations. How would those operations look in the first place? Why would I want extra buttons, to do what?

---

Please keep the above intact. Then reply in this thread with it rephrased, in a way that starts from FUNCTIONALITY, then follows up with code. The WHY and WHAT, before the HOW. I don't care about the HOW, if I don't understand the WHY and WHAT.

[karandatwani92]

Hello, Awaiting directions on this from Master @pxpm. I see it the same way as @tabacitu described. At the moment, I'm also unable to think of a useful generic implementation of this. It feels this will become a discussion before the code begins. Let us know so we try to complete it before the end of the month.

[pxpm]

Lets try to rephrase this.

From a developer perspective, we need to consider what scenarios this package can cover for them.

1 - It can automatically log model changes by adding a trait to their models. 2 - They can log any arbitrary information in their application (sent mails, paid invoices, events)

So assuming that developer did any of 1 and/or 2, Backpack need to provide interfaces to display/interact with the results of said logs.

I think the majority of developers would need us to cover the following scenarios:

• a "master view" with all activities and ability to filter them out (already provided by this package)

• a "single view" to view a single activity (already provided by this package)

• a "causer/subject view" with only the "caused/subjected" activities A practical example of this views is for example a "regular user" (not admin), to view their account activity, maybe in a timeline style page (more verbose/friendly, less robotic like a table)

  • subscribed to plan x
  • added new team member
  • paid invoice

(optionaly we could provide the following views)

• a grouped(bashed) view (maybe maybe) Similar to the single view but to view a single batch of activities. https://spatie.be/docs/laravel-activitylog/v4/advanced-usage/batch-logs

Similar to the views we should provide easy access to that information with, for example, buttons on a list of logged models. "per model" (each list row) and "for type of model" (on top o the list).

talk technical

So let's assume the current controller we have that has the master view and single view.

We can configure it by creating a new controller that extends the package controller and then binding our new controller in the service provider.

Doing that I can now go overwrite the setup() or setupListOperation() methods and add/modify/remove columns/filters, enable/disable access etc.

The technical part I described in my first comment is related with the implementation of the buttons I mentioned (per row and top buttons). Imagine the "per row button", so that when you click it, you want to get the activity for the causer/subject with ID X. In that case you may want to have configurations specific for each model (you can for example change the "log name" for any model https://spatie.be/docs/laravel-activitylog/v4/advanced-usage/using-multiple-logs), so what I was proposing in my first comment was a way to do this configuration on a per model basis using an operation in the "linked model controller".

Calling the "master view" route with the "linked model controller" as a parameter, and "setup the master view" using the setupActivityLogOperation function from the "linked model controller".

Basically from the operation you setup the "view controller".

[tabacitu]

This is much MUUUCH better Pedro! Well done :clap::clap::clap: Now I understand the purpose of this, excellent!

a grouped(bashed) view (maybe maybe) Similar to the single view but to view a single batch of activities. https://spatie.be/docs/laravel-activitylog/v4/advanced-usage/batch-logs

Hmm don't quite understand how this would look/work or why.

---

That being said, let's postpone this. We don't plan on doing this until the end of the month any more. This month we aren't launching any new features, we're launch v6-beta! 🎉🎉🎉 That's already A LOT 😅 so let's focus on that.

[promatik]

Hey everyone! This is now committed to v6 🙌

As discussed in the meeting, we have the 2 operations/buttons;

• ShowModelActivityLogsOperation
• ShowEntryActivityLogsOperation

I'll close this one 👌