...
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.
Allow users to be able to assign rules
This is a normal attribute framework NG concept. The user needs to be able to assign attributes to the owner object. e.g. for a group, the user needs ADMIN access on the group. Then the user needs UPDATE/READ on the attributeDefs (there are two). Also note, the user needs privileges in the actAs. Maybe add to an actAs group, if acting as the user itself, might need access to READ another group where the rule is fired from, etc.
| Code Block |
|---|
stem2.grantPriv(SubjectTestHelper.SUBJ9, NamingPrivilege.CREATE, false);
stem2.grantPriv(SubjectTestHelper.SUBJ9, NamingPrivilege.STEM, false);
RuleUtils.ruleTypeAttributeDef().getPrivilegeDelegate().grantPriv(SubjectTestHelper.SUBJ9, AttributeDefPrivilege.ATTR_UPDATE, false);
RuleUtils.ruleAttrAttributeDef().getPrivilegeDelegate().grantPriv(SubjectTestHelper.SUBJ9, AttributeDefPrivilege.ATTR_UPDATE, false);
RuleUtils.ruleTypeAttributeDef().getPrivilegeDelegate().grantPriv(SubjectTestHelper.SUBJ9, AttributeDefPrivilege.ATTR_READ, false);
RuleUtils.ruleAttrAttributeDef().getPrivilegeDelegate().grantPriv(SubjectTestHelper.SUBJ9, AttributeDefPrivilege.ATTR_READ, false);
|
Logging
You can turn debug logging on to see information about rules which fire. log4j.properties
...