Hi Edhy,



Please find answers below:-







Each form has a permission as does each tab. The groups don't have permissions but will be hidden if all of the tools within the group are hidden. Even though the tabs have permissions, the tabs will also be automatically hidden if all groups are hidden. The only reason I added a permission to each Tab was to give a quick and easy way of turning off the complete tab without having to individually turn off each tool - which could have been a big task if you use popup menu tools with many nested layers. Having a tab permission means I can turn it off with a single click.







Yes, I build the ribbon as normal at design time and all ToolItems are added to the correct tabs and groups. The only extra step at this stage is I use the tool.SharedProps.Tag property to store the form name that will be launched when a user clicks the tool. I have a small general purpose routine which simply checks the tag and calls the form rather than having a separate click method for each tool/form.



The Tag property is also used during the security check to determine if the tool is visible. I use a strict naming convention for form permissions:- "Is" + FormName + "Enabled". For example, a form called "Customer" would have a permission called "IsCustomerEnabled". A ToolItem which launches the customer form will have a Tag of "Customer" so this gives me both the form name and also allows me to work out the correct permission to check. I also have a special value for the Tag property if I don't want a security check for a specific tool and that is "NoSecurityCheck".



I wanted to have the option of having several tools which load the same form which is why I use the Tag property rather than assuming the ToolItem will be called the same name as the form.







The ToolItems have already been loaded into the correct tabs and groups at designtime. I have a routine called CheckMenuRibbonSecurity which runs once during initialization and removes tools which are denied based on permissions. This method does the following:-



1. It checks the Tag property of all tools in the ultraToolbarsManager.Tools collection. If the tag is "NoSecurityCheck" then the tool is allowed to remain visible. If the tag contains a form name then I check the "Is" + FormName + "Enabled" permission. If disallowed, then the tool is hidden.



2. Hidden tools still appear in the Application Menu and Groups in a disabled state so they must still be removed. The routine scans through all tools in the ultraToolbarsManager.Ribbon.ApplicationMenu.ToolAreaLeft.Tools collection. Hidden controls are then removed by calling the ultraToolbarsManager.Ribbon.ApplicationMenu.ToolAreaLeft.Tools.Remove() method. Please note it is vital to scan through the tool collection from last to first to avoid the Remove command from confusing your scan, i.e. if you have 10 tools then check and remove the 10th before moving to the 9th and so on.



3. Each tab is checked. If it's permission is denied then the whole tab is hidden simply by setting the visible property. If the tab is allowed, then the routine will scan through all groups within the ultraToolbarsManager1.Ribbon.Tabs.Groups collection. For each group, the group's Tools collection is scanned and any hidden tools are removed using the same technique as in point 2. If all tools are removed from a group, then the group is removed using Remove(). If there are no groups within a tab because they have all been removed, then the tab is hidden. Again, it is vital to scan through the group and tool collections in reverse order. If not, then you will get some weird results



Please note that one side-effect of using the security system is an "Administrator" sees all tool items as an administrator always passes security checks.



In effect, I am simply setting up the ribbon at designtime and removing denied tools at runtime. Allowed tools don't require any additional action as they are already on the ribbon in a visible state.



Please let me know if you have any other questions.



Aaron

Hi Aaron,



Thanks a lot for the detail explanation. I will follow your lead and use the RBS with this tool, it does make a lot of sense and I like the idea of having one single point to hide/show the tool items via the RBS.

Edhy Rijo

Hi Aaron. Sounds like exactly waht I am looking for. When I sais I did not want to use a 3rd party control, I meant a non SF control

At this point, I want to concentrate on SF first and maybe afterwards I will look at other 3rd party controls

Is the functionality you descibe 'in the box' (regarding Rights for different users/groups) or does it require a fair amount of plumbing ?

Gerard,

Yes this is handle by the SF-RBS of course you need to create your form's permission and assign their Keys to the form's ViewSecurityKey. Read about how to setup the RBS and also there is a good white paper on how to setup security here http://forum.strataframe.net/Topic14216-26-1.aspx.

Basically with Aaron's detailed approach I was able to use the RBS to enable/disable menu items in a very short period of time.

Also you need to check each item permission using code like this:

If SecurityBasics.CurrentUser.GetPermission(customViewSecurityKey).Action <> PermissionAction.Grant Then

     Return False

End If

Edhy Rijo

Hi Aaron,

One more question about the "NoSecurityCheck" feature, you mention that you use this "NoSecurityCheck" instead of the form's name to skip the security and load the menu item, but in that case, the ShareProps.Tag will be "NoSecurityCheck", then how will you know what form's or command to execute?



Before your posting, I was using the Tool.Key to store my form name like "frmInventory", but based on your explanation, I also have the need to open the same form from different tools and the Key must be unique for each item, so I am adopting your logic which at the end simplifies the whole process, specially adding new menu items.

Edhy Rijo

Hi Edhy,



I have a small handful of special tools (File Exit, Security Editor, Database Connection, Upgrade Database) and for these I use the tool.Key to separate them from my "normal" SF forms. My tool click method first checks the key and if it is one of the above then they are handled separately. For the "File Exit" tool I set the Tag to "NoSecurityCheck" as I want everyone to see it. If the key isn't one of the above then it is a regular form and the Tag contains both the form name and effectively the permission.



You mentioned in a post to Gerard the need to set the form's ViewSecurityKey. In theory it doesn't have to be set. If a form is denied then the tools will be removed and there is no way for the form to be run by the user. SF checks the ViewSecurityKey when the form is run so if you are removing the tool the form can only be run whenever permission has been granted.



Regards,



Aaron

Ok, I got it now. Thanks!





Yes you are right on this, you may get away from setting the ViewSecurityKey, in my case I already have those setup and it may be used as a insurance that the form will be protected in case something is missed. During my test using your approach it was really useful to had the ViewSecurityKey since I call the Security Editor form from another place and the key prevented the form from showing up.

Edhy Rijo