mirror of
https://github.com/archtechx/tenancy.git
synced 2026-06-20 22:54:05 +00:00
> Minor breaking change: Pending tenants would previously go through the creation pipeline as *not* pending and would only be marked as pending after full creation. Now, pending tenants go through the creation process with pending_since set from the start. Pending tenants aren't getting their `pending_since` set until they're created completely (e.g. their DB was created, migrated and seeded -- first, the tenant is created fully, and only after that, the tenant is updated to have `pending_since`). This is a problem if someone wants to e.g. add a job to the `DatabaseCreated` job pipeline that would check `$this->tenant->pending()`. Since at the point of `DatabaseCreated`, the tenant's `pending_since` isn't set yet, `$this->tenant->pending()` returns `false`, even for tenants created using `createPending()`. So instead of letting the pending tenant get fully created, and only after that, setting its `pending_since` (using `update()`), we now set `pending_since` in `create()`. `CreatingPendingTenant` is now dispatched from the `static::creating` hook, and `PendingTenantCreated` is dispatched from `static::created` for consistency. Setting `pending_since` right in `create()` made the `MigrateDatabase` and `SeedDatabase` jobs exclude the pending tenants during their creation if the `tenancy.pending.include_in_queries` config was set to `false` -- in that case, these jobs would never migrate or seed the databases of pending tenants. So these jobs now pass `--with-pending` to their underlying commands, with the value set in their `$includePending` static property (`true` by default). This overrides the `tenancy.pending.include_in_queries` config -- unless the `$includePending` properties are set to `false`, these jobs will always include pending tenants. The `--with-pending` tenant command option originally worked just to opt-in for including pending tenants in the command. Now, `--with-pending` can accept values (`true`/`1` or `false`/`0`), so e.g. - `tenants:run foo` with `--with-pending`/`--with-pending=true`/`--with-pending=1` includes pending tenants - `tenants:run foo` with `--with-pending=false`/`--with-pending=0` **excludes** pending tenants (also `--with-pending=foobar` -- invalid input, considered `false`) Passing `--with-pending` makes the command bypass the `tenancy.pending.include_in_queries` config (so e.g. if `tenancy.pending.include_in_queries` is set to `true`, and `--with-pending=false` is passed to a command, the command will exclude pending tenants). When `--with-pending` is not passed, the command will include or exclude pending tenants based on the `tenancy.pending.include_in_queries` config. --------- Co-authored-by: Copilot <copilot@github.com> Co-authored-by: Samuel Štancl <samuel@archte.ch> |
||
|---|---|---|
| .. | ||
| Actions | ||
| Bootstrappers | ||
| Commands | ||
| Concerns | ||
| Contracts | ||
| Controllers | ||
| Database | ||
| Enums | ||
| Events | ||
| Exceptions | ||
| Facades | ||
| Features | ||
| Jobs | ||
| Listeners | ||
| Middleware | ||
| Overrides | ||
| Resolvers | ||
| ResourceSyncing | ||
| RLS | ||
| UniqueIdentifierGenerators | ||
| helpers.php | ||
| Tenancy.php | ||
| TenancyServiceProvider.php | ||