◄ ► | Edit | Home | Admin | en de fr et | Sign in

#5904 (Multitenancy (multiple "user spaces, "ledgers" or "communities"))

by Luc Saffre · in Developers · assigned to Luc Saffre

Summary

My current plan is packed into the userspaces branch. I believe that it would work, but right now we have no real-life use case.


A new model users.UserSpace with just a name field.

New plugin setting users.with_user_spaces.

New models 'users.UserSpace' and 'users.Membership'.

New field User.current_space points to UserSpace.

Plugin method get_default_userspace().

New class attribute Model.interspace_models = False

All models having this True automatically get a field 'userspace' injected (a non-nullable pointer to users.UserSpace),

When a model is interspace, get_request_queryset() adds a filter(user_space=ar.get_user().current_space) and on_create() sets that field to User.userspace.

There will be one SiteConfig per userspace. And dd.today() will move from Site to BaseRequest or User because it needs the userspace.

Should users be able to switch between the different user spaces of which they are members?


The word for this is multitenancy, so I'd replace "user space" by "tenant".

Which tenant to use for anonymous user? A default tenant in the settings?

Should a multitenant Lino site have only one shared Site instance for all tenants?

Don't we want each tenant to choose their language distribution? Which would mean that each tenant has their own site cache.

So even settings.SITE would actually just become a property, which would return a different Site instance dependaing on whats the current tenant.

The current tenant would be a variable similar to the current language, i.e. it would be set by the middleware, and we would have a module lino.core.tenants, similar to django.utils.languages.

Children

Comments