This article presents an example that gives permissions so that only authorized users can execute a List and its corresponding Detail of a Work With object. The idea for Panel objects is the same.
Note: It is not possible to manage the List and Detail permissions independently (or all the sections of the Detail). That is to say, the permissions apply to all or none of them as a group.
Suppose you have a "Novel" Transaction object to which the Work With pattern has been applied. The purpose is to allow only authorized users to see the "Novels" List and view the detail.
1. Set Enable Integrated Security property to True.
2. Set the "WorkWithNovels" Integrated Security Level property to Authorization.
3. Define a Role (for example, Role1) with a certain Permission (for example, with the default Permission Access Type ("Allow")). The permission name must be <prefix>_execute, where the prefix is the value of the Permission Prefix property specified for the WW object (in this case: Novel_Services).
As a result, only users who have this role can execute the "Work With Novels" object in order to display the list of Novels and view the detail of each of them.
User's role that allows executing the Work With Novels
In the case of Menus, permissions are not verified. That's why the only available values for Integrated Security Level property are "none", and "Authentication" in this case.
If you configure the "Authentication" value in this property for Menu objects, the behavior is not the same as the behavior for Panels or WW Panels: when trying to execute the Menu for the first time, the object specified for the Login Object for SD property will execute. However, in the following executions, the validity of the session is not checked for Menus so the login object will display again only when the user tries to execute another private object that is called from the Menu.
Example: Suppose you have the following Menu object with three items:
These objects (Panel1, WorkWithNovel, and WorkWithAuthor) check permissions independently, according to the settings of the Integrated Security Level property of each object.
If Integrated Security Level property = none, Authentication is not required to execute this object.
If Integrated Security Level property = Authentication, only authenticated users can execute the object. Authentication will be checked for the first time when executing the Menu; afterwards (when the session times out), Authentication is checked when this object is executed.
If Integrated Security Level property = Authorization, only authenticated and authorized users can execute the object. Authentication will be checked for the first time when executing the Menu; afterwards (when the session times out), Authentication is checked when this object is executed.
Any combination is valid.
If the three of them require Authorization, you need to define a Role where the corresponding permissions are defined, with the desired Permission Access Type.
If the user is not authorized to execute "WorkWithAuthor", the following error will be shown on screen: "Unauthorized: Access is denied.".
Otherwise, the execution can be redirected to the object specified in Not Authorized Object for SD property.
After configuring the permissions on the user's role, as the following figure shows:
User's role permissions for executing WorkWithAuthor
The user will be able to execute WorkWithAuthor:
Also, to execute the Detail and all its Sections:
Note that the _same permission_ allows the user to execute the Detail and all the sections inside the Detail (view Section General and Section Novels).
The actions in the WW panels (insert, update, delete) are directly related to the Business Component associated with the WW and not the WW itself. This means that, if you apply Work With Pattern to a Transaction ("Novels"), the "Novels" Transaction is automatically saved as Business Component exposed as REST Web Services. In order to control permissions over the actions insert, update, and delete, you need to declare permissions over the Business Component itself. See HowTo: Permissions in SD Applications, CRUD Restricted and HowTo: Permissions in SD Applications, WW and CRUD Restricted for details.
The permissions over the list and view of the item's list are managed in the WWSD object as shown in this paper.
GAM - Permissions
Full Control Permissions and inheritance
GAM Authorization Scenarios