COmanage Developers List

[Scott Koranda <>]

> On 9/7/11 7:36 PM, Marie Huynh wrote:
> 
> >https://spaces.internet2.edu/display/COmanage/cm_cous
> 
> Minor nit... I like to group things together in the data model
> (though I can't exactly explain what my rules are). In this case,
> I'd probably put parent_cou_id right after co_id.
> 
> >https://spaces.internet2.edu/display/COmanage/COU+Schema
> 
> Same nit as above.

On the whole LIGO software engineering is poor because its
done by a bunch of physicsts.

To the extent that we can follow your lead and set a good
example for the rest of LIGO I support it.

(more below)

> 
> >Is this staying Version 1.0?
> 
> Strictly speaking we should rev the version, but the code can't
> handle version management right now and we haven't had a real
> release, so we'll leave it at 1.0.
> 
> >https://spaces.internet2.edu/display/COmanage/COU+API
> >
> >There are two 403s.  Are we also filing these under 403?
> 
> I think so. There aren't really that many useful status codes, which
> is slightly annoying. I'd probably reword them slightly so they're a
> little more self-explanatory and more consistent with the existing
> errors:
> 
>  40x Not Member -> 403 Wrong CO
>  40x Has Children -> 403 Child COU Exists
> 
> Note Edit also requires both checks since you can edit the
> parent_cou_id, which would effectively behave as a delete followed
> by an add.
> 
> Actually, now that I think about it, why can't you delete a COU with
> children? The children would just be reassigned to the parent COU 

That may not be at all appropriate.

> or
> NULL (which we would have to document in the REST docs and the UI).

I would prefer NULL, but see below...

> Seems easier than forcing someone to reassign (or worse, delete) all
> the children. Thoughts?

It's too much power--one CO or COU admin could inadvertantly
wipe out a lot of state.

I would prefer that it take a lot of action to wipe out those
relationships.

> 
> BTW, I realize there's a lot of nitpicky-in-my-head stuff that we
> can look forward to here. Shaking it out is going to be an annoying
> part of this exercise :)
> 

See above.

Thanks,

Scott