Search:

How To Create a New Role Using Role Builder

Overview: This walkthrough shows how to use the Role Builder in Easy Security to create a new Role. Permission to objects can be added manually using object ranges. Inserting object ranges to add many objects on one line is faster than adding the objects one at a time on separate lines. This example shows creating a SUPER role for the Relationship Management feature RM SUPER. You can use this same principle to create any new role using the Role Builder by replacing the example data in the screenshots with your own information.

1) Open the Roles window and create a New Role Card. Enter a Role ID and a Name for the new Role. Click on Role Builder Permissions to open the Edit Role Builder Permissions window.



2) Select the Object Type you wish to add permissions for. In the Object ID field, select or enter the number of the object you wish to start with. In the To Object ID field, select or enter the number of the object you wish to end with. If you know the object numbers you can type the numbers instead of doing a lookup. Notice that when the TableData Object ID is entered, the permissions field changes to the default TableData permission of Read.



NOTE: Even though the last TableData number currently used in the Relationship Management feature is 5311, the TableData number of 5399 was entered in the To Object ID field. Since the numbers up to and including 5399 are reserved for use in the Relationship Management feature, 5399 was entered in the To Object ID field. This Role will already include any objects that are created in the future for the Relationship Management feature.

3) In this example a Super RM user is being created, so lines are added for all object types. Notice that the permissions field changes to Execute. This is the default permission for Table, Form, Report, Codeunit and Page. Also once again, the full range of potential object numbers is used on all object types. This is done so the Role will have permission to newly created objects in the future.



4) The Role Builder has features that make it easy to add additional permissions to a Role. To use these features, you must first set the Origin field to Recorded, as shown in the screenshot below. Then depending on the type of permissions you want added, enter checkmarks in one or more of the following fields: Extend Insert Permission, Add Related Permissions, Role for Both Clients, Do not include Additional.



NOTE: If permissions are not given to a Role according to the fields that are checked in the Edit Role Builder Permissions window, please check Security Setup. The Role Builder options are controlled on the Role Builder tab in Security Setup. Please make sure the appropriate field(s) is checked in setup that corresponds to the field(s) that is checked in the Role Builder Permissions window. For example, let us say the Extend Insert Permissions field is checked in the Role Builder Permissions window. However the Role was given only the Modify permission instead of both the Delete and Modify permissions. This can be caused by the Extend Insert to Delete field NOT being checked in Security Setup.

Click the following link for more information on the fields in Security Setup: Definition of Fields on the Security Setup Window

The fields have the following effect on the Role permissions:

a) Extend Insert Permissions: If Insert Permissions has been given for TableData, then checking this field causes the Delete and Modify permissions to also be added for TableData. It is usually normal for a user with permission to insert data into a table to also be able to change or delete the data. This field is valid only for the TableData object type.

b) Add Related Permissions: The feature uses information gathered by the Source Analyzer. The Source Analyzer identifies relationships among all the tables. When this field is checked, the Source Analyzer then adds READ permission to all TableData that is required for TableRelations and FlowFields among the tables that were added to the Role. This makes the creating of Roles much easier since all of the lookups do not need to be used and the FlowFields do not all have to be calculated in order to have the necessary permissions to do so. The adding of the additional objects is handled by Easy Security. Easy Security uses the information gathered by the Source Analyzer to determine the objects that need to be added. The Origin field must be set to Recorded for this feature to work.

Click the following link and scroll to the Source Code Analyzer section for additional information on the Source Code Analyzer:

Easy Security: The Technical Side

c) Role for Both Clients: When this field is checked, both Form and Page permissions will be added to the Role regardless of which client the Role was created in. This means that if the Role was created in the Classic Client where Forms are used, the Role will also work in the RTC where Pages are used and vice versa. This field is valid only for Page and Form object types.

d) Do not include Additional: When this field is checked, no additional permissions will be added.

5) Each line shows a summary of the permissions (RIMDE) for each Object Type added. This makes it easy to review the permissions. Click OK to close the Edit Role Builder Permissions window and return to the Roles window.

6) Click Update Role to update the permissions to the new Super RM Role. Receive a message showing the number of role permissions that were added to the new Role.



7) Click OK to close the message window and the number of permissions that were added will appear. As can be seen, 12 Role Builder Permissions were added and 642 Role Permissions were added to the RM-SUPER Role. Of the 642 permissions, 176 of the permissions are for TableData.



8) Click on the Role Permissions number to open the View Role Permissions window. Scroll through the information in this window. When the Origin field displays Recorded, this means the permissions were added based on information provided in the Role Builder Permission window. When Additional is displayed in the Origin field, this means the permissions were added based on information from the Source Code Analyzer data.

As displayed in the screenshot below, you can see that permissions for TableData 5401, 5404, etc. were added based on the information from the Source Code Analyzer since the Origin field displays Additional. This feature makes the setting up of security much easier since the person setting up security does not need to know all the other objects that a Role may need access to. The Source Code Analyzer takes care of that.




Like   Don't Like

© 2024 Mergetool.com. All rights reserved.



Related resources

Download software from Mergetool.com