All I want to do is simply make something invisible...a navigation group on a DevExpress Navigation Bar Control.  Here is my attempt after setting up roles and permissions, then DDT to deploy:

if (SecurityBasics.CurrentUser.GetPermission("SystemMaintenance").Action == PermissionAction.Grant)
{
    AdminNavBarGroup.Visible = true;
}
else
{
    AdminNavBarGroup.Visible = false;
}

I have a role called "Administration".  A permission key was created for a category called Administration (not technically related).  The key is use above and it is called "SystemMaintenance".  The key is given grant rights for the "Administration" role.  I removed myself from that role to test.  The only thing that may be gumming up the works is the fact that my profile is marked as an administrator.  Does the administrator bypass any and all permission sets?

What would be nice is SecurityBasics.CurrentUser.IsInRole("Administration").  It would simply return a boolean value.  It look like I have to create a dictionary list then walk the list to see if the user is in the role or not.  Is that right?

Thanks for your help,
Bill

The code you posted should enable the AdminNavBarGroup when the user has Grant action for the SystemMaintenance permission. If it isn't then something else is going on. The first thing I'd do is put a break point on the if statement and make sure I know who the user is and if they have that permission, using the watch window. The next thing I'd do is make sure that the AdminNavBarGroup.Visible property is set correctly. This will tell you if you do in fact have the user setup correctly, e.g. a user without the SystemMaintenance permission set to something other than Grant. If your user is setup such that they don't have that permission assigned at all, then check out the InitApplication shared application event handler in AppMain (or whatever the C# equivalent is) and make sure that the SecurityBasics.DefaultPermissionInfo and DefaultPermissionAction are set to Deny. This is used when a user doesn't have the permission explicitly defined.



If the permission is fine and the visible is getting set correctly, then the next step is to figure out what else might be messing with the Visible property. Some other code that is putting back to visible.



These ideas come to mind because...well...I've done them before.

Thanks a bunch, Greg!  I'll work through these debugging tips tomorrow afternoon when I get back to the office.  Talk to you then!

Bill

Good answers, Greg.

The Action on DefaultPermissionInfo is Read-Only.  I cannot set that in the InitApplication method of program.cs.  Do you have syntax handy to show me how to set this?

Thanks!
Bill

Set it on the SecurityBasics shared property:

Yup.  That seems to work.  I am getting ready to test the change, now.  Should know something soon.

Well, if I do this:

SecurityBasics.DefaultPermissionInfo = new PermissionInfo(PermissionAction.Grant);

Then, I have to specifically deny people access to everything they should not have access to (the taking-away-the-keys-to-the-kingdom approach).  I see more why Greg suggested deny as the default (the don't-let-them-have-the-keys-at-all approach).  This will take a bit of time to setup.  I see why you suggest waiting until the end of the development process; however, I may have been better served to consider some of this stuff up-front.  

Thanks for your help, gents!
Bill 

You got it...this is the same approach that we take and we have good roles and data setup so that our customers can implement their desired security permissions easily.  But it is definitely best NOT to grant by default.

Any time Bill. It takes a while to really understand RBS, as it is pretty complex/full featured. It rocks though!