Changes between Initial Version and Version 1 of ALL__record_lifecyle

Timestamp:

11/19/14 17:15:09 (10 years ago)

Author:

lttoth@…

Comment:

--

ALL__record_lifecyle

@@ +1 @@
+= Enterprise Directory Record Lifecycle (LDAP_REG.STATE) =
+    Original author:  Beth Mercer - 20090108
+
+This document introduces the concept of record lifecycle as implemented in the Enterprise 
+Directory (EDIR) through its batch processes.  Records receive an initial state when first 
+created after which state may be changed.  Possible states are recorded in LDAP_REG_STATES 
+and vary by record type (see the query report_state_counts) as well as by stage of 
+processing.  As of 20080107, possible states are these:
+
+||= STATE =||= DESCRIPTION =||
+|| A ||        PEOPLE ENTITIES - ACTIVE RECORDS ||
+|| B ||    PEOPLE ENTITIES - BAD RECORDS ||
+|| b ||     PEOPLE ENTITIES - FLAGGED FOR BAD PROCESSING ||
+|| D ||     DEPARTMENT ENTITIES - ACTIVE RECORDS ||
+|| E ||    PEOPLE ENTITIES - EXPECTED RECORDS ||
+|| G ||     GROUP ENTITIES - ACTIVE RECORDS ||
+|| I  ||   PEOPLE ENTITIES - INACTIVE RECORDS ||
+|| i  ||    PEOPLE ENTITIES - FLAGGED FOR INACTIVE PROCESSING ||
+|| N ||    PEOPLE ENTITIES - FLAGGED FOR DIRECTORY RECORD CREATION ||
+|| O ||     ROUTING ENTITIES - ACTIVE RECORDS ||
+|| P ||    ALL ENTITIES - PURGED RECORDS ||
+|| p ||   PEOPLE ENTITIES - FLAGGED FOR PURGE PROCESSING ||
+|| R ||    RESOURCE ENTITIES - ACTIVE RECORDS ||
+|| S ||     PEOPLE ENTITIES - SPONSORED RECORDS ||
+|| X ||     FLAGGED FOR EXCLUSION FROM BATCH PROCESSING ||
+
+''NOTE: ''With one exception, transitional states are lowercase.  The state N, though 
+uppercase, is a transitional state establish early in the evolution of lifecyle processing.
+If someone had the time to change the dependent code, changing N to n would be desirable.
+
+People records have the most complex lifecycle, as reflected by number of possible states, 
+because peoples' relationships with the University are the most changeable.  Automated batch 
+processes have evolved to address that complexity and rely on the various possible states 
+for people records.  More about them later is in this document.
+
+DEPARTMENT, GROUP, RESOURCE and ROUTING RECORDS
+===============================================
+When department, group, resource and routing records are first created, they are given a state 
+reflecting the type of record.  The only other supported (by batch processing) state is P for 
+purged.  
+
+STATE DESCRIPTION
+----- ------------------------------------------------------------
+D     DEPARTMENT ENTITIES - ACTIVE RECORDS
+G     GROUP ENTITIES - ACTIVE RECORDS
+R     RESOURCE ENTITIES - ACTIVE RECORDS
+O     ROUTING ENTITIES - ACTIVE RECORDS
+P     ALL ENTITIES - PURGED RECORDS
+
+So, a group record is given a state of G when created.  That state is changed to P when purged.  
+The initial state of G is reestablished if a previously purged record is restored.  The same holds 
+true for department, resource and routing records.
+
+D | G | R | O   when department, group, resource and routing records created
+P               when purged
+D | G | R | O   if purged record subsequently restored
+
+Department records are created via two processes: a monthly batch update process driven by 
+changes to OIR's BOR table (see UPDT_unit_changes) and the EDIR Seed Department form.  Department 
+records are deleted and restored by the same processes with certain restrictions.  The EDIR Seed 
+Department form will only delete and restore "faux" records - those created via the form.  The Seed 
+Department form will not delete those department records originating from the BOR table.
+
+Group, resource and routing records are all created, deleted and restored via the corresponding 
+AUTHSERV or EDIR forms (Seed Group, Seed Resource and Seed Routing)
+
+PEOPLE RECORDS
+==============
+For people records, the initial state reflects a subcategory of people records (A for records matched 
+to Banner with active employee or student affiliation, E for records matched to Banner for which 
+active employee or student affiliation is expected but does not yet exist, S for records with no 
+match in Banner [generally thought of as "guest accounts"]).
+
+STATE DESCRIPTION
+----- ------------------------------------------------------------
+A     PEOPLE ENTITIES - ACTIVE RECORDS
+E     PEOPLE ENTITIES - EXPECTED RECORDS
+S     PEOPLE ENTITIES - SPONSORED RECORDS
+
+Aside from signifying a subcatetory of people records, state on people records is also used for 
+batch process control.  
+
+A state records are subject to record aging and will be flagged for inactivation by the EDIR 
+Banner Extract process when the record no longer meets the active affiliation test.  Inactivated 
+records are present but hidden in EDIR.  The EDIR Banner extract process is the primary source 
+of people records with an initial state of A.  However, the AUTHSERV Sponsor Account form can 
+also restore previously purged records.  Those restored records have an initial state of A and 
+will be inactivated due to lack of active affiliation unless subsequently sponsored.
+
+E state records are exempt from inactivation processing.  Their state is changed from E to A by 
+the EDIR Banner Extract process once the record meets the normal extract criteria.  A now obsoleted 
+AUTHSERV form was the only source of people records with an initial state of E.  The current AUTHSERV 
+Sponsor Account form is now used to sponsor regular accounts as well as guest accounts making the 
+E state obsolete.  
+
+NOTE: As of 1/8/2009, there were still 10 EDIR records with a state of E.
+
+S state records are also exempt from inactivation processing.  State changes from S to A only when 
+sponsorship is revoked.  The AUTHSERV Sponsor Account form is the only source of people records 
+with an initial state of S. 
+
+There are additional LDAP_REG values that reflect alternate and transitional states for people 
+records.
+
+STATE DESCRIPTION
+----- ------------------------------------------------------------
+I     PEOPLE ENTITIES - INACTIVE RECORDS
+B     PEOPLE ENTITIES - BAD RECORDS
+P     ALL ENTITIES - PURGED RECORDS
+N     PEOPLE ENTITIES - FLAGGED FOR DIRECTORY RECORD CREATION
+i     PEOPLE ENTITIES - FLAGGED FOR INACTIVE PROCESSING
+b     PEOPLE ENTITIES - FLAGGED FOR BAD PROCESSING
+p     PEOPLE ENTITIES - FLAGGED FOR PURGE PROCESSING
+
+One step in the EDIR Banner Extract process flags people records with the transitional states of N 
+(new), i (inactive) or b (bad).  A final step generates directory LDIF based on the transitional 
+states and then changes the state to A (active), I (inactive) or B (bad) accordingly.  
+
+NOTE: The fact that the N state is upper case rather than lowercase is an unfortunate by-product of 
+how lifecycle processing developed for EDIR.
+
+The process of purging the directory of inactive and bad people records (see UPDT_process_purge) 
+has not been run since 2007.  When the purge is performed, LDAP_REG is changed to the transitional 
+state of p (purge), directory LDIF is generated and then state is changed to P (purged).
+
+There is one special people record state not previously mentioned - X (exclude).
+
+STATE DESCRIPTION
+----- ------------------------------------------------------------
+X     FLAGGED FOR EXCLUSION FROM BATCH PROCESSING
+
+The state X, which is a kludge that addressed a security/privacy issue that cropped up for one 
+user's record,  must be established and removed manually.  Records with a state of X are excluded 
+from processing by the EDIR Banner Extract.  If state is X, the EDIR Banner Extract process neither 
+updates the registry with Banner data nor changes the record state.
+
+NOTE: As of 1/8/2009, there was only 1 EDIR records with a state of X.
+
+WARNING: Place no reliance on state X without first investigating how it is currently used.
+
+SAMPLE PEOPLE RECORD STATE FLOWS:
+
+<<regular people records>>
+N       when EDIR Banner Extract process identifies a qualifying entity which no directory record exists
+          NOTE: this could be a previously purged record
+A       once the EDIR Banner Extract process (or AUTHSERV Sponsor Account form) generates the directory record
+i       when the EDIR Banner Extract process flags the record for inactivation
+I       after the EDIR Banner Extract process inactivates the record
+p       when the record is flagged for purging
+P       after the record has been purged
+A       when the AUTHSERV Sponsor Account form restores the purged record
+S       when record is sponsored by AUTHSERV Sponsor Account form
+A       when sponsorship is revoked
+i       when the EDIR Banner Extract process flags the record for inactivation
+I       after the EDIR Banner Extract process inactivates the record
+p       when the record is flagged for purging
+P       after the record has been purged
+
+N       when EDIR Banner Extract process identifies a qualifying entity which no directory record exists
+A       once the EDIR Banner Extract process (or AUTHSERV Sponsor Account form) generates the directory record
+...
+b       when EDIR Banner Extract process flags record as "bad" (as result of Banner multiple PIDM cleanup)
+B       after the EDIR Banner Extract process inactivates the "bad" record
+p       when the record is flagged for purging
+P       after the record has been purged
+
+<<guest records>>
+S       when record is sponsored by AUTHSERV Sponsor Account form
+A       when sponsorship is revoked
+i       when the EDIR Banner Extract process flags the record for inactivation
+I       after the EDIR Banner Extract process inactivates the record
+p       when the record is flagged for purging
+P       after the record has been purged
+A       when the AUTHSERV Sponsor Account form restores the purged record
+S       when record is sponsored by AUTHSERV Sponsor Account form
+A       when sponsorship is revoked
+i       when the EDIR Banner Extract process flags the record for inactivation
+I       after the EDIR Banner Extract process inactivates the record
+p       when the record is flagged for purging
+P       after the record has been purged
+
+