Grouper Users - Open Discussion List

[Peter DiCamillo <>]

Currently, using a group, we give people admin privileges to most of the 
course groups. Full admin privileges are only required for the current 
semester, but for old semesters we'd still want them to have read 
privileges. Would there be any performance benefit to changing the old 
admin privileges to read?

Peter

On 1/31/13 5:15 PM, Chris Hyzer wrote:
> I wonder if you could do privileges by semester, or do all the people with 
> privileges need it for 5 years back?
>
> Thanks,
> Chris
>
> -----Original Message-----
> From: Peter DiCamillo [mailto:] 
> Sent: Thursday, January 31, 2013 3:02 PM
> To: Shilen Patel
> Cc: Chris Hyzer; Gagné Sébastien; 
>
> Subject: Re: [grouper-users] Defining rule-based group privileges?
>
> Thanks, I'll try changing includeFlattenedPrivileges, it's set to true 
> now. I tested by adding a person to the group that is used for 
> privileges. We have about 800,000 course groups, since we have to keep 
> the course memberships for at least five years.
>
> Peter
>
> On 1/31/13 1:08 PM, Shilen Patel wrote:
> > The delay may be in creating change log entries for the flattened
> > privileges.  In the grouper-loader.properties file, what do you have
> > changeLog.includeFlattenedPrivileges set to? If it's true and you don't
> > care about flattened privileges, set that to false and see if it resolves
> > the issue.  However, in either case, I wouldn't think it would take an
> > hour to do this.  Is the member (that's being added to the group which has
> > privileges to all the course groups) a person or a group?  How many course
> > groups are there?
> >
> > Thanks!
> >
> > -- Shilen
> >
> >
> > On 1/31/13 9:40 AM, "Peter DiCamillo" 
> > <>
> >  wrote:
> >
> > > On 1/30/13 5:55 PM, Chris Hyzer wrote:
> > > > > We've encountered performance problems when assigning the members of a
> > > > > group 
> > > > > privileges to thousands of groups,
> > > > I think that was on an old version of Grouper, this is not a problem
> > > > anymore, right?
> > > I do still see one problem. If we make a change to the membership of the
> > > group that has privileges for all the course groups, entries in the
> > > change log temp table are not processed for a very long time. For
> > > Grouper 2.1, I stopped timing it after an hour. It took several hours
> > > for 1.6. We use a change log consumer for near real-time provisioning,
> > > so that's a problem. In some cases, users are making requests to access
> > > a service, and expect to get access within about 10 minutes. The only
> > > solution I have is to handle changes to that group as a maintenance
> > > activity.
> > >
> > > Peter