Page History

...

Example usages:

• Provision any identifier to a target without having to "resolve the subject"
• Make a JEXL scripted group: People who have a payroll data row where org is "MATH" and have an affiliation data row where affiliation name is Staff or Faculty with an End date in the next month.  Put a rule on that group for the Business Analyst to review people who might need to be renewed.
• Load users from Zoom and match accounts to users in Grouper by email address
• A staff member creates a report where a column is if the user in the service is an Employee
• A help desk worker can the history of affiliations and troubleshoots access by seeing that the user's payroll org recently changed

Setup data fields

• Each has unique name (cant have same name as data field row)
• Is identifier?
• If is identifier, is it searchable without data field scope?
  • i.e. can you just search by netId and get a result (yes).  or can you search by zoom user id and get a result without telling the search that the value is a zoom user id (no)
• Is access related?

  • Three types of data fields

    • Informational
      • e.g. name, description, email, etc
      • Needed for provisioning or UI or WS
    • Access related
      • e.g. dept, title, school, DN
      • Needed for loading groups, jexl scripted groups, provisioning events
    • Group - based
      • A group could be the basis of a data field
      • Imagine eduPersonAffiliation-like reference groups that drive flags on a user or a multi-valued set of affiliations: e.g. student, member, alumni
      • Security would be based on the security of the group
      • Makes exposing some access information over UI/WS/provisioning easier
      • The subsequent settings would not apply e.g. since PIT is already there
      • If this feature is implemented, the guidance would be to keep low the number of groups that feedback into data fields
• Stored locally?
• Stored in PIT?
  • If data is not huge volume and doesnt change frequently then yes
  • Policies could be based on history of attributes
  • NetId changes would be easier to deal with
• PIT retention in days
  • If stored in PIT, how many days should be stored.  Default to 5 years.  Blank means store forever
• Which group can see it (if none its public)
• Multi-valued?
• Calculated?
  • If the value needs to be translated from other data field in a script (e.g. description)
• Dynamic? (can be selected only if calculated)
  • If a script is needed to evaluate the field, and it depends on env or current user (GrouperSesssion), then it is dynamic.  e.g. name is institutional_name if the user can see anything there, or public name if not
• From_sole_source: select the source if populated from one source only

...