Before we start, we have to decide which model the security elements will go into. The consideration is that security is often configured by a consultant or someone in the organization responsible for maintaining security. The reason this is relevant is that the changes made in the client persist the changes back to the AOT, and therefore have to be deployed in the same way as our code is deployed.
Therefore, we often create a model specifically for security changes. In this way, they can be deployed separately in our code. Designing security is often an iterative process, and often there are many updates made during and after implementation.
We would create the security design in the same model as the main development if it is a vertical add-on. The end user organization will make changes in a specific model in their layer so as to not interfere with their other developments.
There is no specific rule for creating privileges, but we should ensure we provide enough granularity to enable the required duties to be created. We should also consider that privileges might be added to other duties by the security administrator.
The following is an example structure that would be appropriate, based on our menu items and required duties:
|
Privilege |
Menu item |
Access level |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The parts have Update access, as the data is read-only and the form parts may have controls that require the user to complete, such as the vehicle utilization part.
To create this structure, follow these steps:
- In our project, create a new privilege named
ConFMSVehicleViewby navigating to Security | Privileges. - Set the Label property to
View vehicle information. The label will appear to the user configuring security in the client. - Enter a longer description for the privilege as required. This also appears when configuring security in the client.
- Drag the required menu items (as listed in the preceding table) onto the Entry Points node and set the AccessLevel appropriately.
Repeat this for each privilege.
A user with the ConFMSVehicleView privilege will have the following available in the Fleet management system menu:
- Vehicles
- Active vehicles
- Inactive with appointment
The Setup menu and forms related to service data are not visible. Furthermore, the action bar on the Vehicles list page will look like this:
The buttons for the vehicle status, vehicle group change, and service details have been taken away, which is expected because the privilege did not have these as entry points.
However, the buttons for New, Edit, and Edit in grid are also not visible. The reason is that these menu items have the OpenMode property set to higher than View. The Delete button appears, but it is disabled. This is because it is a CommandButton, and so it is automatically disabled because the user only has Read access.
Without the Edit button the user has no obvious way to open the details form, unless they remember that they can double-click on the vehicle record on the grid. The template form we created this form from does have a View button, which is triggered by the double-click event, but this is hidden by default. To solve this issue, we can change the button's Visible property to Yes. On the details form, the following is shown:
The buttons for Edit, Delete, and New are CommandButtons and will therefore not be hidden from the user. The interesting part here is that the Edit button is not disabled. It still triggers the form event, but even so, the user will not be able to edit records. This is not ideal, and the action bar would be much cleaner if the buttons didn't display at all.
To hide these buttons, we have two options: adjusting the form control or adding the form control to the privilege.
There is a reason that there are two options. Adding the control to the privilege avoids modifying standard forms (or any that are in a layer lower than our own). But if we are the authors of the form, adjusting the form is by far the better option, as we will see.
To add a control to the privilege, follow these steps:
- Drag the form onto the Permissions | Forms node of the privilege.
- Right-click on the new node and choose New Control.
- In the Control property, type the name of the control
- Select the appropriate value for the
EffectiveAccessproperty. To hide the control, make itNoAccess.
Since we are the authors of the forms, we will not do it in this way. Instead, we will achieve the same result by adjusting the form controls. Since we understand that, for example, the edit buttons require an access level of update, we can simply tell control it requires this permission. Each form control has a NeededPermission property. This functions as a minimum requirement for the control to be displayed to the user.
We should modify our forms, setting the NeededPermission property on the buttons not linked to a menu item, as follows:
|
Edit button |
|
|
Delete button |
|
|
New button |
|
After this change is made to the ConFMSVehicleTable form, the action pane then looks like what is shown in the following screen shot:
This is much cleaner, and only gives the options that the role requires.
By setting the AccessLevel on the entry point, we also determine the maximum access level for the data sources in the form that the menu item opens. By maximum access, we mean that the AccessLevel can't be used to override the AllowEdit property of the data source or table.
On occasion, we may need to override this, and we have a requirement for the ConFMSVehicleEdit privilege: we don't want the user to be able to edit the status or group fields.
To do this, we add the table and the applicable fields to the privilege, as follows:
- Drag the
ConFMSVehicleTabletable to the | Tables node (found under Permissions) of theConFMSVehicleEditprivilege. - EffectiveAccess will default to
Read; we should change this toUpdate. The permission should be able to edit vehicle data, and this would override the AccessLevel on theConFMSVehicleTableEntry point. - Right-click on the new node and select New Field.
- Change Field to
VehicleStatusId. - Change EffectiveAccess to
Read. You will see that the maximum access isUpdate. This is because we set the table'sEffectiveAccesstoUpdate. - Repeat this for
VehicleGroupId.
We also need to create a privilege so that a service can be invoked by external applications. Currently only the system administrator role can execute services in our ConFMSVehicleServices class, such as the updateVehicleGroup method.
The privilege we need is created as follows:
- Create a new privilege named
ConFMSVehicleServicesby navigating to Security | Privileges. - The label should be clear that this is providing access to service methods and not the service data, for example,
Access to vehicle service methods. - Add description to describe what this will do.
- Create a new entry point under the privilege's Entry points node named
VehicleServiceUpdateVehicleGroup, and open the property sheet. - Set ObjectType to
ServiceOperation. - Select
updateVehicleGroupin ObjectChildName; this lists the appropriate server methods. - Change AccessLevel to
Invoke.