> On Sep 26, 2016, at 8:16 AM, Shawn McKinney <[email protected]> wrote:
>
>
> I should have brought this one up sooner. For each role assigned to group,
> we have to perform a read, to pull back its constraints. This works but not
> efficient. It’s OK for now and not a showstopper. Eventually we’ll want to
> store these constraints on the group object itself like done with the user
> object. That way we can perform the method will one read.
Another idea is to pull back all of the group-role assignments in a single ldap
search operation. The ldap filter will contain all the role dns (in the member
list) and so we can pull back all the records at once.
Not quite as efficient as what’s mentioned in my before comment, but simpler to
maintain in code and data.
I’ve tested in a sandbox and it passes the new groupmgr tests. I’ll check it
in after Chris P gets his merge done.
Here’s what the new fillRoles method looks like. It’s making just one call to
a new method in the roleP to search by group. Next we iterate over the list
and convert to target as before.
private void fillRoles( Group group ) throws SecurityException {
if ( Group.Type.ROLE.equals( group.getType() ) )
{
RoleP rp = new RoleP();
List<UserRole> uRoles = new ArrayList<>();
List<Role> roles = rp.search( group );
for ( Role inRole : roles )
{
UserRole ure = new UserRole( group.getName(), inRole.getName(),
true );
ConstraintUtil.validateOrCopy( inRole, ure );
uRoles.add( ure );
}
group.setRoles( uRoles );
}
}
Shawn
