Limits of Multitenancy addon?

Support
#1

Hello!
Although having read posts here about this issue, I’m still not sure, if multitenancy addon solves my challenges.

We need a cascading users’ rights ‘n’ role setup. More than just tenancy with its branches.

tenant |—<| customer |—<| client

There are the tenants with their ‘customers’. A tenant can add his (own) users, let’s call them ‘customers’.
And again, a customer has several ‘clients’. Customer adds his clients.

Of course, controlled by the roles n rights settings, a tenant can only add customers and a customer can only add clients. No one can see its parent’s entities.

To do this job, we gave a user entity a ‘type’ flag and when storing, we automatically set the special roles n rights to the new ‘user’.
No tenant sets rights on his own. No customer sets rights on his own. This is all done by the event handler. Tenants and Customers have no idea about programming :wink:

So,
could multitenancy help here?
We find it strange to having to set an input like tenantName|userName . That cannot be requested by a real life person…

Thanks for your ideas,
best regards
HP

#3

Hello JMIX Team!
Still working on this issue: getting our various users in various roles ‘n’ rights,
we are still not sure, what multitenancy really is useful for and actually try to delete it from our app again.

I expected a tenant as a certain ‘user type’ mark in the users’ entity.
Let’s imagine user types like ‘admin’, ‘tenant’, ‘client’, etc.

Examining the structure as a padding for the username and several add ‘n’ replace (tenantID +"|"…) let’s us hesitate to go forward here with that addon.

Alternatively, maybe I just didn’t understand enough of multitenancy addon,

how can a user (not an admin user) add another user, without knowing about the tenant’s scope he’s working in?
I cannot tell him/her to please add ‘tenantname|’ all the time…

Thanks for your help, assistance, discussion and ideas here,

best regards,

HP

PS, to my excuses, I’m senior (>20years) in VB and SQLServer , but rookie in Java…

#4

Hello, I will try to provide some answers and thoughts.

In general, multitenancy means that the same application and database can be used by different organisations, without seeing each other’s data, unless you define that they can.

With this specific multitenancy add-on, https://docs.jmix.io/jmix/multitenancy/index.html, you have the system filtering entities for you, if they have tenant id annotation, which in turn will have tenant id field in relevant database tables.
However you need to know what you are doing because it works for entities only, not for direct SQL
“so tenant users should not have access to any functionality that provides access to native SQL or Groovy code” - BPM has a script feature with Groovy for example.
Your requirement “tenant |—<| customer |—<| client” is not directly covered with this, as it has tenant-user, one level short. Multitenancy is just a blanket filter, not a replacement for roles.

I think that you don’t really need multitenancy, you first need to create a CRUD matrix
http://www.unified-am.com/UAM/UAM/guidances/guidelines/uam_crud-matrix_F56BDB11.html?proc=_M6m4MchNEdyU89e0dKAsrw&path=_M6m4MchNEdyU89e0dKAsrw,_tBZcMMhSEdyU89e0dKAsrw,_x-13cN8YEdynr9jlfK-aMA,_2xGNwHpfEeSeFZYfCAsIPg

image
it can be done in excel or google sheets no fancy tools needed really. Possibly also capture the process and activities, and then make a process diagram, a diagonalized CRUD matrix for process-entity, not just role-entity.
Then, define the roles Security :: Jmix Documentation and then build UI as needed - it may be that different roles will have slightly different UI views based on what they need to do - don’t be afraid to just copy-paste and modify like in old VB if its easier to have control of and brings less complexity, you don’t need to make several layers of inheritance just for the sake of it.

“We find it strange to having to set an input like tenantName|userName” - several different tenants can have a user with the same username. Since usernames are supposed to be “separate” for each tenant, you need to provide the tenant id, possibly customize the login screen to have a combo box, or provide different login screens for different tenants that would then be tenant-specific. Otherwise, for example, you admit to one tenant’s users to know a username from another tenant and then you get a huge minus during a security audit.

This all depends on your use-case, however.

Kind regards,
Mladen