COmanage Developers List

[Scott Koranda <>]

> A CO Enrollment Flow has multiple CO Enrollment Attributes attached
> to it, ie: the attributes that are defined to be collected as part
> of the flow. For example, saying 'Office Telephone' is to be
> collected. The way these are collected is via Petitions.
> 
> A CO Petition is created when a Flow is executed. CO Petitions have
> CO Petition Attributes, which are defined by linking them to CO
> Enrollment Attributes in the CO Enrollment Flow being executed. So
> when an enrollee's 'Office Telephone' is collected, it is stored in
> a CO Petition Attribute linked to the CO Enrollment Attribute while
> the Flow is executing.
> 
> Eventually, the Flow completes, and the CO Petition Attributes are
> copied to the appropriate tables (eg: co_telephone_numbers).
> 
> The question is... what happens if a CO Enrollment Attribute is
> removed from a CO Enrollment Flow? For example, let's assume it is
> no longer desirable to collect 'Office Telephone' as part of the CO
> Enrollment Flow.
> 
> * For new petitions, there is no problem as we simply don't collect
> the attribute.

Agreed.

> 
> * For in-progress petitions, we can delete any collected attribute.

Could we instead just ignore the collected attribute value?

> 
> * For completed petitions, do we want to maintain referential
> integrity (or even maintain the petition itself) for historical
> purposes? 

I would argue yes. People are going to want to do that as the
size and complexity of the VO increases.

> If so, does that mean we never delete CO Enrollment
> Attributes, only set them to some Inactive status? 

Yes, I think so. 

> Or perhaps it's
> sufficient if our non-existent table-level archive tracks that there
> used to be a reference?
> 
> There's a similar question for the CO Enrollment Flows, too. 
>
> Can
> they be deleted, or only set to Inactive? 

Set to inactive.

> If deleted, do we delete
> the associated Petitions as well?
> 

Thanks,

Scott