Replicate TenantConfig for Central App ?

[trane77]

Hello,

In the project I'm currently working on, we adopted tenancy for Laravel in single database mode: tenants access to the same DB, resources, and assets.

We're relying on T4L mainly to load configurations specific for each tenant. These configurations are labels, blade templates, and not much else.

I followed this guide in order to have dynamic configurations, based on the detected tenant.

I'm wondering if it's possible to use the same concept for the central app.
Do you have something already available or this requires some custom development?

My idea is something like this:

1. Add a new column in the tenants table ((bool) is_tenant) to differentiate between tenant or central app records
2. Modify T4L TenantConfig feature (or add a new feature class), to read the config from the record with is_tenant == false, in case no tenant has been detected (basically tenant() == null.
3. Raise an error whenever multiple records with is_tenant === false are present, as this would make central app identification impossible.

What do you think about this? Do you see any problem in this logic or have any suggestion?

In case this is not available already, I can submit a PR once the feature is ready.

Let me know.

[stancl]

Not really sure what you're asking about here.

I'm wondering if it's possible to use the same concept for the central app.

If you're talking about TenantConfig, then all that feature does is change Laravel's config, which is as easy as doing config(['foo' => 'bar']);. The feature is just a wrapper around that to read these mappings from a tenant.

[trane77]

Hello @stancl, yes, I'm referring to TenantConfig: it allows to save some configurations and retrieve them for each tenant.

That requires the following (AFAIK):

• the application must be a tenant
• a record must be present in the tenants table
• the configuration you want to access must be defined in config(tenants.tenant_config.storage_to_config_map) (json property -> config key mapping)

This is nice, but as far as I understood, TenantConfig is not available for the central app as it doesn't have a record in the tenants table.

I hope it's more clear now :)

[stancl]

I don't understand how the feature would work in the central context. Any tenant records are irrelevant. Tenants are stored centrally in fact, otherwise they couldn't be accessed during identification in the first place.

All that happens is:

1. Tenant is identified from a request
2. Tenancy is initialized
3. The feature is executed
4. The feature does config(['foo' => tenant()->bar])

If you want to change the config in central context, there's no way for this feature to work when it's entire purpose is to work with data from the current tenant.

You can just change config yourself as needed.

[trane77]

I'm trying to say that it could be used when both tenants and the central app share a common configuration structure (e.g. in case of emails: the sender name must differ when sending an email from the central app, or a tenant app).

Anyway I see you've already closed before understanding the context.

Poor communication here.

[stancl]

the sender name must differ when sending an email from the central app, or a tenant app

You put the central config in the appropriate file. You tell TenantConfig how to change said config in the tenant context. That way, you have separate config in the central and tenant contexts.

If you cannot clearly communicate what you're trying to achieve but feel entitled to your issue staying open indefinitely, then go blame other people's "poor communication", I do not think we can have a productive conversation here.