When group constraints are in effect, table totals are wrong

I tried to apply group constraints like in the example in your docs here: https://doc.cuba-platform.com/manual-6.5/local_admins_example.html.
Then, if I login with an user that has that constraints applied, and try to load some data in a table component, the total rows displayed are not reflecting the actual rows displayed in the table (that are filtered by the constraint), but the total rows in the table as if the constraint were not applied.

IMHO this is misleading from the user’s point of view, and the total should reflect the actual number of rows filtered by the constraints.


Hi Paolo,

Normally, the total number of rows shown above the table is affected by security constraints. Could you create a test project demonstrating the problem or at least provide the query and constraints text?

Also, adding “distinct” to your query may help, see explanation here: https://doc.cuba-platform.com/manual-6.5/query_with_distinct.html

I’ve just done some research (with trial and error procedure), and found that it wasn’t a constraint, but a role setting…

In my case I combined the following advices in your docs:

  • create a denying role (default) that denies everything
  • create several additive roles: internal-user adds some basic capabilities to all internal users, administrative (not system admins, but company admins) adds more power, for example the ability to see User Sessions, and then other specific roles
  • create an access group hierarchy like:

    access constraints are applied from Company level downwards, and system administrators belong to the System group (without restrictions).

Now the problem arises from the fact that there are no wizards or docs stating which System entities are required for which screen
For example, in my case I added the allow flag for the User Sessions screen in my administrative role, but then the screen also needs at least Read permission for the sec$UserSessionEntity entity, and I wasn’t aware of that (found that only after trying it).
If the user has a role that Allows the User Sessions screen, but it doesn’t have Read permission for that entity, the table shows no records at all, but the total above the table shows the number of active sessions (see screenshot).

The permissions system is effectively powerful, and fine-grained, but needs more documenting for the System level entities/attributes. This is something you should publish ASAP, to avoid such trial-and-error I am facing now…


Screen Shot 2017-06-05 at 17.45.29

I noticed you tagged the post as “not a problem”. Whilst I agree that’s not a problem of access groups, the problem remains for role permissions.

What you see in the screenshot is misleading from a user’s point of view. If the user does not have the right to read from an entity, but it has permissions for showing a screen (I know it’s an edge case, but it could happen), the totals shown above the table should reflect what the user effectively sees, that is 0 rows…

I can’t change the title of the post, otherwise I’ll change to “Table totals do not reflect actual records displayed when user’s role does not have read permission”.

And regarding the role’s permissions system, I’ll open a separate case if you don’t want to track it here, but I see the need for a faster way to set cascaded permissions for certain operations. That is, if I allow some screen, I’d like to have a sort of wizard or hint that tells me exactly what are the dependencies for that screen, at least for using it for reading only, or reading/writing. (example: if I allow the User Sessions screen, it should tell me that the sec$UserSessionEntity entity permission is needed).


Hi Paolo,

The problem with rows number is very specific for the user sessions screen, because it shows non-persistent entities which are not affected by standard security mechanisms. So in general table totals are affected by security.

Based on your feedback, we have fixed the problem for user sessions too, see https://youtrack.cuba-platform.com/issue/PL-9227.

However, I wouldn’t recommend giving permissions on any screen in the Administration menu to anyone except superusers (global admins). An exception can be managing Users, Roles and Access groups for local administrators as explained in the docs. All other screens give too many possibilities to break your system and this possibilities are very hard to control through the standard security mechanism.

As for your ideas on improving the security management and documentation, please create separate topics - it will be much easier to track.