Bug description

QueueTenancyBootstrapper will not recognize changes to Tenant Data until tenancy()->initialized is called.

1. Tenant1 job arrives on the queue and is processed
2. Tenant1 attribute data is updated.
3. Tenant1 job arrives on the queue but since tenancy was already intialized the tenant data does not get updated for the currently initialized tenant

Looks to be the result of QueueTenancyBootstrapper::initializeTenancyForQueue code snippet (or setUpJobListener in 3.4.6)

  if (tenancy()->initialized) {
      if (tenant()->getTenantKey() === $tenantId) {
          // Tenancy is already initialized for the tenant (e.g. dispatchNow was used)
          return;
      }
  }

This prevents the tenancy initialization that occurs after this snippet.

Instead of return here what would be the implications of calling tenant()->end() ?

Unsure whether the If statement was only performance related. In the scenario above if Tenant2 job arrives and is processed prior to the 2nd Tenant1 job then when 2nd Tenant1 job is processed tenancy is intialized and correct attribute data is reflected.

Steps to reproduce

1. Send job for Tenant1 to a queue
2. Run Queue worker (and leave running) and output to log the data attribute you will change in point 3 below
3. Edit Tenant1 data attribute
4. Send job for Tenant1 to queue and output the data attirubte in point 3 below 3
5. The old data attribute will appear

Expected behavior

1. Send job for Tenant1 to a queue
2. Run Queue worker (and leave running) and output to log the data attribute you will change in point 3 below
3. Edit Tenant1 data attribute
4. Send job for Tenant1 to queue and output the data attirubte in from point 3
5. The new data attribute will appear

Laravel version

8

stancl/tenancy version

3.4.6 and 3.5.1

Resolved conflicts in #782

Original description

As discussed here #779, this PR adds a new feature to this package: pending tenants.

This adds:

• Four new config settings: pending.include_in_scope, pending.count, pending.older_than_days and pending.older_than_hours
• Two new commands (tenants:pending and tenants:pending-clear)
• A hasPending trait that contains a pendingScope which was inspired by the SoftDelete trait.

All of this can be combined with the scheduler to automatically have x amount of tenants ready to be used and link to a new client/domain and skip the time of creating and migrating (and seeding) the client database.

