I have bound a business object to a ComponentOne grid through an instance of the BusinessBindingSource object.  When I attached security keys to some of the business object's fields, it didn't seem to have any affect on the grid - users who do not have access to a field will be able to see it on the grid.  Does field level security not work with the BusinessBindingSource object or am I doing something wrong?  Thanks for your help.

Fran Parker

MaxQ Technologies, Inc.

These security fields will not be respected by the grid as far as showing up.  Now if you use the replace with character then you will see the replacement character rather than the actual value.

Thanks for the quick reply.  I must be doing something wrong.  I used the Security Editor to create a permission with a denied action of "Replace Each Character".  I then assigned that permission to a field of a grid bound business object and also to a field of a non-grid bound business object.  My program includes the following two lines:

SecurityBasics.DefaultBlockedMsg = "Access Denied.";

SecurityBasics.BlockedReplacementCharacter = '*';

When a user without the permission in question loads a record into the screen, the text box bound to the non-grid object's field will be filled with "Access Denied.".  However, the grid column bound to the field in question shows the field's data.  Any idea what I might have missed?  Thanks again.

Fran

This logic is done within the BO and the property.  I recommend binding the field to a regulary SF text box until you get the results you are looking for so you know that the BBS is not in the formula.

I was already using "Replace Each Character".  I did as you suggested, however, and created a new project using the "StrataFrame Windows Application with Security" template.  I then dropped text boxes bound to both of my business objects onto Form1.  When a user without the required permission runs the test screen, the boxes bound to the fields in question both contain "Access Denied." rather than the replacement character.  Any thoughts?  Thanks.

Fran.

The second thing you can check is the CheckFieldSecurity event on the business object.  When you handle the event on the form, you the event args will contain the values that are going to be used to block/replace the message.  Check those 2 things and let me know.

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.

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.

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.

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.

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

Fran.