That's ok for us. I just wanted to make sure we are not missing anything fundamental.
If I use the shared database, the tenant is created in the shared (host) database specified by the default connection string from the app settings.
If I do not use the shared database (as in the screenshot in my previous post) then I specify a database connection string for the new tenant. Then entities for the tenant are stored via that connection string which may point to a different database.
With the option for separate schemas for host and tenant enabled, it is ensured the migrations only create the relevant tables depending on whether the db contains host and/or tenant via the two db contexts - as you also explained. This works fine.
We want all new tenants to be created in another database. But we do not want to manually specify the connection string each time. I know we could create the tenants programmatically and set the connection string. But before we do so I want to know if there is an intended way that we are missing or that is not well-documented on how to achieve this without additional code.
Yes, the definitions of the tenants always go into the host db. But we can specify an alternate connection string for the tenant upon creation and that works as intended. But manually specifying a connection string via UI isn't what we expected from the feature.
Thank you for your response. We understood the migrations part. It's more the overall concept as we expected b the description of the option that there would be a way to specify a default connection string for new tenants. We tried changing the connection string attribute of the MyProjectNameTenantDbContext but as we found out this only applies to the migrations, not to creating new tenants.
Is there an out-of-the-box way or are we supposed to explicitly set a connection string when creating new tenants that should not go into the host db?
We created a solution with the separate schema for host and tenants option enabled with the goal to have a second database that will only contain the tenant-related data. Our hope was that we can specify a second connection string that would be used by default for new tenants. The option though seems to apply to the migration path only. Our first guess to edit the connection string attribute of the ...TenantDbContext did not result in the desired behavior and I think this isn't the intended way.
Manually specifying the desired connection string works
Is there an out-of-the-box feature to accomplish what we want to achieve? Did we miss something?
In the identity module the German translations for the two-factor options are incorrect. It should be "Optional", "Deaktiviert", "Erzwungen". "Behinderte" refers to people with disabilities and not to the state of something not being active. While the translation "Gezwungen" for "Forced" in English is ok, "Erzwungen" would be a bit more common.
Is there a way we can contribute to improve localization in the commercial modules?
Thanks, the packages could now be restored.
We have a Business license. The packages are Volo.CmsKit.Pro.Common.Application Volo.Payment.Iyzico.Domain.Shared Volo.Payment.PayPal.Domain.Shared Volo.Payment.Payu.Domain.Shared Volo.Payment.Stripe.Domain.Shared Volo.Payment.TwoCheckout.Domain.Shared Volo.CmsKit.Pro.Common.Application.Contracts The problem started yesterday (more packages where affected but these remain)
CMSKit (pro) and Payment still won't restore for me.
For me the problem still persists.
