Vibrant discussion about CSLA .NET and using the framework to build great business applications.
Hi All,
I've encountered a strange behavioural issue with the ReadWriteAuthorization extender on a single WinForm. The WinForm contains a TabControl with a series of TextBox and ComboBox controls. We've add the ReadWriteAuthorization extender and set each TextBox and ComboBox control's ApplyAuthorization on ReadWriteAuthorization property to true.
When we log in with a user account having the GetObject permission but not Edit/Delete/Create permissions on all other forms the controls are disabled. On this one Form they are still enabled.
Is there something I am missing? We are using CSLA 4.1.0 in VS2010.
Phlar
ReadWriteAuthorization only check CanReadProperty / CanWriteProperty methods in the BO.
Get/Edit/Delete/Create permissions is not checked by CanReadProperty / CanWriteProperty.
CanReadProperty => AuthorizationActions.ReadPropertyCanWriteProperty => AuthorizationActions.WriteProperty
Jonny Bekkum, Norway CslaContrib Coordinator
Hi JonnyBee,
Sorry I should have also indicated the series of WriteProperty details as well. For example on a Property BO we have the following for Authorization Rules:
BusinessRules.AddRule(new IsInRole(AuthorizationActions.WriteProperty, CityProperty, "Address-Edit"));
The user login details we are using does not have the "Address-Edit" role.
On the UI we have inserted a TabControl with a TextBox Control. We've set the DataBindings Text Property to our BO - City property. We have also set the ApplyAuthorization on ReadWriteAuthoriztion property to true. The ApplyAuthorizationRules() method determines if the user has EditObject permissions (in this case no) and then Rebinds(false, true). Finally it calls the ResetControlAuthorizaiton method on the ReadWriteAuthorization extender.
We have utilized this in two dozen other forms/controls without any issue. However for some reason this one particular control is not properly disabling the controls. I had thought it was another issue as with DataGrids but that does not seem to be the case.
Any suggestions?
I have noticed a few times that the codebehind for ReadWriteAuthorization has become corrupted in <form>.Designer.cs. Possibly connected to copy / paste of controls in the form (but not sure) where the RWA control is owned by another container control than form.
You can also check this in the Document Outline window of the Form. RWA control assumes it is owned by the form and will "hook" into the controls of the parent container only (and thus will only know that containers child controls).The Windows Forms Designer will not acknowledge this and still allow the RWA control to (seemingly) extend all controls on the form.
So my first suggestion is to:
Unfortunately I have not had any luck with your first suggestion. Is there anything else I could attempt (short of constructing a new Form and adding new controls to that form)?
Hmm,
Well you could check in the Document Outline window on where the RWA is placed within the sequence of controls and the owner container in the Form and compare to Forms where the RWA is working OK to see if there is differences and try to correct them.
You should also verify that the RWA is created like this:
this.readWriteAuthorization1 = new Csla.Windows.ReadWriteAuthorization(this.components);
I think I have also seen a couple of times that the default constructor (without parameters) is called without this.components.
If these suggestions don'tsolve the issues then the only options I can suggest is to either debug the RWA control or try to make a new Form.
Well the Document Outline window outlined the RWA in the same location across all our Forms. However, after much debugging and line by line review of the BO I did discover the error so I thought I would share the details with anyone else who may come across the problem.
All of our property level business rules (Write/Read Property) are located in protected AddAuthorizationRules() method. I understand that this method is no longer utilized in the new CSLA but this project has been migrated from CSLA 3.X. For consistency we have left this convention in place. What was missing was the call to this method in the overridden AddBusinessRules method.
Unfortunately I had already begun reconstructing the Form to determine if it was due to a designer or other issue.