As discussed sometime on Discord I'm opening a PR to use Github Actions native services and shivammathur/setup-php. This way we don't have to maintain a Dockerfile for this project anymore and immediately allows us to test on PHP 8.1 (so #792 is redundant).

Version 3.x of Tenancy for Laravel is now in open beta.

3.x is mostly a ground-up rewrite. It's focused on making the package much more flexible by using an event-based architecture and it brings "enterprise" features such as synced resources (e.g. users) between tenant databases, user impersonation, easy Cashier integration, and others.

The documentation is being rewritten completely, and soon also the website will be rebuilt completely.

Added

(All of the previous features, including mutli-database tenancy and automatic tenancy mode are still part of the package.)

• [x] Shared resources between tenant databases (e.g. users)
• [x] Single-database tenancy traits
• [x] Manual mode of tenancy (model traits etc)
• [x] Rich event system
• [x] Job pipelines
• [x] Path identification
• [x] Subdomain identification
• [x] Native Eloquent support -- tenants are now Eloquent models (easier Cashier, Nova, etc integration)
• [x] User impersonation
• [x] Nova resources for managing tenants
• [x] Fully featured example SaaS application to see how the package is used in production

Join our Discord to share feedback, get more updates and join the beta: https://discord.gg/7cpgPxv

Describe the bug

• When we use $tenant->run() to perform query on another tenants from central/tenants context it should work as expected. for example : $tenant->run(function () { User::create(...); });

Above code works fine when we have session driver set to SESSION_DRIVER=files. But if we set session driver to SESSION_DRIVER=database . it fails and give Call to a member function prepare() on null.

Steps to reproduce

• Make env file to use SESSION_DRIVER=database
• Run tenants specific query.

Expected behavior

• It should run the tenant specific query and return to central or whatever tenants we calling from.

Your setup

• Laravel version: 6.2.x
• stancl/tenancy version: 3.4.0
• Storage driver: DB
• Session Driver : DB

Love the package!

I'm just wondering if anyone has any advice on how to create temporarily signed URLs for a tenant, from inside the central app?

The problem I'm trying to solve is creating a user for a tenant from inside the central app and using https://github.com/spatie/laravel-welcome-notification to send a welcome email.

I'm able to create the user fine, I've also been able to send out the email but the temporary signed URL is always that of the central app, I've even tried overriding the sending/building of the email to be inside initaializeTenancy code block.

eg.

        tenancy()->initializeTenancy($this->tenant);

            $this->showWelcomeFormUrl = URL::temporarySignedRoute(
                'welcome', $this->validUntil, ['user' => $this->user->id]
            );

            return (new MailMessage)
                ->subject('Welcome to my app')
                ->action(Lang::get('Set initial password'), $this->showWelcomeFormUrl);

        tenancy()->endTenancy();

Any help would be greatly appreciated.

Reading your comments on #270 I thought I should queue the database migration, but after setting queue_database_creation to true in config/tenancy.php I get this error:

You cannot serialize or unserialize PDO instances. 

Comming from src\Illuminate\Queue\Queue.php:139.

This is my configuration:

		'queue_database_creation' => true,
		'migrate_after_creation' => true, // run migrations after creating a tenant
		'migration_parameters' => [
			 '--force' => true, // force database migrations
		],
		'seed_after_migration' => true, // should the seeder run after automatic migration
		'seeder_parameters' => [
			'--class' => 'DatabaseSeeder', // root seeder class to run after automatic migrations, e.g.: 'DatabaseSeeder'
			 '--force' => true, // force database seeder
		],

Bug description

I'm trying to upgrade from 3.4.5 to 3.5.0, but when accessing a Tenant I am getting an error

Stancl\Tenancy\Exceptions\DatabaseManagerNotRegisteredException
Database manager for driver is not registered.

It seems to have been caused by the changes made in https://github.com/archtechx/tenancy/commit/73a4a3018cadca2ba0fb5f2130fca1718a2b3670

It's this line, https://github.com/archtechx/tenancy/commit/73a4a3018cadca2ba0fb5f2130fca1718a2b3670#diff-570b873722200ff149851a2e1c3c016ed87596744cc8b8e5be003760a825f974R81, where it is now unsetting the database.connections.tenant config.

I am using the PostgreSQLDatabaseManager.

Steps to reproduce

n/a

Expected behavior

Connect to the Tenant database successfully.

Laravel version

8.78.1

stancl/tenancy version

3.5.0

Hi, I've write a CRUD controller to manage tenants. After the creation phase I try to migrate database calling the related artisan command in this way: \Artisan::call('tenants:migrate', [ '--tenants' => [$tenant['uuid']] ]); but the process fail with an exception

Symfony \ Component \ Console \ Exception \ CommandNotFoundException The command "tenants:migrate" does not exist.

Then to resolve this issue I've clone the command in the App\Console\Commands directory. When I run the creation process from controller the tenants()->create('sub.domain') command create the tenant and create the database but fail running the migration with this exception

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'tenant51fc8900-bd14-11e9-812f-bf18d2921640.migrations' doesn't exist (SQL: selectmigrationfrommigrationsorder bybatchasc,migrationasc)

I noticed that the problem occur also when I run the migration for all tenants from the terminal `php artisan tenants:migrate Tenant: 0263c840-ba6c-11e9-801a-a932495b9d33 (marco.itplog.com) Nothing to migrate. Tenant: dabfa100-bce9-11e9-8818-c51ed3718fe9 (umb.itplog.com)

Illuminate\Database\QueryException : SQLSTATE[42S02]: Base table or view not found: 1146 Table 'tenantdabfa100-bce9-11e9-8818-c51ed3718fe9.migrations' doesn't exist (SQL: select migration from migrations order by batch asc, migration asc)

at /home/vagrant/Code/rat/vendor/laravel/framework/src/Illuminate/Database/Connection.php:664 660| // If an exception occurs when attempting to run a query, we'll format the error 661| // message to include the bindings with SQL, which will make this exception a 662| // lot more helpful to the developer instead of just the database's errors. 663| catch (Exception $e) {

664| throw new QueryException( 665| $query, $this->prepareBindings($bindings), $e 666| ); 667| } 668|

Exception trace:

1 PDOException::("SQLSTATE[42S02]: Base table or view not found: 1146 Table 'tenantdabfa100-bce9-11e9-8818-c51ed3718fe9.migrations' doesn't exist") /home/vagrant/Code/rat/vendor/laravel/framework/src/Illuminate/Database/Connection.php:326

2 PDO::prepare("select migration from migrations order by batch asc, migration asc") /home/vagrant/Code/rat/vendor/laravel/framework/src/Illuminate/Database/Connection.php:326

Please use the argument -v to see more details.`

But no errors when I run from terminal the single tenant migration php artisan tenants:migrate --tenants=dabfa100-bce9-11e9-8818-c51ed3718fe9 Tenant: dabfa100-bce9-11e9-8818-c51ed3718fe9 (umb.itplog.com) Migration table created successfully.

How can I resolve this blocking issue?

Thanks

@stancl, I'm drafting this as a follow-up on the comments on BC. From the conversation:

Samuel:

The general goal is that sometimes, it's appropriate to delete tenant DBs when running migrate:fresh. Reason: when you run migrate:fresh you generally expect your DB to become clean, so it'd make sense to also delete databases.

Some thoughts: We probably only want to delete DBs of the tenants that are currently in the tenants table and will be removed when migrate:fresh runs. We don't want to use any logic like detecting tenant DBs based on the configured prefix (e.g. tenant_) because someone could have those DBs for other purposes such as testing (e.g. tenant_tests) We can't modify the default Laravel command, but we likely also don't want to add a new command. One way to handle this could be checking if migrate:fresh dispatches any events. I think migrate does, so migrate:fresh could have some specific ones too. Then, we could simply do Tenants::all()->each->delete() or something like that in a listener

me:

The migrate:fresh command dispatches a bunch of events. DatabaseRefreshed is the most specific one (before that gets dispatched, there's a bunch of StatementPrepared and QueryExecuted events, and these probably aren't useful to us). Also, the migrate:refresh command dispatches DatabaseRefreshed too, so the event is not specific to migrate:fresh.

Maybe this is too hacky, but it's the most accurate thing I found so far:

There's a CommandStarting event. The event has a $command property which we can access, and if we call migrate:fresh, the property's value would be "migrate:fresh". So we could listen for that event and if the property's value equals "migrate:fresh", delete the tenant databases.

I have a problem.

in tenant.php

Route::middleware([ 'auth', 'web', InitializeTenancyByDomain::class, PreventAccessFromCentralDomains::class, ])->group(function () {

Route::get('/', 'DashboardController@dashboard')
->name('index');

Route::get('dashboard', 'DashboardController@dashboard')
->name('dashboard');

});

error:

Symfony\Component\Routing\Exception\RouteNotFoundException Route [login] not defined.

Help Please.!

Closes https://github.com/archtechx/tenancy/issues/529

This PR allows defining the template connection using an array like this:

'template_tenant_connection' => [
    'driver' => 'mysql',
    // ...
],

You can still use the connection name from config/database.php like this:

'template_tenant_connection' => 'mysql'

So, both approaches work with this PR.

Why this should be added

For my current project I am using Tennacy for Laravel and Laravel Lighthouse (a framework for serving GraphQL from Laravel). This means I have 1 endpoint for GraphQL queries, which is /graphql. I would like to get data from the tenant databases by using a header, which is possible by using the InitializeTenancyByRequestData identifier and disabling the queryParameter by setting it to null. However, when I use this identifier I lose the ability to access the central database if I leave the header empty because it will throw an exception. This exception can easily be handled by setting the $onFail callback. As a workaround I created a new middleware (php artisan make:middleware InitializeTenancyByHeader) to solve this problem. In this middleware I extended the InitializeTenancyByRequestData since it works as intended but is missing onFail logic for this specific case, so I add the desired config and onFail logic to it:

namespace App\Http\Middleware;

use Illuminate\Http\Request;
use Stancl\Tenancy\Resolvers\RequestDataTenantResolver;
use Stancl\Tenancy\Tenancy;
use Stancl\Tenancy\Middleware\InitializeTenancyByRequestData;

class InitializeTenancyByHeader extends InitializeTenancyByRequestData
{
    public function __construct(Tenancy $tenancy, RequestDataTenantResolver $resolver)
    {
        parent::__construct($tenancy, $resolver);
        self::$onFail = fn (\Throwable $exception, Request $request, \Closure $next) => $this->onFail($exception, $request, $next);
        self::$queryParameter = null;
    }

    public function onFail(\Throwable $exception, Request $request, \Closure $next)
    {
        if($request->header(self::$header)) {
            throw $exception;
        }

        return $next($request);
    }
}

Using this middleware I can do the following:

• Query from the central database by omitting the X-Tenant header.
• Query from a tenant database by putting a valid tenant id in the X-Tenant header.
• If the tenant doesn't exist it will throw the exception to tell me that it, in fact, does not exist.

I thought it would be great if there was a default option to make the header and/or queryParameter optional.

Description

I have 2 proposals:

1. The "optional by type" approach: Setting $header or $queryParameter on InitializeTenancyByRequestData to null would keep the current behavior and setting them to false would make them optional.

// Throw exception when header is missing
$header === null 
$queryParameter === null
// Continue request when header is missing
$header === false 
$queryParameter === false // Continue request

2. The "static parameter" approach.

InitializeTenancyByRequestData::$optional = true; // Default: false

1, 2 or both?

Proposal 2 may work for other identifiers too, but for this one it makes the most sense and would be easy to implement without breaking changes.

Note:

This feature request is a "nice to have" and not an imminent issue that is bothering me. Just sharing thoughts on improving since I commonly use this package as a multi tenant solution in my projects :) Also, there could be a good reason on why this is a terrible idea. Which, if so, I would like to learn more about.

