This is the documentation for Clover Club 12.0.
Documentation for the upcoming version Rampur 13.0 can be found here.
Upgrade to Paper Plan 11.x Troubleshooting
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.
- 1 User Group Restricted Objects
- 1.1 Binary Data (Attachments)
- 1.2 Quote Types, Compensation Types, Agreement & Promotion Type, Rebate Types
- 1.3 Compensations, Compensation Records, Rebate Agreements, Rebate Records, Agreements/Promotions, Quotes, LookupTable
- 1.4 Incorrectly Applied User Group Restrictions
- 1.5 Group Restrictions Not Checked on Backend
User Group Restricted Objects
In 11.0 we fixed a couple of issues about how user group restrictions where 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 couldn’t 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 couldn't 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 couldn’t 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 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
userGroupEdit
was 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 shouldn’t be able to.
Now we always enforce them 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.