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

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.

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 

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

Set it on the SecurityBasics shared property:

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

Good answers, Greg.

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

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.

Nope.  The code failed.  The non-admin user was still able to access the group.  Not good.  How do I simply check if a user is in a specific role or not?  Maybe that is the better question.  I really don't see that in the docs.

Thanks,
Bill