Question

I had managed to successfully configure mail notifications via WebNotify for several distinct groups at my company according to project. The rules I was using looked like:

ProjectGroup : ProjectPrefix*

...where the members of a particular project were all members of ProjectGroup.

However, to get access controls working the way we wanted, we recently had to move each project to its own web, and this made notifications stop working.

Each project web (e.g., ProjectFoo) now has its own WebNotify topic containing the subscription details, but the user and group topics are still stored in the Main web. So ProjectFoo's WebNotify looks like:

Main.ProjectFooGroup : ProjectFooPrefix*

Like I said, though, the notifications are no longer getting sent. I've sifted through the logs, checked the permissions on the Web-specific subdirectories of work_areas, and I've got no idea what's wrong. When I run the mailnotify script by hand, it collates the pending notifications, but then prints out something like:

0 change notifications from ProjectFoo
0 change notifications from ProjectBar

I can still create subscriptions that work within the Main web -- that is, when the users and topics are both in Main. Any idea what I'm doing wrong?

As an additional bit of trivia, I've noticed that I was able to make subscriptions for individual users work again by prefixing their WikiName in the subscriptions with % USERSWEB% (minus the space), e.g.,

% USERSWEB%.ProjectFooUser : ProjectFooPrefix*

Update: Tried the same configuration with the release version of TWiki 4x02 -- still doesn't work. Could someone take a look at this and confirm it as a bug or give us some tips on how to proceed? This is making TWiki somewhat inconvenient for us to use.

Environment

-- JulianGraham - 14 Jan 2008

Answer

I'll have to assume that you are using conventional TWiki authentication, and that usernames are the same as wikinames.

The notify code works by looking up users after first stripping off the prefixed webname. It then uses the TWiki standard Func API, which calls the TWikiUserMapping, which in turn reads the user and group topics. once a user is identified, it uses the password system (probably HtpasswdUser in your case to look up an email address for the user.

Once a notification has been generated, the mailer code timestamps the web to say that notifications have been generated. Subsequent runs on the same web will only show incremental changes since the last notification.

Now, there are a number of places this might be going wrong for you. First, and simplest, you may just have a timestamp present that is telling the mailer that nothing has changed since the last notification. Look for working/MailerContrib/webname for the timestamp for each web. If you delete the timestamp file it will reset the clock for that web to zero, and you should see all changes since 1970 going out.

Second, your users may not be being recognised as valid users by the TWikiUserMapping - though I would expect a "no such user" message in this case.

Third, your users may be recognised, but may have no valid email address. Again, I would expect a more revealing error message.

Based on what you have described, I suspect that you simply have timestamps in the way, and that is all that is blocking notifications.

Note that the web prefix on user names is a purely cosmetic thing; it makes the wikiword (the user's wikiname) appear without a question-mark. %USERSWEB% is automatically expanded to the name of the users web, and the code strips off the users web prefix when it reads WebNotify anyway, so %USERSWEB%==Main, and it doesn't actually matter whether you use it or not anyway.

-- CrawfordCurrie - 18 Feb 2008

If you answer a question - or have a question you asked answered by someone - please remember to edit the page and set the status to answered. The status is in a drop-down list below the edit box.

Thanks for the reply, Crawford. (Actually, we're using the ApacheLogin LoginManager. I don't know if that's significant.) Unfortunately, deleting the timestamp files didn't seem to have any effect. Do you guys know for sure that this feature works? Would it help if I created an easy-to-reproduce test caste?

-- JulianGraham - 18 Feb 2008

Okay, I've figured this one out.

We'd set up several groups, among them "CompanyStaffGroup" and "ProjectNotificationGroup" which respectively mapped to everyone at the company (who should be able to view and edit all the pages) and the members of the specific project (who would in particular want to get notifications about changes to a set of project-specific pages). In the WebPreferences for the ProjectFoo web, the ALLOWWEBVIEW was only set to CompanyStaffGroup. When I added ProjectNotificationGroup, everything worked again.

What was happening was that MailerContrib/WebNotify.pm was checking the access permissions of the WikiName as a group and not individual users, even though that group was, in terms of membership, if not explicit access rights, a subset of a group that had VIEW permission.

-- JulianGraham - 26 Feb 2008