What is the proper set up for a master admin and then each tenant has their own admin?

[osean-man]

I've been playing around with this for a while and what I want to accomplish is multitenancy where each tenant can access their own admin. I've gotten as far as actually getting /admin to work but I can't create an admin user for the tenant. How is this done?

Also, what is the best way to set up the main application where I can manage the customers / tenants?

Here is my settings.py configuration:

TENANTS = {
    # ...
    "www": {
        "APPS": [
            "django.contrib.auth",
            "django.contrib.sessions",
            "django.contrib.admin",
            'django.contrib.messages',
            "django.contrib.staticfiles",
            # ...
            "website",
        ],
        "DOMAINS": ["localhost"],
        "URLCONF": "website.urls",
    },
    # ...
    "public": {
        "APPS": [
            "django.contrib.contenttypes",
            "django.contrib.staticfiles",
            # ...
            "django_pgschemas",
            "customers",
            # ...
        ],
    },
    # ...
    "default": {
        "TENANT_MODEL": "customers.Client",
        "DOMAIN_MODEL": "customers.Domain",
        "APPS": [
            "django.contrib.auth",
            "django.contrib.sessions",
            "django.contrib.admin",
            'django.contrib.messages',
            'django.contrib.staticfiles',
            # ...
            "frontend",
            "accounts",
            # ...
        ],
        "URLCONF": "frontend.urls",
    }
}

Whenever I try to createsuper on for the base site, I get this:
django.db.utils.ProgrammingError: relation "auth_user" does not exist LINE 1: ...user"."is_active", "auth_user"."date_joined" FROM "auth_user...

I'm in dev and just experimenting so if I have to start over, I'm fine with it. I think this last issue with creating superusers is because of a migration mistake I made.

[lorinkoz]

Users can either be placed at the tenant level, or at the system level. If you place users at the tenant level, then users will be enclosed in that tenant, and one user will not be accessible outside the scope of its own tenant. If you place users at the system level, users will have access to all tenants, and you must provide yourself a "binding" between users and tenants, so that authentication / authorization behaves accordingly. These are the only options.

In your case, seems like you need users to be able to access multiple tenants. For that, you must place your user model in the public schema, and you must have in place your own control for determining which users have access to which schemas (e.g. User -> Tenant M2M relation.) With that, your authentication mechanism should check not only validity of credentials, but also whether the authenticating user has access to the target tenant.

[osean-man]

Thanks for the reply. What I am ultimately going for is this:

Master Admin - > controls the tenants/customers

Tenant Admin - > each tenant has their own admin where they can manage their information (specifically for that tenant). Obviously each tenant would have a front end where they can use the app for it's purpose.

Website admin -> static tenant to handle the website of the application, specifically.

I guess, the big issues I'm having is the master admin portion of this. What would be the right way to set that up? Do I have both public users for the master/public and tenant schemas?

Finally, how do I create the initial superuser for a tenant? I can't seem to figure this out.

I appreciate your time and response. Thank you!!

[lorinkoz]

Your users should go in the public schema. Additionally, you have to control which users have access to which schemas (that's on you, because by placing the users in a schema that is accessible to all other schemas, without proper controls, any user could access any schema.) In this case, let's suppose you will have a User.is_superuser and also a UserRoleOnTenant model. When implementing your authentication views (or hooks if using a 3rd party autentication app) you would have to run at least two checks after the user has provided valid credentials: (1) if user is superuser, then authentication can go on (2) if user has any role in the tenant it's trying to log into, then authentication can go on. The rest of cases should fail, even if credentials are correct. This is somewhat equivalent to how Django currently checks for the is_active flag in the user, where even after providing valid credentials, inactive users cannot log in.

Since your user model will be in the public schema, there is no extra magic for running the createsuperuser management command.

---

In a separate world, if you didn't have the need for superadmins, your user model would be placed on each tenant-specific schema. Here you don't need a binding between users and tenants, because by placing the model in a tenant schema, users are only accessible from within the tenant. In this case, if you needed to create a superuser (for whatever purpose) you would have to enclose the createsuperuser command in runschema, because Django provided commands are by default tenant-agnostic and would fail with an error similar to what you have stated (database error, model not found) because the user model is not found in the default schema, which is the public schema. Then, you would do something like manage.py runschema -s <target_schema> createsuperuser.

[osean-man]

Thank you for the very well described answer. I appreciate it and it seems I'll need to be reading up more on Django in general to accomplish this.

Thanks again and great library!