The following areas might be a source of issues when starting to use the version Paper Plane 11.x, so please make yourself familiar with this section.
| Child pages (Children Display)toc | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
User Group Restricted Objects
In 11.0 we fixed a couple of issues about how user group restrictions where were taken into account when the following objects were fetched (both as lists or individually), updated and deleted.
...
When userGroupdEdit and userGroupViewDetails are specified and the user has no group assigned, then
...
:
In previous versions,they could see those objects in lists.
NOW Now they cannot see them.
Note: The users couldn’t could not download them anyway because the backend would have prevented it.
...
When a user has no group AND only one of the two userGroupXXX fields is null, then
...
:
In previous versions,they could not see those objects in lists.
NOW Now they can see them.
Compensations, Compensation Records, Rebate Agreements, Rebate Records, Agreements/Promotions, Quotes, LookupTable
...
If userGroupEdit is not defined and userGroupViewDetails is specified, and the user is not in one of those view groups, then
...
:
In previous versions, they couldn’t could not see those objects.
NOW Now they can see them.
Note: This will probably be a rare case because it makes no sense from a business point of view to specify a view group but no edit group. The correct rules to follow are documented in Entitlement Concept.
...
Group restrictions have sometimes been incorrectly implemented when fetching lists of domain objects, mostly when using Advanced Configuration Options to enable filtering (
hideXXXBasedOnUserGroups, see the table in the Groups section of Entitlement Concept).These issues are now fixed, which in lists of domain objects can mean that users may now see objects they had access to but were incorrectly filtered out when
userGroupEditwas not specified.
...
Group restrictions were sometimes not checked on the backend, so a user could bypass the UI via the REST API to, e.g., modify an object they shouldn’t should not be able to.
Now we always enforce them restrictions for fetching/updating/deleting individual objects.
The UI was already correctly checking the domain objects against those rules, so mostly there are no changes from the user point of view here.