This PR makes broadcasting work with Tenancy using both public and private channels. It also allows using different broadcaster credentials for each tenant.

BroadcastTenancyBootstrapper maps the tenant attributes to config so that the broadcasters use the credentials of the current tenant. It also overrides the BroadcastManager singleton with an instance of TenancyBroadcastManager.

TenancyBroadcastManager re-resolves the broadcasters instead of getting them from the $drivers property so that the broadcasters always use credentials from the current config.

The issue with re-resolving the broadcasters

We need to make the broadcasters use the credentials from the config every time we initialize tenancy. Also, the freshly resolved broadcasters need to have all the channels registered in routes/channels.php, or else broadcasting won't work.

Ideally, we'd just forget the BroadcastManager instance without overriding it, similarly to the mail credentials PR. But then, the cached channels will be gone.

So instead of forgettingBroadcastManager, I'm extending it with the custom TenancyBroadcastManager. During the extension, I'm also "passing" the broadcaster from the original manager to the custom manager instance so that I'm able to take the channels from the original broadcaster, and make the newly resolved broadcasters have the channels. Since $channels isn't a public property, I used invade() to access them.

I'd like to find a less ugly, non-invade() way to make the newly resolved broadcasters have the channels. I tried calling require base_path('routes/channels.php') in the manager so that the file registers the channels for the currently bound broadcaster, but that results in an infinite loop (because of the Broadcast::channel() calls in routes/channels.php).

