There is no automatic filtering for native SQL so tenants should not have access to any functionality giving access to write native SQL or Groovy code (JMX Console, SQL/Groovy bands in reports etc.) .
However, I have a service exposed through a custom rest controller. In the service I have 2 methods querying the same query. one goes through the entitymanger, the other users the datamanager.
When using the datamanager the entities are correctly filtered out, but when using the entitymanager no filtering is applied.
I am not referring to entity permissions. Permissions have an impact on what operations are allowed on a type of entity. Eg. a user is allowed to create instances of type X. What I am talking about is filtering. I should only see entities belonging to my tenant.
These are 2 orthogonal aspects. The security is defined on a class while the filtering is defined at instance level (or record level if you will)
The fact that de documentation explicitly talks about native queries but not about the distinction between EntityManager and DataManager strengthens my idea that both should apply filtering.
Can anyone from @CUBA tell me the exact behaviour? Either the documentation should be updated or a bug should be created.
Everything that CUBA provides from a security perspective is built on top of the JPA layer. JPA itself is unaware of concepts like entity permission, security constraints etc.
If you are interacting with the JPA layer directly without going through the CUBA abstractions, you will not get its benefits (nor its drawbacks).
As the EntityManager is an Abstraction from JPA, you’ll not get row level security etc.
You are right when saying that current documentation page doesn’t explicitly say that you need to use DataManager if you need to auto-apply multi-tenancy constraints.
The link you gave actually only details permission and security checks at type level but not at record level. For this we would need some additional criteria appended on queries.
While Jpa itself doesn’t have support for adding additional record level criteria both Hibernate (@ Filter, @ FilterDef, @ Where, …) and EclipseLink (@ AdditionalCriteria) provide support for this. This is of course targeted at the JPA entitymanager.
So basically, it is not supported but it could have been. Hence my question to clarify.
Multitenancy addon has applied constraints on EntityManager layer since the 7.2 version.
Short description:
Adding multitenancy constraints work on the EntityManager layer for JPQL queries. Multitenancy constraints don’t work for native SQL queries.
If you need auto-applying of tenant constraints, you need to load data with EntityManager/DataManager
All data loaders use DataManager to load their data
REST API also uses DataManager to load data
Reporting: SQL bands don’t apply multitenancy constraints. Those can be applied only if you call DataManager queries inside of a Groovy band or use JPQL bands.
Reporting: JPQL bands work with multitenancy constraints.
