Item4812: WebNotify: improper interaction between group and individual subscriptions

I want to use WebNotify and MailerContrib. For a given web, I want to just subscribe one or more groups. But if an individual doesn't want a subscription, then that individual should unsubscribe by using the SubscribePlugin.

Issue 1: I set up the following subscriptions:

• admin: *
• bobg: - *

Now, admin is a group that contains the individual bobg. The way I read the documents, everyone in 'admin' should be subscribed except bobg. Yet even bobg gets the email.

Issue 2: Less important, but the %SUBSCRIBE% variable does not properly check membership in any subscriber groups. So the toggle between 'Subscribe' and 'Unsubscribe' can be wrong if the logged on user is a member of a subscription group.

I don't think the following is relevant, but I have my own UserMapping.pm and PasswordUser.pm modules, so I can enforce loginname=wikiname, can authenticate with ldap, hold groups in ldap, and easily map email to loginid.

The way I read it, in Contrib/MailerContrib/WebNotify.pm in processChange(), the check if a user is subscribed (and not unsubscribed) takes place before the call to getEmailAddresses(), which in turn is where the expansion of the group takes place.

Seems to me, the proper fix would be in Webnotify::subscribe() (and unsubscribe()), where any group subscription should be expanded to multiple user subscriptions at that point.

-- TWiki:Main/BobGoldstein - 14 Oct 2007

I'm wrong about modifying subscribe(), and expanding groups at that point. If I do that, the mail is sent correctly. But when I use the Subscribe plugin, writeWebNotify() writes back the value of stringify(), and that now has the expanded view of subscribers, not the orignal group name. Not good.

-- TWiki:Main.BobGoldstein - 14 Oct 2007

There's another problem with expanding groups, and that is that there are some huge groups - for example, the "Engineering" group in an engineering company can have tens of thousands of members. So group expansion is not really an option, and the SubscribePlugin is likely to fall to its knees. Checking group membership is feasible, but at the time I wrote the Mailer the API for this testing was unstable.

4.2 has a much better API for handling group membership, and this API ought to be leveraged to improve the Mailer and Subscribe plugins.

-- TWiki:Main.CrawfordCurrie - 14 Oct 2007

What would be the difference between expanding one group with 10000 members, and listing out all 10000 explicitly in WebNotify? Wouldn't the SubscribePlugin die in either case? It's a matter of scale, not whether you expand groups or not. If the groups are that large, don't use the SubscribePlugin.

Anyway, I've discovered a 90% solution, at least for the scenarios I'm concerned about (now!). That is, I added a parameter to WebNotify->new() called $noexpandgroups. By default, groups are expanded in subscribe() and unsubscribe(), but this can be suppressed by setting this flag to true.

I want to expand groups in almost all cases. The only exception is when I will change a subscription, which happens in SubscribePlugin::_subscribe(), so there I create $wn using this flag. And obviously, this default could be controlled by a $TWiki::cfg param, if a site never wanted to expand groups. (E.g. use large groups, but not allow explicit unsubscriptions)

One remaining issue, maybe you can resolve in 4.2. is this. If a person is in a group, and decides to unsubscribe, you get:

admin: *

bobg: - *

Which is fine. But if the person changes his mind, and wants to subscribe, you get:

  admin: *

bobg: *

As opposed to realizing that bobg is a member of the admin group, so the subscription does not need to be explicit. Minor distinction, but what if bobg later leaves the admin group? His subscription should be revoked, but it won't be. Or, I suppose, if the person has explicitly unsubscribed, and then falls out of the group, the explicit unsubscription should be cleaned up at some point. I'm willing to ignore those problems for now

-- TWiki:Main.BobGoldstein - 14 Oct 2007

Me too. There comes a point where a manual edit of the WebNotify is the only sensible course for rationalising the subscriptions.

If you would like to provide your noexpand change in the form of a patch, I'd be quite happy to consider it for inclusion.

CC

• WebNotify.patch: Patch to MailerContrib/WebNotify.pm to enable condition group expansion

• SubscribePlugin.patch: Patch to Plugins/SubscribePlugin.pm to coordinate with conditional group expansion

Glad to. I attched two patch files (hope that's the right ettiquette for submitting patches.)

-- TWiki:Main.BobGoldstein - 03 Nov 2007

Thanks Bob, merged. Sorry it took so long. Next time, set the bug status back to New and I'll react faster.

CC

This broke the MailerContrib on 4.2 and MAIN. Reopening with prio urgent.

-- TWiki:Main.MichaelDaum - 29 Jan 2008

It didn't break 4.2 because the change never went into 4.2. But it did break MAIN; fixed now.

CC