COmanage Users List

[Benjeman Meekhof <>]

This behavior surprised me, I think it's by design but maybe it
shouldn't be since it messes with what seemed like the most logical
use-case I could come up with.  Maybe someone can enlighten me as to a
better way to avoid this issue.

When I update any CO person information it triggers a provision action
to the Grouper provisioner which ultimately ends up calling
provisionCoPerson in CoGrouperProvisionerTarget.php.  At the end of
the function the CoPerson is deleted from any Grouper groups which
they do not belong to in Comanage - even groups which do not exist at
all in CoManage.

My expected use was that I'd be able to manage identities in Comanage,
and create no groups in COmanage except the core/automatic CO_COU
groups which are provisioned to Grouper.  I then do any further group
management under the COU sub-stems in Grouper.  This doesn't exactly
work if Comanage deletes memberships from Grouper groups it isn't
responsible for, and as far as I am concerned that behavior is really
only appropriate when we are deleting a CO person and want their
subject taken out of Grouper groups entirely (but I imagine we could
catch that by deleting unknown subjects from Grouper groups with a gsh
job).

In my case a small workaround in the php code only matches the COU
default groups for this variable which is used later to loop through
and delete group memberships not found in CoManage:

(line 618)
 // Filter the returned groups by the stem that this plugin is
configured to control, but only match groups that Comanage is
responsible for.
    $grouperGroups = array();
    $stem = $coProvisioningTargetData['CoGrouperProvisionerTarget']['stem'];
    // change this preg pattern to only match relevant groups
    $pattern = "/^" . preg_quote($stem, '/') . ".*" . "CO_COU_.*/";
    foreach($allGrouperGroups as $g) {
      if (preg_match($pattern, $g)) {
        $grouperGroups[] = $g;
      }
    }

This of course wouldn't work if any other groups are created in
Comanage and not named by the CO:COU convention that default COU
groups use, but I'll never be creating any groups in COmanage except
those 3 it creates automatically for every COU (CO top-level groups
don't seem to make it to Grouper, which is preferable anyways).

thanks,
Ben