Instance Auth rules - not known when AddInstanceAuthorizationRules is called?

ajj3085 posted on Wednesday, April 04, 2007

Hi,

I have a case where I want some instance authorization rules on a child object that change based on the parent object. That is, if this child object is being used by an Invoice object, only Inviocing should be able to modify it. If its part of an order, only Sales should be able to modify it.

I though about having the parent pass the roles allowed to modify it when it creates the child object, but AddInstanceRules fires before the child's constructor does.

This actually has to flow down to the grandchildren as well..

Any ideas how to acomplish this task?

Thanks
Andy

William replied on Wednesday, April 04, 2007

Hi Andy,

To my understanding, AddInstanceRules is meant to setup the rules. Then, the rules are only evaluated when ValidationRules.CheckRules() is invoked, typically in DataPortal_Create. In this case, you instantiate the child objects in DataPortal_Create and pass along the parent instance (i.e., this). Then, then child would be able to determine who is the parent, and typically, check for the type of the parent in authrorization method's implementation. For example,

if (_parent != null && _parent.GetType() == typeof(Invoice))

return true; // Authorized

Hope this helps.

Regards,

William

ajj3085 replied on Thursday, April 05, 2007

Well, we're talking about Auth rules, so it gets evaluated when CanReadProperty or CanWriteProperty are called. That's the problem I'm having; its not the evaluation of the rules that I'm stuck on, its how I can get the proper rules added.

The child doesn't know what roles to allow when AddInstanceAuthorizationRules gets called..

William replied on Thursday, April 05, 2007

I would think the same pattern can be applied.

When you instantiate child objects, you pass along the parent object. This way, when the authorization rules on child objects run, they will have enough information about who is the parent (Sales, Invoice, etc.).

Regards,
William

ajj3085 replied on Friday, April 06, 2007

The problem is that the base constructor runs before the subclass constructor, so I cannot set the Parent before AddInstanceAuthorizationRules runs.

I can add some methods to add the rules after the constructor is run, but I'm concerned its not the 'proper' way to acomplish this as its outside what you'd normally do in Csla.

ajj3085 replied on Friday, April 06, 2007

Oh I should add that these child objects are NOT contained in a collection; they are directly contained by a non-BLB root object.

emathias replied on Friday, April 06, 2007

I'm still not real clear on when to use instance rules versus the class-based rules? Can anyone point me to a resource on this?

Justin replied on Friday, April 06, 2007

Correct me if I am wrong but isn't this very similar to what was posted here: http://forums.lhotka.net/forums/thread/6670.aspx and I think your response there would also work with your own problem, and seems to be the CSLA way which is subclass this common object into InvoiceChild and OrderChild with slightly different behaivors?

Otherwise it would involve overriding SetParent to add the rules or as you said a new method to be called afterchild construction.

Would be interesting to know how you work it out.

Justin

ajj3085 replied on Friday, April 06, 2007

Hey Justin,

The problem is indeed similar, and I have though of subclassing, but that would lead to four additional classes, each simply overriding AddInstanceAuthorizationRules with different hardcoded values.

Also, I'm not sure its different behavior; only certain roles may change the values on the instance, the only difference is which roles may change a particular instance.

This is not much different than loading the roles allowed to edit from the database in AddInstanceAuthorizationRules ; my problem here is getting the data to the instance in time for appropriate method to fire.

I think I will go the subclass method for now though, unless someone can propose a better solution.

ajj3085 replied on Monday, April 09, 2007

I'm going to go the subclass route, as that seems to be the cleanest way to acomplish this within the framework.