...
Allow common reference groups to have user friendly labels
Code Block e.g. employee instead of ref:employee
- Do not allow plurals of labels, and absorb plurals. e.g. "member of employee" same as "member of employees
- Same for case differences
- Absorb smart quotes
- Give a warning (validation) and suggestion when parens are needed
- alow group friendly names, uuid, idIndex, case issues, etc to be used but converted into the id-path
- Document common allowed reference groups and syntax on the script editing page
- Allow natural language to be converted into JEXL
e.g.
Code Block FROM Member of employee, and member of app:jiraAdminsManualTO ${entity.memberOf(‘ref:employee’) && entity.memberOf(‘app:jiraAdminsManual’)}e.g.
Code Block FROM Has affiliation attribute with name of staff and dept of english, but not a member of lockout TO entity.hasAttribute('affiliation', 'name==staff && dept==english') && entity.notMemberOf('ref:lockout')
- Load groups as members
- Add incremental job
- Unit tests
- Better validation
- More methods to call (other than hasMember)
- Add subject attributes e.g. from global attribute resolver
- Failsafes
- Add delegated admin based on READ of groups
- Visualization
- Add more counts of total memberships etc
- See if comments can be included in scripts
- See if we can replace composite type with immediate in membership table if replacing a composite with jexl script
- Have a confirm screen that tells the user information about what will happen (tie into visualization)? (have a progress page)
- Add UI to configure scripts?
- Test button while writing to see if valid (maybe that does counts too)
- Add dependency graph for precedence or recalcs in full sync
- Do not allow circular references
- Identify full syncs to be hourly or daily
- Allow single quotes or double quotes when parsing scripts
Entity
...
This is for a future release
The high level strategy is you need two database tables, a table of people and a table of one-to-many records about those people. This will be configured in your global entity attribute resolver. abac jexl scripted groups would be able to use those similar to this
| Code Block |
|---|
my_people_table
employee_id (same as subject id or identifier) email
123 a@b.c
234 b@c.d
my_people_affiliation
employee_id affiliation_name dept
123 staff english
123 student history
234 guest chemistry
${ entity.attributeRecordFilter('myPeople', 'affiliation', "(affiliation_name == 'staff' || affiliation_name == 'student') && dept == 'english'") } |
The first argument "myPeople" identifies the entity resolver
The second argument "affiliation" identifies a one-to-many relationship on the main entity resolver table which is another table
The third argument is a filter on that one-to-many table for those people
This means find people where the affiliation has a name of staff or student and that affiliation is in dept english. The format of the filter would not be a well defined subset of jexl... thoughts? 
Note: this is a little weird since there is a JEXL script embedded in the JEXL script... but we can document it and see how it goes?
Entity resolver change log or last updated col could be used on incremental
...
data fields
Setup your entity data fields and use that data in JEXL scripts. This data can come from LDAP or SQL
Gail Lift: Michigan is starting to see situations where this approach would be REALLY useful. We are also interested in near real time / changelog.
We have struggled to build widely usable reference groups, because each unit has their own special needs: "Regular staff, but only in these jobcodes" and "Regular staff, but only in those jobcodes". Because a person can have multiple jobs, or multiple student programs, simple group math is not enough. If Mary has 2 jobs, {"dept":"English","jobcode":"12345"} and {"dept":"History","jobcode":"67890"}, intersecting a dept ref group with a jobcode ref group will not work as desired.
We are hoping the the new approach with Entity Attribute Resolver Groups will help with these needs. But we are concerned about how to get all the needed data into the my_people_affiliation table. (you could feed from arbitrary LDAP/SQL/WS sources)
We have affiliation data for employees, emeritus, Ann Arbor students, Dearborn students, Flint students, alumni, and Sponsored Affiliates (guests). Class enrollment data will be added later. Each affiliations has its own set of attributes that need to be available for group construction. A couple of typical samples, seen as we store them in LDAP in an almost-JSON format:
umichAAAcadProgram: {acadCareer=GBA}:{acadProg=00018}:{acadPlan=0010MAC}:{campus=A}:{progStatus=AC}:{admitTerm=2410}:{admitTermBegDt=2022-08-29}:{expGradTerm=}:{degrChkoutStat=}:{acadCareerDescr=Graduate Business Admin}:{acadPlanDegree=MAC}:{acadPlanDescr=Accounting MAcc}:{acadPlanField=0010}:{acadPlanFieldDescr=}:{acadPlanType=MAJ}:{acadPlanTypeDescr=Major}:{acadGroup=BA}:{acadGroupDescr=Ross School of Business}:{acadProgDescr=Accounting MAcc}
umichHR: {jobCategory=Faculty}:{campus=UM_ANN-ARBOR}:{deptId=304000}:{deptGroup=MEDICAL_SCHOOL}:{deptDescription=MM Orthopaedic Surgery}:{deptGroupDescription=Medical School}:{deptVPArea=EXEC_VP_MED_AFF}:{jobcode=201000}:{jobFamily=10}:{emplStatus=A}:{regTemp=R}:{supervisorId=12345678}:{tenureStatus=TEN}:{jobIndicator=P}For a single my_people_affiliation table, having a column for each distinct keyword would require about 70 columns. In any given row, most columns would have a null value. At the other extreme, we could use a single column for the affiliation data, so the columns would be employee_id, affiliation_name, affiliation_value. At this extreme, most queries would require substring matching. Would a structure between these make sense? Is a separate table for each affiliation better? (Dont worry about a table with all data)
Parse expression with JEXL (for Grouper developers)
...