The Permissions Editor
Contents
The Permissions Editor shows all the Permissions and allows the user to create, update and delete them. By default, it appears on the menu here:
This is what the Permissions Editor looks like first opened:
Permissions apply to a particular action and Biskit Type. The above screen shot shows all the Biskit Types for which there are Permissions. Note that a Permission can also be defined that will apply to any Biskit Type.
For a complete description of the standard toolbar buttons read the Toolbar Button Standard Definition chapter.
Once all the items in the tree are viewable, the Permissions are viewable in their Action, Biskit Type, Permission categorisation with any that are disabled shown in red.
Click on a Permission in the tree, and the details for that Permission will appear on the right:
Now that a Permission is selected, the button bar is no longer greyed out:
For a complete description of the standard toolbar buttons read the Toolbar Button Standard Definition chapter.
Press the Edit button to make the page to be editable, and the button bar changes:
The main details of the Permission contain all the information represented in the tree on the left. These two screen shots show the details in read-only and in edit mode:
When changing these details:
•The Name can be as required, but should not be the same as any other Permission.
•The Comments can also contain anything and is only there to record whatever notes there are about the Permission.
•The Enabled flag is a way to create a Permission without making it take effect immediately, or to turn one off without deleting it. A disabled Permission shows in red in the tree.
The other properties are described in How Permissions Work.
Conditions underpin much of the configuration that can be done in Calpendo, and they are used in several places (most notably in Workflows). Consequently, they have their own section of this configuration guide. See Conditions for the details.
Please note that the section that describes conditions indicates that the Updated Value and Change condition types are considered an error in some contexts. For Permissions, they are only usable when the Permission action is Update.
In read-only and editable mode, the Applies To tab looks like this:
Include Everybody
If set to true, then this means that the Permission applies to all users, and so the rest of the tab is hidden. As described in Introduction To Permissions, the targeted users are those users covered by the Applies To tab that are not also covered by the Does Not Apply To tab.
Individual Users
This allows the specification of particular users that the Permission should apply to.
User Groups
The Permission will apply to.any user in the specified groups.
Property Path
A Permission property path works exactly the same as the property path in an Email Workflow Action, and it is described more fully in that section. The property path is a property or list of properties that lead from the Biskit Type defined on the Permission to a user or user group, and those users will also have the Permission applied to them.
User Roles
Users can have multiple roles. Any number of roles can be selected by ticking the check box next to the role, and then choose with the drop-down whether the Permission is to apply to users that have all of the selected roles, or users that have any of the selected roles.
This tab is almost identical to the Applies To tab. The only difference is that the check box at the start is labelled Exclude Nobody instead of Include Everybody. When ticked, it means that no users are taken away from the Applies To list of users, and so the rest of the Does Not Apply To tab will be hidden. When unticked, the users that should not be targeted are selected.