COmanage Developers List

[Benn Oshrin <>]

I've re-updated the diagram.

There's a side effect of the new approach which is when administrator 
enrollment is performed by a non-reconciliation manager, a new Org/CO 
Person is created even if the person already exists. The new ID doesn't 
get merged into the existing one until the reconciliation step. 
Effectively, I needed to bake a "merge identities" step into the process.

There's also a question of how adding a role for an existing CO person 
differs from starting an enrollment process from the beginning. It may not.

-Benn-

On 2/14/12 5:27 PM, Benn Oshrin wrote:
> I've updated the diagram. One of the reasons we set up the original
> process was to simplify reconciliation... we're going to have to figure
> out what to do about that in the updated process, but I want to get more
> of it coded before we think about it.
>
> On 2/13/12 9:03 AM, Scott Koranda wrote:
> > > 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