COmanage Developers List

[Benn Oshrin <>]

In reference to this diagram

 https://spaces.internet2.edu/display/COmanage/Registry+Enrollment

I'd like to propose a revision of the described process. In the current 
version, we don't write to co_people, co_person_roles, or org_identities 
until the processes merge together, post approval. There are various 
reasons why we decided on this approach which I won't recount here.

As I start to implement this, I'm now thinking we should write to these 
tables much earlier, roughly at the two boxes that describe completing 
forms as per co_enrollment_attributes. I'm arguing for this change for 
two main reasons:

(1) It's going to be dramatically easier to implement than what we first 
proposed. Basically, we'll be able to use co_enrollment_attributes to 
dynamically generate forms that directly reference the tables we want to 
store the data in, eg

 CoPerson.title
 Name.type

(We can still optionally copy these attributes to the petition history, 
or rely on our not-yet implemented audit feature.)

In the current model, we need to do a pretty ugly mapping to and from a 
typeless representation (as described in co_petition_attributes). This 
mapping is almost certainly going to be a pain to maintain.

(2) It will allow a CO[U] admin to pull up a single list of all their 
people, both active and petitioning. (A simple filter would allow them 
to see one or the other if they didn't want them combined.) If 
petitioners don't show up in co_people right away, it will require two 
separate views to see these populations.

Comments? We can discuss on the next standup call if it's helpful.

-Benn-