Skip to Content.
Sympa Menu

comanage-dev - Re: Fwd: [comanage-dev] Notes on CO-172

Subject: COmanage Developers List

List archive

Re: Fwd: [comanage-dev] Notes on CO-172


Chronological Thread 
  • From: Benn Oshrin <>
  • To:
  • Subject: Re: Fwd: [comanage-dev] Notes on CO-172
  • Date: Wed, 07 Sep 2011 19:50:12 -0400

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.

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 or NULL (which we would have to document in the REST docs and the UI). Seems easier than forcing someone to reassign (or worse, delete) all the children. Thoughts?

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 :)

-Benn-



Archive powered by MHonArc 2.6.16.

Top of Page