This is an example of an EL condition on memberships which is an advanced use case. Only admins can set these up.
Setup EL in rules
in grouper.properties
Key: rules.accessToApiInEl.group
Value: Some group name, e.g. etc:rulesAccessToApiInEl
Add GrouperSystem to that group
Attribute definition
(note attribute is immediate memberships. if you want "any membership", the query needs to change slightly:
Attribute name
Rule
| Attr | Value | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ruleActAsSubjectId | GrouperSystem | |||||||||
| ruleActAsSubjectSourceId | g:isa | |||||||||
| ruleCheckType | membershipRemove | |||||||||
| ruleIfConditionEl | (adjust attribute name test:testAttr) ${ "1" == new("edu.internet2.middleware.grouperClient.jdbc.GcDbAccess").sql("select value_string from grouper_aval_asn_mship_v gaamv where attribute_def_name_name = 'test:testAttr' and membership_id = ?").addBindVar(membership.getImmediateMembershipId()).select(''.class.forName('java.lang.String')) }
Notes
| |||||||||
| ruleThenEnum | veto | |||||||||
| ruleThenEnumArg0 | mySchoolVetoIfAttributeThere (some random externalized text key you can ignore) | |||||||||
| ruleThenEnumArg1 | This membership cannot be removed since attr is there with val 1 (what is shown on screen, see below for caveats) |
Note that the way rules are implemented with membership deletes, the rule is fired in the transaction after the membership (and attributes) are deleted. So if we do a query like this which will not use the same transaction (as opposed to a hibernate call which uses the same transaction), then we get the desired result. The hibernate call which does not work correctly is:
When you multi-select memberships (or bulk remove via import), you get a generic error
When you revoke a single membership from the drop down, you see the veto error
