I'm addressing a case where BypassPropertyChecks may be the solution,
but in more general terms. The case involves business processing and
authorizations that the user may not otherwise have. In this case,
SalesQuote objects are transformed by user action into SalesContract
objects. However, there are some properties on SalesContract that the
user cannot specifically edit, but whose values must be transferred from
SalesQuote. The simple solution is to add the appropriate
authorizations to CanWriteProperty to to allow the transformation to
complete, but many of my UI elements are enabled based on
CanWriteProperty (indeed, that's what the ReadWriteAuthorization control
does). Given all of this, it seems that we're actually asking two
different questions:
1) Can the user write to the property at all?
2) Can the user edit the property directly?
The difference seems to be business rules in two different contexts:
1) core business
2) the UI
At
first glance, I considered leveraging BypassPropertyChecks, but my fear
is that authorization rules cannot be accurately queried while it is
active. It's as if the business process would have to pre-authorize
before executing the process, in which case the process would have to
have intimate knowledge what internal rules to check first.
I'm building a WinForms app, but not using any presentation
patterns. Were I using such a pattern that had bindable controller
classes, I'd consider allowing the property write in the business
object, but deny the property write in the UI controller. I've seen
Rocky's training video on building with CSLA/MVVM and in it he chooses
to expose the business object(s) for the sake of binding (or at least to
avoid the tedium of writing a view model that delegates back and forth
with the business object), so I'm unsure of what I'd actually do.
I believe in the CSLA principle of keeping the business rules close to the data, but this situation is quite a challenge.
Any thoughts on implementing authorization in business process vs. the UI?
In general terms BypassPropertyChecks is designed for use in DataPortal_XYZ or object factory methods.
There's a protected SuppressRuleChecking property on BusinessRules (ValidationRules in older versions) that is intended for batch loading of property values without having rules run. In CSLA 4 there's also an interface on BusinessBase specifically to enable UI frameworks to suppress, resume and run all rules for an object.
This interface was added to help support ASP.NET MVC, which does block mode loads of data on postback. It is also helpful for Web Forms or service implementations. I can't imagine it would be very useful for any smart client scenario, where interactivity is desirable.
One thing to keep firmly in mind is that authorization is business logic. It is not security, it is logic. Sure, there's a little overlap with security, but people can be allowed/denied read and write authorization based on many factors, including security, state of the object, state of specific properties, state of the overall application, etc.
CSLA 4 has much broader support for creating custom authz rules, specifically to help scenarios where property read/write capabilities need to be more sophisticated.
Thanks for the reply, Rocky.
Yes, the authorization I'm referring to is indeed business logic (e.g.
"Only Contract Managers can edit property SalesContract.PropX."). The
problem is that Sales Reps can transform SalesQuotes, which also have
property PropX, into SalesContracts, and it is the business rule above
that is blocking the transform.
What I've done is implement a BypassAuthorizationChecks mechanism in the
spirit of the BypassPropertyChecks pattern in 3.6. I'm using v2.1.4 right
now, so I'm unable to leverage any CSLA goodness created in the last few
years. :-( My workaround seems to rather hack-ish, but at least it was
created with the CSLA framework in mind.
I would suggest that there is another object you might need, which does the actual tranformation. In this object, Sales Reps could modify the property, whereas they just wouldn't be able to on the SalesQuote. Transformating a quote to Contract is probably a diffent use case than just editing a SaleQuote, correct?
Copyright (c) Marimer LLC