Models Reference

The django-tenant-users extension introduces specialized models to handle multi-tenancy in Django applications. This page delves into the intricacies of these models, providing insights and examples to help developers integrate and customize them effectively.

TenantBase Model

The TenantBase model is central to the multi-tenancy architecture. It represents each individual tenant or client within your application.

class TenantBase(*args, **kwargs)

Bases: TenantMixin

Contains global data and settings for the tenant model.

slug

A wrapper for a deferred-loading field. When the value is read from this object the first time, the query is executed.

owner

Accessor to the related object on the forward side of a many-to-one or one-to-one (via ForwardOneToOneDescriptor subclass) relation.

In the example:

class Child(Model):
    parent = ForeignKey(Parent, related_name='children')

Child.parent is a ForwardManyToOneDescriptor instance.

created

A wrapper for a deferred-loading field. When the value is read from this object the first time, the query is executed.

modified

A wrapper for a deferred-loading field. When the value is read from this object the first time, the query is executed.

auto_create_schema = True

Set this flag to false on a parent class if you don’t want the schema to be automatically created upon save.

auto_drop_schema = True

USE THIS WITH CAUTION! Set this flag to true on a parent class if you want the schema to be automatically deleted if the tenant row gets deleted.

delete(*args, force_drop=False, **kwargs)

Override deleting of Tenant object.

Parameters:

• force_drop (bool) – If True, forces the deletion of the object. Defaults to False.

• *args – Variable length argument list.

• **kwargs – Arbitrary keyword arguments.

add_user(*args, **options)

remove_user(*args, **options)

delete_tenant()

Mark tenant for deletion.

We don’t actually delete the tenant out of the database, but we associate them with a the public schema user and change their url to reflect their delete datetime and previous owner The caller should verify that the user deleting the tenant owns the tenant.

transfer_ownership(*args, **options)

class Meta

Bases: object

abstract = False

get_next_by_created(*, field=<django.db.models.fields.DateTimeField: created>, is_next=True, **kwargs)

get_next_by_modified(*, field=<django.db.models.fields.DateTimeField: modified>, is_next=True, **kwargs)

get_previous_by_created(*, field=<django.db.models.fields.DateTimeField: created>, is_next=False, **kwargs)

get_previous_by_modified(*, field=<django.db.models.fields.DateTimeField: modified>, is_next=False, **kwargs)

owner_id

schema_name

A wrapper for a deferred-loading field. When the value is read from this object the first time, the query is executed.

User Model

The User model in django-tenant-users is tailored to support multi-tenancy. While each user is primarily associated with a specific tenant, ensuring data isolation, the architecture also supports global users that can span multiple tenants.

class UserProfile(*args, **kwargs)

Bases: AbstractBaseUser, PermissionsMixinFacade

Authentication model for django-tenant-users stored in the public tenant schema.

This class represents an authentication-only model that is centrally located in the public tenant schema, yet maintains a link to the UserTenantPermissions model for authorization. It enables a singular global user profile across all tenants while allowing permissions to be managed on a per-tenant basis. This design ensures a unified user identity across different tenants with distinct permission sets in each tenant context.

Access to a user’s permissions requires routing the request through the relevant tenant. The implementation necessitates using the ModelBackend for proper integration.

Inherits:

AbstractBaseUser: Django’s base class for user models, providing core user authentication features. PermissionsMixinFacade: A facade to adapt Django’s PermissionMixin for multi-tenant environments.

USERNAME_FIELD = 'email'

objects

tenants

Accessor to the related objects manager on the forward and reverse sides of a many-to-many relation.

In the example:

class Pizza(Model):
    toppings = ManyToManyField(Topping, related_name='pizzas')

Pizza.toppings and Topping.pizzas are ManyToManyDescriptor instances.

Most of the implementation is delegated to a dynamically defined manager class built by create_forward_many_to_many_manager() defined below.

email

A wrapper for a deferred-loading field. When the value is read from this object the first time, the query is executed.

is_active

A wrapper for a deferred-loading field. When the value is read from this object the first time, the query is executed.

is_verified

A wrapper for a deferred-loading field. When the value is read from this object the first time, the query is executed.

class Meta

Bases: object

abstract = False

has_verified_email()

delete(*args, force_drop=False, **kwargs)

get_short_name()

get_full_name()

Return string representation.

last_login

A wrapper for a deferred-loading field. When the value is read from this object the first time, the query is executed.

password

A wrapper for a deferred-loading field. When the value is read from this object the first time, the query is executed.

UserProfile Manager

The UserProfileManager is a custom manager for the UserProfile model. This provides additional methods and utilities for user-related operations.

class UserProfileManager(*args, **kwargs)

Bases: BaseUserManager

create_user(email=None, password=None, *, is_staff=False, **extra_fields)

create_superuser(password, email=None, **extra_fields)

delete_user(user_obj)