Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] functionality request, invitation service ....

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] functionality request, invitation service ....

Chronological Thread 
  • From: Chris Hyzer <>
  • To: Steven Carmody <>, "" <>
  • Cc: Mark Earnest <>
  • Subject: RE: [grouper-dev] functionality request, invitation service ....
  • Date: Tue, 13 May 2014 15:53:43 +0000
  • Accept-language: en-US

Seems like it might be trouble to tie the user who invited the person to the
membership. Maybe just an end date that emails the group admins? Maybe
there was turnover of the person who invited the user and someone else should
make sure the membership should be there. The group admin. Or would the
user handle that when they get the email?


-----Original Message-----

On Behalf Of Steven Carmody
Sent: Tuesday, May 13, 2014 11:47 AM
To: Chris Hyzer;

Cc: Mark Earnest
Subject: Re: [grouper-dev] functionality request, invitation service ....

On 5/12/14 3:13 PM, Chris Hyzer wrote:
> I added a jira.


> Do you want to know who added the user overall, and keep that
attribute with the user record. Or do you want to know who invited a
user to a group, and keep that attribute on the membership?

We currently have a set of "sponsored IDs" in our Person Registry (ie I
can sponsor a local account, here at Brown, for Chris Hyzer; this is how
the world used to work ;-) ). On the yearly anniversary of the creation
of that Sponsored ID account our IDM system will send an email to both
the sponsor and the holder of the Sponsored ID account, asking if it
should be kept active. Without a positive response, the account moves
down the workflow steps to remove it.

I'm thinking of using the same model for "invited external guests". On
the yearly anniversary send an email to both the invitor and the
external person asking if the group membership is still needed. Its the
only way I can currently think of handling de-provisioning for these
external people.

So, I think that implies keeping the identity of the invitor with the

And, perhaps, when the set of group memberships for an external person
reaches zero we could flag that record for removal from our Person Registry.

I'd be keenly interested, tho, in hearing how other people are thinking
about handling de-provisioning for external users.

> Do you want that information kept for all external users, or is it
only for certain groups?
> Thanks,
> Chris
> -----Original Message-----
> From:
> [mailto:]
> On Behalf Of Steven Carmody
> Sent: Monday, May 12, 2014 3:03 PM
> To:
> Subject: [grouper-dev] functionality request, invitation service ....
> Hi,
> Would it be possible to extend the content of the Invitation Services
> "Registration Page" to accept (and store) the set of attributes
> associated with the InCommon Research and Scholarship attribute bundle ?
> It would also be helpful if in the name of the invitor (sponsor) were
> saved (this would allow us to send a "renewal" email at some future
> date, asking if we need to keep this external person in our local Registry).
> I believe this is mostly a question of fields on the form that is
> presented to the invited user, and the DB schema where this information
> is stored.
> I'd suggest that the R&S attribute bundle represents a "reasonable" set
> of info to collect and store about a person.

Archive powered by MHonArc 2.6.16.

Top of Page