PropertyStatus DenyRead

Brette.Net posted on Tuesday, June 09, 2009

Quick question and bare with me as I am new to the PropertyStatus object. It seems however, that when the PropertyStatus object encounters a property that one does not have read access to, it assigns (in my case) the value of the text box bound to the property to string.empty. This is well and good but it results in the setter being called in my business object making the current instance dirty and to add insult to injury it breaks a rule triggering the the control to validate via IDataErrorInfo.

Has anyone found a solution to this?

Thanks,
B

RockfordLhotka replied on Wednesday, June 10, 2009

Is this WPF or Silverlight?

I have not seen this behavior, can you provide a simple example illustrating the problem?

Brette.Net replied on Thursday, June 11, 2009

Sure.

<Label Grid.Row="0"
                   Grid.Column="0">Customer Name</Label>
                <TextBox
                Name="NameTextBox"
                     MinWidth="267"
                     MaxLength="40"
                     Text="{Binding Path=BusinessObject.Name, Mode=TwoWay, ValidatesOnDataErrors=True, UpdateSourceTrigger=PropertyChanged}">
                </TextBox>
                <Controls:PropertyStatus Source="{Binding Path=BusinessObject}" Property="Name"
                               Target="{Binding ElementName=NameTextBox}" />

Add a auth rule

AllowRead(NameProperty, "Admin") and log in with a user who does not have the admin role.

The PropertyStatus calls the set_Text method on the text box, this triggers databinding to update the source. In my opinion you should only be calling set_Content not set_Text.

Let me know if you need any more info.

RockfordLhotka replied on Thursday, June 11, 2009

Ahh, I think I see.

It didn’t occur to me that someone would deny read to a user, but allow them to write to the property.

So you have a scenario where the user isn’t allowed to read, but is allowed to write?

Rocky

Brette.Net replied on Friday, June 12, 2009

Rocky,

You are correct in that it is not a valid scenario for us to have a field that can be written but not read. However our security model is configurable through a Admin tool we build. So it is possible through configuration to create this scenario, (though it would probally be a mistake). In any case I just changed your code so it fits what we need.

Thanks,

Brette