Grouper Users - Open Discussion List

[Julio Polo <>]

Definitely, mailing list integration opens a new can of worms.  We provide an option for groups to be synchronized with a respective LISTSERV mailing list, and we have observed that people tend to unsubscribe themselves from mailing lists, even if they've never received email from that mailing list.  The group admin needs to be alerted of such discrepancies, and currently, the only viable option is to remove the person from the Grouper group.  I can imagine there may be scenarios where a person needs to remain in the group (for AuthZ purposes) but can be off the mailing list.  There may also be use cases where it's unacceptable for someone to unsubscribe from a mailing list (though that's probably a losing argument if you engage with the subscriber).

We have also encountered the external email subscriber issue (where the email address cannot be derived from a subject in Grouper).   For now, we track these external email addresses in a file associated with each group that syncs to a mailing list.  The same goes for any mailing list configuration settings (LISTSERV headers).  We need to control certain LISTSERV header settings in order to handle errors associated with the group-to-mailing-list sync, but we also want to allow the group and/or mailing list admin to choose how their list will behave (e.g. is it moderated?  who can send to the list?).   We currently address this by taking over the administration of the LISTSERV headers; any changes have to go through us.  This won't scale, so we'll eventually need a better way to address this and the many other issues that come with integrating Grouper groups with external group repositories.

-julio

Julio Polo
Enterprise Middleware, Identity and Access Management
Information Technology Services
University of Hawaii

On Fri, Nov 13, 2015 at 10:44 AM, Jeff McCullough <> wrote:

This question is both for other schools as well as the grouper team. As we look further at an integration with Google Groups, there are several mailing list options to think thru. There are the issues of external identities and options for requesting/subscribing/leaving a group (those standard mailing list functions). If we want one group source, grouper, that pushes groups to all the campus services, then grouper may need to have extra functionality. If you have mailing list service, aka mailman, the ability to add any email to a list is standard, send email to confirm are standard features. One can also request to be added to a list. Subscribing/leaving are also standard, and grouper already has those features in opt-in/opt-out permissions. When it comes to sending email, I know it is possible to have grouper send email when someone is added/removed from a group, but that is more a confirmation that the event happened rather than a confirmation cycle where the person being added is confirming they want to be added by replying or following a link. I’m not suggesting that the confirmation cycle be there in groups, but noting it is a standard feature of mailing lists. Lastly, when it comes to sending emails, there are times when sending an email might be confusing or unnecessary, so having a way to signal to the system that we want an email sent is useful.

For any school that has made a conversion from a regular mailing list to Google Groups, how did you had those features above? Did you find work arounds or just decided they were not going to be available. For the grouper team, I’m wondering if there has been any design discussions around including email features and the ability to create an identity or to just include an external email account in a group. I know that last one has all sorts of issues, but just want to get a sense of direction. There are the external identities which have an invite process and there are the general external identity features offered through vendors like Cyrius Identity. There isn’t the ability to just add an external identity when that might be useful.

Thanks,
Jeff