Trent,

I did as you suggested and found that the deny action was Message in both circumstances.  With a little further experimenting, I found that this value would always be whatever the default denied action was.  So, I can get my test screen, the one without a grid, to behave the way I want if I setup the default permission info as follows:

SecurityBasics.DefaultPermissionInfo = new PermissionInfo(PermissionAction.Deny,"Access Denied.", DeniedActions.ReplaceEachCharacter);

A related thing I noticed by running SQL Profiler is that my screen doesn't make any attempt to find out what the denied action should be for a permission that I don't have.  After logging in, the screen executes the following SQL statement which returns only the list of permissions that I have been assigned:

exec sp_executesql N'SELECT * FROM [dbo].[SFSUserPermissionInfo] WHERE us_pk = @us_pk ORDER BY pm_pk',N'@us_pk int',@us_pk=1

Anything permission that I haven't been assigned just uses the DefaultPermissionInfo.  For what its worth, my test user is not a memeber of any roles.

Anyway, getting back to my grid screen, changing the default denied action didn't have any affect on the grid.  Also, I noticed that the CheckFieldSecurity event never gets fired for the business object bound to the grid.

Thanks for your help.

Fran.

 

Ah, yes, when you don't explicitly set a permission on a user, the DefaultPermissionInfo is used for that permission.

I will add an enhancement request to retrieve the DeniedAction from the database when a user is denied by default rather than explicitly denied.

As for the CheckFieldSecurity event, you have to set the CheckFieldSecurity property on the business object so that the event will be raised.  Otherwise, the event never gets raised for you to handle it.  Sorry I left that out earlier.

Ben,

Thanks for the info.  Now I understand why I wasn't getting the denied action I expected.

Unfortunately, however, I'm still having trouble with my grid screen.  I changed the CheckSecurityOnFields property of my object to Always (it had been set to WhenPermissionKeySet) and still the CheckFieldSecurity event is not being fired.  On my non-grid test screen, the event does get fired.  So, it seems as though having the object bound to the grid is preventing the event from being raised.  Any thoughts?  Thanks for your help.

Fran.

Any thoughts on my grid problem?  Thanks.

Fran.

For what it's worth, I added a standard DataGridView control to my test screen (to remove ComponentOne from the loop) and that didn't help.  So, it seems as though field level security is not enforced when a BusinessBindingSource object is used.  Can you guys confirm this?  Thanks.

Fran.

Fran,

The BBS at the moment is not respecting the security fields as it relates to binding to a grid and having the same native functionality as bound to any other type of control.  This is due to the nature of the IBindindList interface and how it interacts with the grid.  This is going to take some time to work through and as soon as we have a solution we will let you know.  Sorry for any trouble.

Trent,

No trouble - I just wanted to make sure that I wasn't doing something wrong.  Thanks for the update!

Fran.