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.
| Table of Contents | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
User Group Restricted Objects
In 11.0 we fixed a couple of issues about how user group restrictions were taken into account when the following objects were fetched (both as lists or individually), updated and deleted.
Binary Data (Attachments)
Applies only to configurations where the Advanced Configuration Option useBinaryDataGroupRestriction is enabled (it is by default).
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 they cannot see them.
Note: The users could not download them anyway because the backend would have prevented it.
Quote Types, Compensation Types, Agreement & Promotion Type, Rebate Types
They have always been filtered in lists of objects (there are no Advanced Configuration Options for enabling/disabling filtering).
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 they can see them.
Compensations, Compensation Records, Rebate Agreements, Rebate Records, Agreements/Promotions, Quotes, LookupTable
Applies only to configurations where the Advanced Configuration Option hideXXXBasedOnUserGroups is enabled (it is disabled by default).
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 could not see those objects.
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.
Incorrectly Applied User Group Restrictions
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 Not Checked on Backend
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 should not be able to.
Now we always enforce 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.