Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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.

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.

  • No labels