Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

Actors

  1. User
  2. OpenRegistry
  3. Database

Pre-Conditions

  1. PRE1: User has authenticated with system
  2. PRE2: User has chosen SoR to work with
  3. PRE3: User has chosen SoR Person to add role to
  4. PRE4: User has authorization to add role to person
  5. PRE5: Defined list of appropriate roles
  6. PRE6: Either consistent rules on validation, or a pre-configured validation of rules
  7. PRE7: Data Standardization and Normalization Rules are defined
  8. PRE8: Required Fields / Role Information is defined for an SoR in an Interface Specification on top of the standard required fields.

Flow

  1. User chooses role/affiliation that they wish to add to person. MUST BE FROM APPROVED LIST: PRE5.
  2. Based on the role/affiliation chosen, the user will have to enter some of the information below:
    • Status
    • Sponsor & Sponsor Type
    • Start Date
    • Percent Time
    • Role ID for the SOR (not required, but recommended for any SOR that can provide it. MUST be generated otherwise)
  3. Based on the negotiated Interface Specification (PRE8), there may be additional requirements such as (but not limited to)
    • At least one email address supplied
    • Termination Date/Reason is required and can't be further than 6 months out.
  4. Supplied information is validated.
  5. Supplied information is normalized and standardized per PRE7.
  6. Supplied information is persisted for SoR
  7. Calculated Person is re-calculated (reconciliation of roles?).
  8. Business Rules are Executed
  9. If a new Role ID was created, passed back to user.

Post Conditions

  • Downstream systems should be notified of the new role and attributes created for this person.

Business Rules

  • Required Fields are dependent on meta data defining validation rules. They may be per deployment, or SoR.
  • Start Date MUST be before End Date.

Exceptions

  • EX1: Any errors should stop flow, including authorization, database, etc.
  • EX2: If any rule calculation fails, the flow should fail.
  • No labels