Grouper Users - Open Discussion List

["GW Brown, Information Systems and Computing" <>]

The approach I'm taking to incomplete data from source systems e.g. student 
systems is to set up the following groups:

Registered students for X
Ad hoc students for X

All students for X -> has above two groups as members

Inactive students for X

and finally:

Students for X -> All students for X <complement> Inactive students for X

which is the group I would use for granting privileges.

Currently I place all but the last group under another stem to reduce 
clutter.

If you don't need to cater for people who need removing it is simpler - 
fewer groups.

Gary



--On 03 March 2008 12:26 -0500 Bert Bee-Lindgren 
<> wrote:

> We have official data. (Slow, untouchable)
> We have data on the ground. (Needs to be right or people can't do  their
> jobs)
> Sometimes we want both in groups.
>
> Yes, we wish the official data were better, but it's never going to be
> fast or right enough. For example, HR just does care about adjuncts,
> collaborators, employee loans (that don't involve money), etc.
>
> When I look at grouper, I don't see the richness of overrides that
> Signet offers, particularly, temporary or other conditions, proxying,
> etc.
>
> So, do people typically have the following pattern?
>         HRMS Data: Faculty in History Department  (updated at the speed of
> bureaucracy)
>         LDAP/IdM Store: Faculty in History Department (synchronized with 
> above)
>         Grouper: HRMS:History:Faculty (official group, a good starting point,
> but limited usefulness)
>
>         Grouper: Departments:History:Faculty (group that can be tweaked by
> department to include adjuncts, other non-employed researchers/
> collaborators, etc)
>     or
>         Signet: Departments:History:Faculty (departmental "membership"
> privilege that can be tweaked by department, but using temporary (etc)
> conditions)
>         Grouper: Departments:History:Faculty (group made from the above
> privilege that can be used by group-consuming systems)
>
>
> In other words:
> a) How do implementations deal with groups that need to be tweaked  into
> other groups, when those tweaks benefit from signet's abilities?
> b) Does anyone take all of signet's privileges and make them groups,
> just in case the Service-Providing system wants groups instead of
> attributes?
>
> Thanks,
>    Bert



----------------------
GW Brown, Information Systems and Computing