...
| Code Block |
|---|
//add a rule on stem:a saying if you are out of stem:b, then remove from stem:a
AttributeAssign attributeAssign = groupA
.getAttributeDelegate().assignAttribute(RuleUtils.ruleAttributeDefName()).getAttributeAssign();
attributeAssign.getAttributeValueDelegate().assignValue(
RuleUtils.ruleActAsSubjectSourceIdName(), "g:isa");
attributeAssign.getAttributeValueDelegate().assignValue(
RuleUtils.ruleActAsSubjectIdName(), "GrouperSystem");
attributeAssign.getAttributeValueDelegate().assignValue(
RuleUtils.ruleCheckOwnerNameName(), "stem:b");
attributeAssign.getAttributeValueDelegate().assignValue(
RuleUtils.ruleCheckTypeName(),
RuleCheckType.membershipRemove.name());
attributeAssign.getAttributeValueDelegate().assignValue(
RuleUtils.ruleIfConditionEnumName(),
RuleConditionEnum.thisGroupHasImmediateMember.name());
attributeAssign.getAttributeValueDelegate().assignValue(
RuleUtils.ruleThenElName(),
"${ruleUtils.removeMember(thisGroupId, memberId}");
|
sadf
Daemon component
If the rule is not scripted, then we have the opportunity to run it in daemon mode at the time the rule was added or changed, or periodically (nightly/weekly) to reduce data corruptions. Some rules might not want this to happen (e.g. on group create set permissions, if you do this nightly then you cant remove permissions)
Error handling
If the rule execution fails for some reason, it should be logged (which could include emailing administrators), but it probably should not affect the transaction of the operation that triggered the rule. Maybe this can be a setting on a per rule basis and where applicable (e.g. if it is a flattened membership rule trigger, then there is no transaction since the rule fires post commit anyways.
...
There are certain validation constraints to make a rule valid. i.e. you need some check, you need some then, you need an act as subject, etc. So each time you change a rule attribute value, all the attributes are validated, and the attribute "ruleValid" is managed by that hook. If the rule attributes are not valid, you will get a ruleValid value of something like: "INVALID: Rule check type required", if they are valid, then the value will be "T". Only rules with a value of T will be processed. The attribute stores this state so the rules dont have to be validated each time they are read from the DB, and so the user can get some feedback.
TODO: a daemon should validate rules daily, and ones which arent valid should be logged (notified)
TODO: when processing all rules, filter out ones which arent valid
Logging
You can turn debug logging on to see information about rules which fire. log4j.properties
...