Page History

...

• ifCondition: this might not be needed if the check contains all the information about when the rule should fire.  You can configure a premade check (enum) or a scriptlet or EL (Expression language).  e.g.

  Code Block
  ${!RulesUtils.hasMember(groupName, subjectSourceId, subjectId)}

  
  

• then: this is a premade (enum) or scriptlet (EL: expression language).  e.g. thenType is removeMember and groupName is a:b, or a scriptlet:

  Code Block
  ${RulesUtils.removeMember(groupName, subjectSourceId, subjectId}

  
  

...

The check component will see if the rule should continue to the "if condition".  The check part is an enum class: edu.internet2.middleware.grouper.rules.RuleCheckType

Look at the javadoc or source for the most recent check types, currently they are:

...

grouperSession = GrouperSession.startRootSession();
stem = StemFinder.findByName(grouperSession, "test:testRules");
RuleApi.inheritGroupPrivileges(SubjectFinder.findRootSubject(), stem, Stem.Scope.SUB, SubjectFinder.findRootSubject(), Privilege.getInstances("admin"));
RuleApi.rulesToString(stem);
stem.getAttributeDelegate().removeAttributeByAssignId("af0aa3601b5149a08b71d7d82ea6a906");

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.

...