@stancl, could you please take a look at the diff and let me know your thoughts? Also, this is a draft because there are no tests yet, and it's likely that the implementation will change.

Bug description

I am facing a problem while running some jobs with queues combined with tenants:run.

I am executing a company command with a heavy job inside (usually i had a supervisor making this task but has been disabled for debugging), all jobs are sent to Redis before will be processed.

The problemas arrives when command is executed for all tenants, in that case, every time I try to run the command, a new connection is open for each tenant keeping previous one open, and finally provoking a collapse in MySQL throwing "Too many connections" when running via supervisor.

Currently problem is solved using queue:listen instead but the performance is better with queue:work command.

Example: 3 tenants in my system, 2 tenants:run iterations executed and you can see duplicates connections.

Steps to reproduce

• Execute php artisan queue:work myCustomQueue --tries=3 --sleep=3 (queue is ready to accept jobs)

• php artisan tenants:run company:myCommand

Expected behavior

Keep connections open by tenant and use it instead of create new one.

Laravel version

8.83.18

stancl/tenancy version

3.5.7

todo update description after resolving reviews.

This PR adds the ability to bootstrap features early in the request life cycle. In simple words, You can bootstrap the feature without waiting for tenancy initialization. We are calling these tenant unaware feature.

Solution

PR introduces the new config key, which is an array of tenant-unaware features. For now, CrossDomainRedirect is added to this array. This also closes https://github.com/archtechx/tenancy/issues/949

