COmanage Developers List

[Scott Koranda <>]

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

I think I understand this reason.

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

I think I understand this reason.

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

I cannot make the scrum call today--I have a once off
conflict.

Can we put this on the list for Wednesday's call? 

Please proceed and don't wait--I just want to understand.

Thanks,

Scott