COmanage Developers List

[Benn Oshrin <>]

I realize this is a bit late for 1.1.0, but we need to solve the 
"members is everyone or just active people" issue for Lafayette, so this 
is technically a bug. As I dig through this, a lot of code is touched, 
so I'm inclined to try to fix a few longstanding issues that are sort of 
related.

Ignoring transition issues for the moment, my proposal is to add two new 
attributes to co_groups:

group_type: An enum indicating if the group is a "special" group 
(admins, members, etc). If not null, the group cannot be deleted.

auto: A boolean indicating if the group is automatically managed. If so, 
the UI and REST API will not permit direct manipulation of the group.

(Once the existing code is refactored, the above means you could rename 
the admin group if you wanted.)

Upon creation of a new CO or COU, the following groups will be created 
(as appropriate):

 CO:admins (formerly "admin")
 CO:members:all (formerly "members", sort of)
 CO:members:active
 CO:COU:<couname>:admins (formerly "admin:<couname>")
 CO:COU:<couname>:members:all (formerly "members:<couname>")
 CO:COU:<couname>:members:active
 CO:COU:<couname>:members:nested:all (includes subordinate COUs, 
eventually)
 CO:COU:<couname>:members:nested:active

The prefix "CO:" will be reserved. However, we might ultimately want to 
allow COU specific groups to be made under CO:COU:<couname>:something.

The biggest issue is likely to be on the provisioning side. For LDAP 
directly provisioned by COmanage, the group memberships will change.

This is a big change, but we have to do it at some point, and I'm 
inclined to rip the bandage off sooner rather than later.

Thoughts?

Thanks,

-Benn-