Item12055: Push/Pop Topic Context corrupts Session Web.Topic when used in rest handler. Notification emails triggered from browser link incorrectly to Author

The HTML email produced by bin/rest/MailerContribPlugin/notify should render the most recent Author as either a link to the author's wiki user name topic (e.g. DavidHochman) or as plain text (DavidHochman), but is instead rendering it as a new topic in the non-existent MailerContribPlugin web (e.g. DavidHochman).

Here is an example from my company:

  </td><td width="20%">
    <span class="foswikiNewLink">DavidHochman<a href="https://wiki/bin/edit/MailerContribPlugin/DavidHochman?topicparent=MailerContribPlugin.Notify" title="Create this topic">?</a></span>
  </td>

Here is the relevant part of templates/mailnotify.tmpl:

  </td><td width="20%">
    %AUTHOR%
  </td>

The resolution may be as simple as changing %AUTHOR% to %USERSWEB%.%AUTHOR%. Changing templates on the server carries quite a bit more enterprise-inertia than changing topics in the wiki.

-- DavidHochman - 27 Aug 2012

The %AUTHOR% is a template token, not a macro. It is expanded by Fosikik::MailerContrib::Change() using Foswiki::Func::getWikiName(). This should probably use the getWikiUserName function. It should also test if the topic exists, and render it as a literal instead of a missing link. Not all registration methods create User web topics.

For some reason though, this is not failing on foswiki.org. Wondering if it's related to our use of FindElsewherePlugin so user names resolve cross-web.

-- GeorgeClark - 27 Aug 2012

Digging a bit further, This is not failing on a 1.1.3 system I run, and it doesn't have FindElsewherePlugin installed. I'm not sure what is going on. It almost sounds like when the mailnotify process is running, it doesn't have a default web when it renders the html. Which version of MailerContrib do you have installed? On my working 1.1.3 system MailerContrib is version 2.4.4, 2.5.2 is current. (checked with bin/configure - the FindExtensions tool.

-- GeorgeClark - 27 Aug 2012

On my Foswiki-1.1.4, Tue, 20 Dec 2011, build 13483, Plugin API version 2.1, MailerContrib is Version: 13315 (2011-12-06), Release: 2.5.2.

A possible difference, I am triggering mail notification from the browser via URL https://wiki/bin/rest/MailerContribPlugin/notify as a scheduled task in Windows, not from a cron job on the server. That may not be typical.

-- DavidHochman - 27 Aug 2012

This is a problem only with triggering mail notification from the browser via URL https://wiki/bin/rest/MailerContribPlugin/notify, both manually and as a scheduled task. It is not a problem when run on the server via command-line or cron job.

I will rename the task and reset the state to New.

-- DavidHochman - 30 Aug 2012

Changing the task to Confirmed. I can recreate the issue on trunk (Foswiki 1.2) using the rest command. Not quite sure where the bug is. The Foswiki session has the correct topic context. I added in a print of the current Web and Topic in the context when the rest command starts: = CONTEXT: Main, WebHome=, so why the HTML is rendered using the wrong web context, I'm not sure.

Changing the template will certainly get around the issue, but it's not really fixing the underlying problem. Something is mis-interpreting the url path for the rest command.

-- GeorgeClark - 31 Aug 2012

Found the underlying issue. MailerContrib uses the following sequence:

    Foswiki::Func::pushTopicContext( $web, $Foswiki::cfg{NotifyTopicName} );
 ... some processing ...
    Foswiki::Func::popTopicContext();

When run under a REST Handler, popTopicContext corrupts the Session Web.Topic context, changing it from the default Main.!WebHome to the rest handler name.

-- GeorgeClark - 31 Aug 2012

This is nothing to do with the mailer, it's a fault in the core. popTopicCOntext should restore the original wherever it it.

Upgrading to Urgent, as it's an obvious and nasty core bug.

-- CrawfordCurrie - 25 Mar 2013

Commenting is disabled while not logged in