View Source

Expiration Policies allow for automatic transition of CO Person (Role) attributes in support of offboarding procedures, such as grace periods and expiration.

Each Expiration Policy consists of two components: Conditions and Actions. When the Conditions for an Expiration Policy all match, all Actions for that Expiration Policy are taken. Multiple Expiration Policies can be defined.

Conditions

The following conditions are currently supported:

COU: The Expiration Policy will only apply to the specified COU. If no COU is specified, the Expiration Policy applies to the entire CO.
Affiliation: The Expiration Policy will only apply to CO Person Roles with the specified affiliation. If no affiliation is specified, the Expiration Policy applies to all CO Person Roles.
Days Before Expiration: The Expiration Policy will apply the specified number of days before the Valid Through date of a CO Person Role. For example, if a CO Person Role has a valid through date of June 30, and Days Before Expiration is set to 3, then the Expiration Policy will be considered in effect beginning June 27. When used in conjunction with a Notification action and nightly automated processing, this will generate nightly expiration warnings for 3 nights prior to expiration. (To have an Expiration Policy apply only once when using this condition, set an Action that will change the Affiliation, COU, or Status so that the Expiration Policy no longer matches. Or use Max Execution Count.)
Days After Expiration: The Expiration Policy will apply the specified number of days after the Valid Through date of a CO Person Role. For example, if a CO Person Role has a valid through date of July 1, and Days After Expiration is set to 7, then the Expiration Policy will be considered in effect beginning July 8. When used in conjunction with a Status action and nightly automated processing, this will implement a week long grace period (but see more, below).
Max Execution Count: The Expiration Policy will apply no more than the specified number of times. The count will reset when expiration related CO Person Role attributes (eg: status, valid through, affiliation, COU, sponsor) are changed. Available since Registry v1.1.0.
Status: The Expiration Policy will only apply to CO Person Roles with the specified status. If no status is specified, the Expiration Policy applies to all CO Person Roles.
Invalid Sponsor: If set, the Expiration Policy will apply to CO Person Roles attached to a sponsor (CO Person) that is no longer in Active status.

Only one of Days Before Expiration and Days After Expiration may be set in a given Expiration Policy.

In order to have an expiration policy apply on the exact day of expiration, set Days After Expiration to 0. (Do not use Days Before Expiration for this.)

Note that 0 and blank are treated differently. A blank Days value will be treated as unset, and not used for matching records.

Versions prior to Registry v2.0.0 may not have handled these settings as described here.

Actions

The following actions are supported:

Updating these CO Person Role attributes, for the matched CO Person Roles: COU, Affiliation, and Status.
Clearing Expiration. This will clear the Valid Through date for the CO Person Roles that matched.
Notifying the CO Administrators, COU Administrators, members of a specific CO Group, Sponsor (as of Registry v2.0.0), or the CO Person whose CO Person Role matched.
- See also: Notification Message Substitutions

When a CO Person Role status is updated, the overall CO Person status will be recalculated.

Automatic Processing

In order for Expiration Policies to be processed automatically for a CO, the following conditions must be met:

The Registry cron job has been installed.
1. As of Registry v4.0.0, expirations are processed via the Core Job Plugin Expire job.
Expiration is not disabled. To disable expiration, edit the CO Settings (Collaborations >> CO >> CO Settings) and check Disable Expiration.
Only Expiration Policies with status Active will be executed.

Common Expiration Patterns

Grace Periods

The recommended way to implement Grace Periods is with two Expiration Policies.

The first Expiration Policy would have Conditions appropriate for the start of the Grace Period. This would generally involve Days Before Expiration being blank and Status being Active, with optional filters for COU and Affiliation. The key Action would be to set Status to Grace Period.

The second Expiration Policy would have Status of Grace Period as the key Condition (thus effectively chaining to the first Expiration Policy), along with Days After Expiration set to the number of days in the Grace Period. The Actions would then be set appropriately, such as setting Status to Expired.