@JpqlRowLevelPolicy is not applied when using genericFilter in Flow UI ( Jmix 2.7.4 )

Support
#1

Hi,
In a standard list view, I have a CollectionLoader, a genericFilter bound to that loader, a row-level role with @JpqlRowLevelPolicy on the same root entity loaded by the view.
The expected behavior is that the final result should always be JpqlRowLevelPolicy AND genericFilter condition
However, in practice, when the user applies a condition using genericFilter, the @JpqlRowLevelPolicy does not seem to be respected anymore, and entities become visible that should remain restricted by the row-level role.

Important details, the policy is defined on the same root entity as the loader and the view uses a standard Flow UI collection loader. There is no custom loadDelegate but if I add a @PredicateRowLevelPolicy, the result becomes correct again, but performance is much worse.

So it looks like:
@JpqlRowLevelPolicy alone → not correctly applied when genericFilter is used
@PredicateRowLevelPolicy → works as a workaround, but is too slow for real use

This makes me think the issue is specifically in the interaction between genericFilter and @JpqlRowLevelPolicy.

Has this been reported already?
Is it a known bug or limitation in Jmix 2.7.4?

Thanks.

#2

Hi,

I cannot reproduce this problem.

  • Opened https://github.com/jmix-framework/jmix-onboarding-2 project
  • Run the app, logged in as admin
  • Added flowui-filter role to alice user
  • Logged in as alice with password 1
  • Opened Users view
  • Added a condition to the generic filter
  • The app still shows only the users permitted by the HrManagerRlRole row-level role

Please provide a test project where the problem is reproduced.

Regards,
Konstantin

#3

Thanks Konstantin,
One important detail in my case is that the application uses REST DataStore, not direct database access. According to the documentation, REST DataStore applies entity operation policies and predicate row-level policies, but it does not say that it applies @JpqlRowLevelPolicy on the client side.

This matches what I see: when I add a @PredicateRowLevelPolicy, the restriction works, but with @JpqlRowLevelPolicy alone the genericFilter result is not restricted as expected. So maybe this is not a genericFilter bug itself, but a limitation of using @JpqlRowLevelPolicy together with REST DataStore.

In my case, the initial CollectionLoader result is already restricted, so some row-level security is clearly being applied. The problem appears specifically after applying genericFilter, where the filtered reload no longer respects the expected restriction. Since genericFilter is documented as adding a condition to the loader, this looks like an issue in the interaction between genericFilter, REST DataStore, and row-level security rather than expected behavior.

#4

Right, the REST DataStore doesn’t apply @JpqlRowLevelPolicy because it has no access to the database.

But the genericFilter component on the client side generates conditions that are passed to the server side in JSON and translated to JPQL and then to SQL and effectively filter on the database level.