Making an Editable Root Read-Only

David posted on Thursday, September 06, 2007

I have an Editable Root object (an Invoice) that becomes Read-Only when its Status property is set to Finalised. What is the best way to enforce this?

RikGarner replied on Thursday, September 06, 2007

We do this by overriding the CanWriteProperty method in the object; internally we have a permissionResolver object that knows what state the object is in and whether the user has permission to alter the object.

public override bool CanWriteProperty(string propertyName)

{

   return _permissionResolver.Permission == PermissionLevel.Write;

}

 

sgraham replied on Tuesday, February 05, 2008

Would you be willing to shed some light on your implementation of the permissionResolver?  I have a few different states for my object and I'm wondering how best to model such an implementation.

How does it get info/data about the business object?

Thanks,

Sean

JonnyBee replied on Wednesday, February 06, 2008

You may also use the ReadWriteAuthorization control  in Csla to set ReadOnly/Enabled/Visible on UI components based on the CanWriteProperty / CanReadProperty.

Jonny

sgraham replied on Wednesday, February 06, 2008

I am already using the ReadWriteAuthorization control to control the UI components.  What I'm trying to do is have the CanWriteProperty use a helper class (like permissionResolve) to determine the state of the object and it's children (based on object variables like dates, status, etc.) and return the correct value (true or false) based on that state.  So, I'm interested in understanding how to implement such a class per my questions above.

ajj3085 replied on Wednesday, February 06, 2008

If you have a private field in the root bo that determines if can be changed, you can check that in a CanWriteProperty override.

public override CanWriteProperty( string propertyName ) {
   if ( isLocked ) {
       return false;
   }

    return base.CanWriteProperty( propertyName );
}

sgraham replied on Wednesday, February 06, 2008

I do have some private fields in the root of the bo.  So, that would work.  However, I also need to implement this override in the children and grand-children (dependent on the same parent properties).  And, although I understand there are topics on sharing data down to children and grandchildren, I know it's typically not a good idea because it causes tight coupling.  That's why the thought of a helper class like permsissionResolver intrigues me.  However, I'm not sure how I would go about implementing that class.  Maybe that class isn't as "robust" as I initially thought (maybe it doesn't handle a situation like mine).  Maybe my situation can't be solved without sharing data down to children and grandchildren (in which case I should use interfaces maybe)?  I've been using CSLA for a year or so now but I'm still not real keen on "advanced" OO techniques such as this so any help/guidance would be greatly appreciated!

SomeGuy replied on Wednesday, February 06, 2008

Assuming that you know that Status is Finalized at load time, couldn't you set a flag on the Child Objects as you fetch them to make them read only.

E

 

RikGarner replied on Wednesday, February 06, 2008

I don't think my PermissionResolver addresses your problem. When I originally wrote that post I was using a PermissionResolver which contained a bunch of common functions and then subclassing it for state management of different types, e.g. DocumentPermissionResolver. These subclassed objects would know how to adapt to changes in state of their 'host object' by setting properties on it when things changed - PropertyHasChanged is useful here.

As the design and code progressed this began to get really complicated and, in the end, it was easier to just use the PermissionResolver to work out the allowed access level based on external information (a permission table, whether a user was assigned to a team etc) and manage the access based on the state of the instance as internal variables as ajj3085 suggests.

In practice the state management stuff was less complicated than it felt it was going to be when we started.