12-15-2011 10:44 AM
I have two domains in my NUXEO instance: domain1 and domain2.
I would like:
In other world: how to be sure users from domain1 have no interaction with users from domain2 ?
12-16-2011 10:37 AM
Hi,
This is an interesting subject and we start to work on it.
To take into account the tenant context, Nuxeo has extended API of
- Directory Service,
- Core Repository Session
- and User Management Service.
Into our implementation, declaring a document as a root of a tenant amounts to add a tenant local configuration on it (i.e. a metadata). This solution is dedicated for cheap multi-tenant implementation and low service level for isolation of:
But I start to tell you that we "start to work on it". This means development is not finished and developments are visible only into the foundation of Nuxeo and not yet into the UI part. You can find the add-on that treats this subject here: https://github.com/nuxeo/nuxeo-multi-tenant
So the answer to your question is: you can't yet until we improve UI to take into account the evolution of the foundation. If you want to contribute you are sincerely welcome, but as there is no customer behind that and this is not a priority for us the development progression from us is slow. If you have a strong need you can contact us as our Roadmap is agile.
To give you a full answers, implementing a real and strong isolation through the application level is not a good way, as many questions comes:
Answers to all these questions above means you go through each service and take into account of the tenant. We will not plan to do the job for all our services.
But, resolution of multi-tenant with the high isolation level will be resolved in Nuxeo in another level: through the cloud and multi-Nuxeo instance. If you follow our Roadmap you may know that we plan to work on Cloud solution and simplification of Nuxeo provisioning. Our goal is bringing high simplification of Nuxeo provisioning and management. So isolation of database, documents, users, workflows is trivial, idem for Backup/Restore of a tenant.
Regards,
12-16-2011 10:37 AM
Hi,
This is an interesting subject and we start to work on it.
To take into account the tenant context, Nuxeo has extended API of
- Directory Service,
- Core Repository Session
- and User Management Service.
Into our implementation, declaring a document as a root of a tenant amounts to add a tenant local configuration on it (i.e. a metadata). This solution is dedicated for cheap multi-tenant implementation and low service level for isolation of:
But I start to tell you that we "start to work on it". This means development is not finished and developments are visible only into the foundation of Nuxeo and not yet into the UI part. You can find the add-on that treats this subject here: https://github.com/nuxeo/nuxeo-multi-tenant
So the answer to your question is: you can't yet until we improve UI to take into account the evolution of the foundation. If you want to contribute you are sincerely welcome, but as there is no customer behind that and this is not a priority for us the development progression from us is slow. If you have a strong need you can contact us as our Roadmap is agile.
To give you a full answers, implementing a real and strong isolation through the application level is not a good way, as many questions comes:
Answers to all these questions above means you go through each service and take into account of the tenant. We will not plan to do the job for all our services.
But, resolution of multi-tenant with the high isolation level will be resolved in Nuxeo in another level: through the cloud and multi-Nuxeo instance. If you follow our Roadmap you may know that we plan to work on Cloud solution and simplification of Nuxeo provisioning. Our goal is bringing high simplification of Nuxeo provisioning and management. So isolation of database, documents, users, workflows is trivial, idem for Backup/Restore of a tenant.
Regards,
Find what you came for
We want to make your experience in Hyland Connect as valuable as possible, so we put together some helpful links.