Usage

You add your own tenant unaware feature in tenancy.php.

'tenant_unaware_features' => [
        Stancl\Tenancy\Features\CrossDomainRedirect::class, // https://tenancyforlaravel.com/docs/v3/features/cross-domain-redirect
       // ... add yours
    ],

Improvements

With the old approach, I noticed that the "$tenancy" object is passed but the tenancy is not initialized at this point. This happening because tenancy is not initiated yet. Maybe that's why current feature classes are not making use of the tenancy parameter. One feature was using actually, to add macro, but macro can be added statically like Tenancy::macro.

So the following got changed.

• Removed the $tenancy parameter from the Feature interface bootstrap method. Now all tenant unaware & aware features have the same abstractions.
• Tenant-aware features are being bootstrapped in the ->resolving(Tenancy) event. That means we can use DI.

The question can be how to develop tenant-aware features. Most probably using the Tenancy events.

closes #531

This PR adds support for cache prefix mode for separating tenant caches using a bootstrapper that can be enabled. The bootstrapper simply adds the prefix for cache keys.

Note: It does not work for the file driver.

Usage

enable bootstrapper in the tenancy.php config.

'bootstrappers' => [
        Stancl\Tenancy\Bootstrappers\DatabaseTenancyBootstrapper::class,
        // Stancl\Tenancy\Bootstrappers\CacheTenancyBootstrapper::class,
        Stancl\Tenancy\Bootstrappers\FilesystemTenancyBootstrapper::class,
        Stancl\Tenancy\Bootstrappers\QueueTenancyBootstrapper::class,
        Stancl\Tenancy\Bootstrappers\BatchTenancyBootstrapper::class,
        Stancl\Tenancy\Bootstrappers\PrefixCacheTenancyBootstrapper::class, // prefix cache keys
        // Stancl\Tenancy\Bootstrappers\RedisTenancyBootstrapper::class, // Note: phpredis is needed
    ],

That's it. Your cache keys are prefixed now.

The cache will behave like this.

cache()->put('key', 'original-value');

tenancy()->initialize($tenant1);
cache('key') // returns null;
cache()->put('key', 'value-for-tenant1');

tenancy()->initialize($tenant2);
cache('key') // returns null;
cache()->put('key', 'value-for-tenant2');

tenancy()->end();
cache('key') // returns 'original-value';

tenancy()->initialize($tenant1);
cache('key') // returns 'value-for-tenant1'

tenancy()->initialize($tenant2);
cache('key') // // returns 'value-for-tenant2'