Enterprise Library has the concept of default and named validation rule sets. In our environment we have used these to apply validation depending on the role of the user saving the object (ex. Administrator or not).
Objects will have properties that are not viewable or updateable by certain users and therefore the values will be null/nothing. However, when the field is accessible to the user, the value is required.
I am wondering what mechanism in CSLA.NET, if any, allows for specifying the mode or set of rules that apply for a given scenario. Since the rules are added for the Class/Type rather than the instance, I know it is not done when adding rules. Since some rules may be object independent (ex. MinLength, Required, etc.), the rule itself should not be made dependent on the scenario.
I cannot see how I might do this other than creating a completely new class which is overkill if the difference is for just 1 or two fields.
There is no direct implementation of per-role rules. Interestingly enough, you are the first person to bring this up in 16 years. I'm going out on a limb to speculate that it isn't a super-common requirement :)
The good news is that you can use gateway rules to address the requirement. If you want a rule to execute or not based on the user's identity/roles you can create a gateway rule to do the role check and chain to the business rule only if appropriate.
I don't cover your specific scenario in the book, but the Using CSLA 4: Creating Business Objects book covers gateway rules, and I'm pretty sure the RuleTutorial sample has some gateway rule examples as well.
Yes, RuleTutorial sample show CanWrite, IsNew and IsNotNew gateway rules.
You can also use ShortCircuitingRules like StopIfNotCanWrite which also included in RuleTutorial.
The CanWrite / StopIfNotCanWrite checks the result of CanWriteProperty - whether this by default checks authorization or if you have an overload.
IE; These rules allow you to create rules that are only validated when user is allowed to edit the field.
StopIfNotCanWrite can also be used together with Data Annotation rules (that always have Priority=0) by setting Priority to -1 or lower.
I must also add that CSLA does support the concept of default and named rulesets.
These can be used for both authorization rules and business rules.
For Authz rules you must use ApplicationContext (as tuis is a static method)
ApplicationContext.RuleSet = ApplicationContext.DefaultRuleSet;
BusinessRules.AddRule(typeof(PermissionsRoot2), new IsInRole(AuthorizationActions.DeleteObject, "User"));
ApplicationContext.RuleSet = "custom1";
BusinessRules.AddRule(typeof(PermissionsRoot2), new IsInRole(AuthorizationActions.DeleteObject, "Admin"));
ApplicationContext.RuleSet = "custom2";
BusinessRules.AddRule(typeof(PermissionsRoot2), new IsInRole(AuthorizationActions.DeleteObject, "User", "Admin"));
For business rules:
BusinessRules.RuleSet = ApplicationContext.DefaultRuleSet;
BusinessRules.AddRule(new Csla.Rules.CommonRules.IsInRole(Rules.AuthorizationActions.ReadProperty, FirstNameProperty, new List<string> { "Admin" }));
BusinessRules.AddRule(new Csla.Rules.CommonRules.IsInRole(Rules.AuthorizationActions.WriteProperty, FirstNameProperty, new List<string> { "Admin" }));
BusinessRules.AddRule(new Csla.Rules.CommonRules.IsInRole(Rules.AuthorizationActions.ExecuteMethod, DoWorkMethod, new List<string> { "Admin" }));
BusinessRules.RuleSet = "custom1";
BusinessRules.AddRule(new Csla.Rules.CommonRules.IsInRole(Rules.AuthorizationActions.ReadProperty, FirstNameProperty, new List<string> { "Admin, User" }));
BusinessRules.AddRule(new Csla.Rules.CommonRules.IsInRole(Rules.AuthorizationActions.WriteProperty, FirstNameProperty, new List<string> { "Admin" }));
BusinessRules.AddRule(new Csla.Rules.CommonRules.IsInRole(Rules.AuthorizationActions.ExecuteMethod, DoWorkMethod, new List<string> { "Admin" }));
Johny, thank you for replying. Thank you for pointing out ruleset functionality. This is more like what developers here are familiar with, though the syntax here is a bit verbose. Hopefully we can cut it down with some namespace imports.
Now I just have to figure out how, if at all, this will tie in with dynamicdata fields in asp.net.
OK.. Looks like I have to pick up the books as a refresher then. Truthfully, I've been avoiding it because I either like printed or kindle formats. PDF on the kindle or computer is a pain to read over a long period, though I love PDFs as references after I've read through a whole book.
Copyright (c) Marimer LLC