COmanage Developers List

[Scott Koranda <>]

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

Hi,

This will require substantial changes to the GrouperProvisioner.

My concern is that between now and TIIME I will not be able to
do that work, and then I am at TIIME, and then immediately
after that I am on vacation. After returning from vacation I
will need a week to catch up with clients. So the earliest I
could begin this work would be about March 20.

Are you willing to put off 1.1.0 until late March, early
April?

Thanks,

Scott

P.S. It is also an opportunity to completely re-work the
GrouperProvisioner, which badly needs refactoring.