Provides a simple but very efficient Windows-style authorization layer to grant or revoke user permissions or controlling attribute visibility on the editor tab level.
In Contentserv there are various authorization concepts available. They work however mostly on role level, e.g. by adding editing rights on workflow state or language version:
This means, that the user, once he has a role can execute the rights of the role where ever he sees a product or file. Complicated it becomes when the same user should have different view and edit rights per product or product area.
Earlier there was a concept of so-called "Access Levels", that the role could be bound to on one end and the objects can be bound to on the other end. But these access levels are not recommended anymore for performance and usability reasons. For such object rights now there is this Business Solution called "BS Permissions".
Setting up BS Permissions
To use the BS Permissions the following steps are mandatory:
- Deploy the software modules BSLive/modules/alani and BSLive/modules/alanipermission
- Log off and on again to wipe out the plugin cache
- Activate the BS Permissions license checkbox
- Run an update data model to create the data model used by the permissions
- Activate the right "BS / Permissions / Use" to work with the permissions on the role
- Activate the global option "BS / Permissions / Active" to make the permission work. This means you can also deactivate the permissions temporarily if you happened to lock yourself out
Granting and revoking rights
The idea of the BS Permissions follows the classical authorization concepts on tree structures as we can find it on the Windows file system. For each PIM folder or product, permissions can be added or removed. To achieve this there is an attribute "Permissions" in the PIM properties tab where such permissions can be added.
Permissions are technically inheritable relations between products and users or user groups. On these relations between a product and a user then properties can be configured that grant or revoke the right to view or edit the product.
Permissions can be granted or revoked also on a user group in the user tree. The permission then is valid for all users within that group. It is possible to grant on a higher level in the product tree structure and then to revoke further down. Alternatively, it is possible the other way around and to revoke the modification and then grant it further down. This way whitelist and blacklist strategies are possible.
The following permissions are available:
|Right to view an object in the tree|
|Modification||Right to check out, modify and check in an object|
|Creation||Right to create a new object|
Once the dialog is closed the product shows the current permissions:
Further down the product hierarchy existing rights are inherited and can be overruled by adding other or removing rights, just like with any other additive inheritance attribute.
Once the modification has been revoked, the editor can not be checkout, saved or checked in anymore.
Once the viewing has been revoked the product is not loaded in the tree anymore.
Finally, without the creation right, the option to create new children or siblings will be disabled.
Hiding, Showing and Locking of Attributes
Additionally, attribute tabs can be selected that should be visible and/or editable, this way groups of attributes can be removed from the UI or at least locked from editing.
- Visible Tabs: If one or multiple Tabs are selected, all other tabs are removed from the editor
- Editable Tabs: If one or multiple Tabs are selected, all other tabs are locked in the editor, if available
Once the product is loaded a special editor plugin then removes or locks the attributes or prevents the user from checking it out. Also in the tree, a plugin makes sure, that products that should not be visible are not loaded at all.
If tabs are visible but locked little icons are displayed in the tab titles to indicate the editability of the attributes within this tab.
Editable tabs show a green arrow:
Locked tabs show a red lock:
The concept though, can not remove the visibility from search results and listings or other more hidden access points like REST services or API calls. The removal of visibility can for that reason not be "guaranteed". Instead, it is more a kind of friendly guide through the tree structures, which products must not be minded.
In the PIM Studio settings it is possible to configure the PIM editor by using vertical tabs in a tree-style instead of horizontal tab panes:
In such a setup the locking is indicated through the tree-icons:
Disabling workflow actions on object level
Workflow actions can be authorized within Contentserv only on a role level. This means, that in such a workflow all actions can be authorized, but only based on the user role:
If the availability of an action per object or object tree branch is required, the BS Permissions can be used. To do so:
- Revoke the right for modification on the object or branch
- Add the "BS Permissions Validator" plugin to the workflow action you need to prevent
This plugin will remove the workflow action for the user not having the BS Permission to "modify":
In the "BS Permissions Validator" tab of the workflow action, there is a short explanation and a link to
"Add to all Workflow Actions of this Workflow"
This is helpful if you quickly want all actions to be bound to the BS Permissions rules.
In a nutshell
The following PDF gives a simple overview of the BS Permissions Module. This PDF can be used by Salespersons, Business Users, Marketing, etc.
Click here to
See the Video
Click here to see a recording of the webinar about BS Permissions.