Securing a menu item is not enough – form parts

Implementing the correct security is not only about granting access to menu items. You need to understand the full architecture and realize the menu item linked to a menu is only one option when Microsoft mentions user interface elements in their documentation about the security architecture. I will spend several blogs explaining more options that you need to consider to get the result required by the business. In this post, I will share knowledge about securing form parts.

Form parts

In my opinion, we have multiple types of form parts. It is about having a subform with information embedded in another form. The most obvious one from a development point of view is the form parts section on a form. Next to this one, there is an option to define tiles, mainly implemented on workspaces and there is an option to add a form part in a container control at any place of the form design.

During a security implementation, these form parts are mainly overlooked. It can be included automatically when you decide to reuse existing duties and privileges. Then still, from my experience, there are a lot of people not aware of it. When you will start creating privileges from scratch, you and the end user might overlook or not be aware of any missing form part. Let me start with an easy example: the Global address book page (Party). The next screenshot is taken with system administrator role access rights.

You can use the menu item name as presented in the URL or probably you are using the security diagnostics for task recordings to learn which menu item should be included in a privilege. For this form, I created a new privilege, duty, and role and assigned this role to a test user.

When you compare the two screenshots, you will notice several differences. First of all, the Party menu is not visible. If users would need functions like the duplicate check, create a new customer, or maintain registration IDs, you can add these menu items to your security configuration.

A second difference is that the Address books filter is not filled and the user does not have access. This is also related to permissions and configurations, but I would like to highlight another missing element. Did you notice the third difference yourself? At the right side of the page, there is a bar with Related information available on the first screenshot which is missing on the second one. When you open this bar, there are form parts with additional information related to the selected record.

The Primary address and Relationships are two form parts linked to the Global address book page. To know how to include them in your security design, we can have a short look at Visual Studio and the form design of the object DirPartyTable.

One element of the form tree control is intended to link the form parts. When you look at the properties, the contents is managed with a display menu item which will open a small subform on the current page. To provide access to the user, you would need to include the menu item present in the properties of the form parts. Using the Security configuration form or in Visual Studio you are able to add the menu item and grant permissions. If you don’t have access to Visual Studio to look up the form part menu item, there is a trick to get this information from the user interface. The security diagnostics for task recordings and the security configuration form will not help you retrieve the name of the menu item related to the form parts.

As a system administrator, you have the option to use get details using the feature Form information. If you right-click on the form part title, it will show information about the control. This includes the name of the control itself. The last part of the name is the name of the form part.

Usually, it would be the same technical name as the menu item name. Technically, the name gets updated by selecting the menu item name. I have not seen occasions where the name is updated thereafter, but this is possible. In about 95% of the cases, you can rely on the form part name equals the menu item name. If this is not the case, then you would need Visual Studio to get the correct menu item name.

If you are a developer and reading this part, then please consider maintaining these two properties to be the same to help persons set up security via the user interface.

Before moving to the next type of form parts, I would like to mention that if you use the security diagnostics available on the form, you will see standard security elements. The privilege Maintain party records (technical name: DirPartyTableMaintain) does contain the related form parts. For myself speaking, I would rather first attempt to reuse existing duties and privileges or create a copy of them and make changes compared to creating privileges for standard features from scratch. The reason is that standard privileges usually contain more permissions than just some menu items which are directly visible.

Form part container control

We just had a look at the list page for the global address book and solved the missing related information. Now even if you added the menu items to your custom privilege or if you added the standard privilege, there is some other information missing in the details.

Comparing this form with the view from a system administrator or another role with the correct permissions, you will notice that the address and contact information tabs are missing on this form. This is explainable due to the usage of form part controls for the grids on these tab pages. Let’s have another look at the form design in Visual Studio.

For both the addresses and contact information, form part controls are used where, like the parts discussed above, menu items are specified. In this case, there is no common way to find the menu items from the user interface and you would need a development environment to get more insights.

The reason for having form parts for the addresses and contact information is reusability. The same form object for addresses and contact information can be used on different forms, like customers, vendors, workers, and more. These forms have different menu items, opening the same subform, to be able to manage the security to address and contact information per entity. Interestingly enough, the legal entity form has no form part for the addresses and contact information. Instead, it is having the data source and grid for addresses on the same form. There is something about that as well, but that will be discussed in my next blog.

Once you know the menu items, you can add them to your custom privileges. Above, I mentioned that the standard privileges usually have all related menu items compiled together. The menu items for the addresses and contact information are not included in the privilege Maintain party records as mentioned above. Microsoft created separate privileges for access to the addresses and contact information. The standard duty for maintaining global address book party records does have these privileges included.

Workspaces

I thought to include some notes about workspaces in this post as it also contains form part controls and tiles. Let’s have a look at the user interface first. The workspace itself is a form that can be secured via a menu item, but without additional effort, the page might be quite empty.

Each tile on this form, each tab page with lists, and each menu item in the links can be individually secured. To know how to secure the elements, you have to look into the details in the development environment.

The summary section contains tiles. These tiles are objects in the application object tree (AOT). The tile has a reference to a menu item, which can be secured by adding them to privileges and granting permissions.

The tab pages with list controls are form part controls. As described above, these form-part controls do have the menu item linked in the properties.

Lastly, the links in the bottom section of the workspace are just a list of individual menu items. These are usually some menu items that are also accessible via the main menu. If you grant permissions, you would not only see them appearing on the workspace, but also as an option to choose from the menu.

There is more…

In this post, I highlighted that just granting access to a menu item part of the main menu is not enough. There are more related user interface elements that also need attention to have all information displayed correctly. In this blog, I mainly focussed on all form elements which require additional menu items to be part of your security customizations. In my next blog, I will elaborate more on form controls that can’t be controlled via menu item access.

I do hope you liked this post and will add value for you in your daily work as a professional. If you have related questions or feedback, don’t hesitate to use the Comment feature below.


That’s all for now. Till next time!

The post Securing a menu item is not enough – form parts appeared first on Dynamicspedia.