README

This project is a fork of spatie/laravel-activitylog.

Now compatible with Laravel 10.

What we want with this fork is to make it possible for the logs not to be centralized in a single table. Over time, all system logs end up generating a table with many records, and to alleviate this problem, the proposal here is to use the package Tenancy for Laravel to create a second tenant , with the nomenclature having a _logs suffix. And so making each tenant have 2 databases.

To proceed with the implementations of Logs you should still use the documentation from Spetie Laravel-activitylog.

The changes in this package were that an attribute for the useLogName function must always be informed, as this attribute will define the name of the table to save the log data informed by the getActivitylogOptions function applied to the model.

public function getActivitylogOptions()
{
    return LogOptions::defaults()
    ->useLogName('system');
}

Installation

You can install the package via composer:

composer require cerutti-maicon/laravel-activitylog-for-tenancy-for-laravel                          

The package will automatically register itself.

You can publish the migration with:

php artisan vendor:publish --provider="Spatie\Activitylog\ActivitylogServiceProvider" --tag="activitylog-migrations"

Yes, this command remains the same

Compulsorily, you can publish the configuration file with:

php artisan vendor:publish --provider="Spatie\Activitylog\ActivitylogServiceProvider" --tag="activitylog-config"

Note that there are some extra settings tenant_model and tenant_seeder_model. These settings are used to define the template that will be used to create the tenant and the template that will be used to create the tenant propagator. They must be met according to each project implementation.

Create the databases following the prefix pattern for the main tenants:

Example:

tenant_main
tenant_main_logs

After publishing the migration, you can run the migrations with the following command:

php artisan multi_tenants_logs:migrate

The above command also generates the records of the tenants from logs in the tenants table of the application's central database.

Note that there is a run of a seeder that truncates the migrations table. Yes, this is done on purpose, so that the tables created in the tenant logs contain the same tables as the main tenant automatically, so the developer doesn't have to recreate other migrations for this function.

It is extremely important for this package to work that MultiActivity is listed in the project configuration, it is thanks to this that the connections are switched between the main tenant and the log tenant.

Commands

The package comes with some artisan commands to run the migrations and seeder only for the main tenants, the tenant logs should work automatically:

Migrate for Tenant Logs

It must be run for each new table created in the main tenant, in order to be able to generate the logs for it.

php artisan multi_tenants_logs:migrate

Migrate for Tenant Main

It should be executed when the objective is to run migrations only for the main tenants.

php artisan multi_tenants:list

This command lists all tenants in the system

php artisan multi_tenants:migrate

Has --tenants option to run for a specific tenant

php artisan multi_tenants:seed

Has --class and --tenants option to run for a specific tenant

Warning

It is extremely discouraged to continue to use the native commands from the Tenancy for Laravel package.

For example:

php artisan tenants:migrate

This command does not differentiate between the main tenant and the log tenant

Because it is not making any difference between main tenant and log tenant, it would be at your own risk to run migrations from different migration directories (some more basic validations were implemented to prevent these types of errors, but only if you use the native commands of this one package).

License

The MIT License (MIT). Please see License File for more information.