Background work and tenants

In an app with a tenant: (Tenancy), each kind of background work reaches a stated set of tenants, and "no tenant" means the same thing for each: only the records every tenant shares (Background work):

Work	Reaches
A schedule's run	Every tenant's records: no tenant's event starts it. A run by hand, and a test's `.run()`, too
A subscriber's delivery	The tenant its event's one field of the tenant's `id` type names (`household_id: Household.id`), so the tenant is written in the event where a reviewer sees it. With no such field, more than one, or `none` in it: no tenant's records, only those every tenant shares
A batch's run	The tenant its saved values of the tenant's `id` type name, values naming the same tenant counting as that one (Batches, tenants and grants). With none, `none`, or values naming different tenants: no tenant's records, only those every tenant shares
The magic-link `send:` action	The tenant of its delivery, as a subscriber's: `jadpo.MagicLinkEmail` names none, so no tenant's records, only those every tenant shares (Magic links)
A webhook's reply action, and `on_first_sign_in:`'s	No tenant's records, only those every tenant shares: each runs as the system inside a request no tenant's event starts, and "no tenant" is never every tenant for them

A schedule names no tenant, so it reaches every one. A subscriber and a batch name theirs by a value, and a value that names no tenant never widens what they reach. The system's runs inside a request (the sign-in email's send: action, a webhook's reply action and on_first_sign_in:'s) reach no tenant's records. In an app without a tenant:, each reaches every record the system is granted.

The value naming a subscriber's or a batch's tenant must come from a record of that tenant, which its action reached under its caller's policy. Otherwise it is policy.event_tenant_unproved (Background work). So a caller can never aim background work at a tenant they don't belong to.

Related