in our application we will have some attributes that are calculated by traversing through the object graph. In most cases, the business logic behind the calculated field is to determine which user is responsible for the object.
On top of that, we have security constraints that are based on the responsible person, i.e. the calculated field.
Is it possible to define Access Group permissions based on the calculated attribute? I guess the answer is no, because of the same reason why it does not work for filters, that is because the calculation of the filter and security rule is perfomed on database level and not in the middleware.
The only solution that I can think of is reimplement the calculation of the attribute in the constraint of the access group, by joining the relevant tables together.
Do you have a different suggestion on how to handle our use case? In a perfect world, we would only want to implement the calculation of the transient attribute once (no matter where, it could be a query or by traversing over the object model in java, whatever…) so that we could reuse the code at different occasions.
Access Group constraints allow you to check entities in memory only - see the “Check Type” drop-down list. In this case, all rows will be loaded from the database to middleware and then they will be filtered out by the Groovy script which you specified in the constraint, and which can work with any attribute, whether it is persistent or not.
The script is executed in the usual context of the middleware, so in theory, you can encapsulate the logic of calculating attributes and checking constraints in some bean or static helper. The {E} placeholder in the constraint script will be replaced with a copy of the checked entity.
Just keep in mind that using “Read” constraint in memory only can potentially lead to loading a large amount of data from the database and immediately throwing it away. Of course, it depends on the nature of your constraints.
I created a lot of objects (100k) to try out the performance of an in memory constraint. The user that was logged in should be able to see half of them (50k) due to his constraint.
When navigating to the browse view, the user did initially see about 25 list entries with no way of navigating to the “next” set. Is this the default behaviour? When I did reset the filter that only selects the top 50 objects to “empty”, I could only see 5k objects without the option to navigate to the next set as well. So basically I was not able to view all my objects.
Is there a way to display the panel where the user can navigate to the next set of rows or is there a different way for the user to navigate through the list entries?
I think it’s a bug (or rather shortcoming) in the platform. We always used DB-level constraints for browse screens, and in-memory checks were only supplementary for filtering nested collections. So now when a screen requests say first 100 rows, middleware loads all 100 but returns to the client only about 50 because your constraints filter out 50% or records. But the screen thinks that there is no more data because the number of results is less than the page size, and doesn’t show the paging buttons.
I thought about this right after answering to your question and was going to check, but you did it before me.
We will try to fix the issue in the recent bug-fix release.