= 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 ||

[=#point1 ''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| Monthly Process: EDIR Unit Changes Following BOR Structure Table 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 
* Seed Routing

== PEOPLE RECORDS ==
For people records, the initial state reflects a subcategory of people records 
* A : Records matched to Banner with active employee or student affiliation 
* E : Records matched to Banner for which active employee or student affiliation is expected but does not yet exist 
* S : 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 ===
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 the EDIR UI.  They are visible through iPlanet queries on IDMP-3.  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 ===
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 ===
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. 

=== Additional States ===
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. See [#point1 ''NOTE:''].

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).

=== X State Records ===
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 Record ===

** Example 1: Inactivating a record **
{{{
* 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
}}}
** Example 2: Flagging a bad record **
{{{
* Same as above for states N, A, through S, A
...
* 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
* 	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
}}}