Download the PHP package sinclairt/multi-tenancy without Composer
On this page you can find all versions of the php package sinclairt/multi-tenancy. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download sinclairt/multi-tenancy
More information about sinclairt/multi-tenancy
Files in sinclairt/multi-tenancy
Package multi-tenancy
Short Description Multi tenancy solution inside a single app and single database
License MIT
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package multi-tenancy
Multi Tenancy
Installation
Register the service provider in the config/app.php array:
Optional
Publish the config:
Config
ignore-roles default([ 'super-admin' ])
if you don't want your app to apply the multi-tenancy constraints add the roles here, I've assumed super-admin out of the box, but feel free to change this or leave as an empty array if you're not using roles
public-space-roles default(['super-admin'])
if you would like to protect your public domain with auth routes, you can set which roles should be allowed access to this area
relationship name default('tenant')
this is the name of the relationship method on your models, the plural is assumed for many-to-many
relationship table default('tenants')
name of the tenant table
relationship class default(\App\Models\Tenant::class)
class name of the tenant model
relationship polymorph-term default('tenantable')
the polymorphic term used in you models relationships
relationship foreign key _default('tenantid')
the foreign key used on your models tables
relationship slug column name default('slug')
the column where the slug is stored on the tenant table
should apply callback default(null)
if you want to use custom logic to decide whether to apply the scopes set you callback here the user object and ignored roles array are passed into this
should apply default default(true)
if true will automatically apply the scopes to the models, this is only used if the callback is null and the ignore roles are empty
role class default(\App\Models\Role::class)
The name of your role class - leave as an empty string if you're not using roles
Set Up
Inside config/auth.php you will need to set up a new guard and a new provider like so:
You may also like to set the default guard to tenant or set an if statement up, otherwise you will need to specify the guard when interacting with the Auth object:
The multi-tenancy package works by using global scopes to restrict queries based on a constant . This package assumes you are using a sub-domain to control which tenant is required by your user; there is a helper function to place inside bootstrap/app.php , but, of course, you are free to set the constant however you wish, but in order for this package to work it must be set.
Usage
To avoid having a foreign key on every single database table, the multi-tenancy package uses a models relationships to constrain queries. There a three ways a model can be connected to a tenant:
-
Directly - the model belongs to the tenant
-
Through - the model belongs to the tenant through another model or chain of models
- Morph - the model belongs to the tenant via a many-to-many relationship (polymorphic included)
There are three scopes that can be applied based on the criteria above, and there are traits to ease the implementation for two of them: the and scopes have respective traits, just use them in your models and that's it.
The other scope requires a little more set up, but only a little, all you need to do is set the relationship(s) to go through to get to the tenant when applying the scope in the models boot method, for example:
The vehicle model in the example above belongs to the Tenant in one way or another and so we will go through this relationship to get to the tenant.
You can also use dot notation to chain relationships i.e. driver.user, this applies when there are series of relationships to go through to get to the tenant.
One final scenario is if your model is a polymorphic many-to-many and could potentially belong to the tenant through various channels, easy, pass in an array of all the potential links to the tenant, the multi-tenancy package only needs to find one:
In this example we have a Phone model which stores numbers against various models: users, drivers, and locations, so we need to check whether it belongs to our given tenant through any of those connections.
User Model
Because the multi-tenancy package allows you to have a single database, it means a user can belong to more than one tenant if you want them to, useful for admin roles (although I recommend using the ignore-roles config value). If you use the sub-domain solution for multi-tenancy this will force the user to login to new tenant areas but it means they can have the same credentials, roles, and permissions across tenants.
Your User model needs to use the trait if you are using roles, it provides a piece of logic for the scopes, but it also uses the trait and sets the roles relationship for you. If you're not using roles, be sure to use the trait in your User model.
