When using ObjectAuthorizationRules the CanAddNewItem doesn’t appear to get updated but when using AuthorizationRules then property CanAddNewItem does get updated and allows the controls to go read-only etc. So the question is how do I get the ObjectAuthorizationRules to work like the AuthorizationRules or is this not possible?
I am using CSLA 3.7.0.0 for Silverlight and Silverlight 3 with the language C#
I don't understand what you are asking.
The CslaDataProvider has a CanAddNewItem property. This property's value is derived based on the per-type authorization rules for the child object type contained within a list.
Per-type authorization rules are added to a business object type in the static AddObjectAuthorizationRules() method. Your code in that method calls static methods on the Csla.Security.AuthorizationRules class to associate roles with the business object type.
To clarify:
I have some object level authorisation rule applied in my business classes: e.g.
partial class meta_ServiceProviderList
{
[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]
public static void AddObjectAuthorizationRules()
{
Csla.Security.AuthorizationRules.AllowEdit(typeof(meta_ServiceProviderList), "EditMetaData", "Admin");
Csla.Security.AuthorizationRules.AllowCreate(typeof(meta_ServiceProviderList), "EditMetaData", "Admin");
Csla.Security.AuthorizationRules.AllowDelete(typeof(meta_ServiceProviderList), "EditMetaData", "Admin");
}
}
On a Silverlight page displaying the data for an unauthorized user I would have expected that all of the fields would automatically become read-only (as the whole object is read-only, and the page uses the CSLA PropertyStatus control) but they aren’t. i.e. I was expecting each of the properties “CanEditItem” to be set to false if the user is not authorised to edit the business object as a whole. Similarly I was expecting the “add” button to be disabled.
I have implemented a workaround on the Silverlight page, by putting all of my properties in a “ContentControl” and binding the IsEnabled to the business Object’s “CanCreateObject” and “CanEditObject” respectively.
Is this by design? – I was expecting object level authorisation to cascade down to the properties.
This is by design - the per-property and per-type rules are essentially independent from each other. Per-type rules are enforced by the data portal and/or your code. Per-property rules are enforced by each business object instance at the property level (and potentially by your code).
In a XAML UI, the PropertyStatus control is typically used to expose the CanRead/CanWrite values on a per-property basis, and your UI controls can bind to a PropertyStatus control to enable/disable based on the permissions for a specific property.
If you want to bind your UI to a per-type rule that's fine too - you can bind to properties on CslaDataProvider or your viewmodel.
You should be aware that the data provider model is essentially obsolete. Microsoft doesn't appear to be going in that direction anymore, and CslaDataProvider exists now only for backward compatibility.
Copyright (c) Marimer LLC