What is the expected behavior of the platform when setting an attribute to “hide” for a given role ?
See below for instance “marginRate” on a “ProductSalesCondition” entity is set to “hide” for the role “sales_assistant”, and this is causing the infamous “unfetched” error.
I was rather expecting the attribute to be loaded to null.
If it is normal that the security restriction is implemented through not fetching the field, it is close to unusable.
In fact, I’m not even sure of what to do, writing some code in the hundreds of screens in the app to hide all fields that are not permitted and change the views ?
Platform version 7.2.17. Roles policy version 1 for compatibility. I’m currently trying to migrate to role policy version 2 hoping to tackle the issue.
Is there a way to use wildcards for screens in order to implement “has access to all screens except these ones” ? Without that role definition is actually quite difficult to read, see screenshot below.
Also, if through a role I give rights to “modify all Customer fields but hide margin fields” to a user, will I have “unfetched” each time a loading view contains these fields ?
EDIT functional case is the following : a Sales Assistant can create and modify Orders, but they cannot see the margin amount and margin rate of Orders.
Regarding unfetched problem, did you set the following app property?
cuba.entityAttributePermissionChecking=true
As far as I see its default value is false and data is actually being loaded into entity, but UI fields are hidden.
Also, even if I set the value to true, I get nulls in hidden fields, not unfetched errors. Could you provide a sample project where we can reproduce the issue, if it’s still relevant? Of course, moving to the new security mechanism will be a better choice:)
No, it’s not possible out-of-the-box. You’ll have to explicitly grant permissions to specific screens, entities, etc. in order to be sure that users will have access only to the things that must be available for them.
As for readability, you may use role designer in Studio, no need to define role manually.
If you want to define your own “wildcard” support in roles you may write method implementations in role classes that will return anything you want. Take a look at this discussion for some starting point.
Sorry, but we are not going to implement new features in CUBA. All development goes in Jmix.
Perhaps you can get the list of screens from the WindowConfig bean at runtime (see getWindows() method) and save it in a form suitable for copy-pasting into your role definitions.
If there is no more development on cuba 7.2, what is the level of support we can expect and until when ? Migration is not a one-minute topic, and if at some point I’m forced to migrate my apps, I would like to know.
I think we can agree on the following point : any serious project has hundreds or thousands of permissions to setup. This is exactly at this point that you need tools.
The tool (Studio) promotes “enhancing developer productivity”. If the answer to the bulk edition requirement is “you should produce the text definition by grep/whatever”, it simply means the screen is useless for serious projects.
As developers when our users/clients come to us saying “it is out of question that I click each line one by one” we propose something, this is business as usual, and it never rises tensed debate as the one between @albudarov and @tom.monnier. In fact it is core to the purpose of IT an automation in general.
Using the platform since 2016, I started my last big project before the rise of JMix, shall I be cursed for that ?
So you can count on fixing critical security vulnerabilities and data loss bugs for free until March 01, 2025.
We also strive to provide Studio updates for each newer version of IntelliJ, at least until we found a major obstacle.
Unfortunately, we cannot afford implementing new feature requests for versions at the maintenance stage, especially if there are workarounds.
