Item2140: mailnotify should respect the context of the user (and topics) for which it is called

Description

This is a somewhat similar problem like we hat in Item1847.

mailnotify expands some variables in a wrong way:

1. BASETOPIC gets expanded to WebHome and therefore TOPICURL also points to WebHome
2. HTTP_HOST is just empty

Via http the macros get expanded as they should.

-- PhilippLeufke - 22 Sep 2009

Is this 1.0.6 as you have marked or the new 1.0.7?

-- KennethLavrsen - 22 Sep 2009

It's 1.0.6-3 from the latest debian packages.

-- PhilippLeufke - 23 Sep 2009

I ask because we closed a similar bug in 1.0.7

Item1741

Can you check if this is related?

-- KennethLavrsen - 23 Sep 2009

If it's related, I can't tell, but at least I do encounter the bug described there, as well.
*But:* redefining TOPICURL to use %BASEWEB instead of WEB like described in Item1741 doesn't solve the problem described here...

-- PhilippLeufke - 23 Sep 2009

Then it is probably a different bug and probably also in 1.0.7

-- KennethLavrsen - 23 Sep 2009

I would expect HTTP_HOST to be empty - there isn't one. This is a CGI-fuelled macro, and when running from cron, CGI isn't there.....

As for BASETOPIC, I consider a setting of WebHome to be correct; what else could it be? It's reporting on changes across many different topics.

Can you clarify what you would expect instead?

-- CrawfordCurrie - 08 Dec 2009

I understand from the technical point of view.

But the end-user will just expect the mentioned macros behave like they do when the topic is accessed via the web browser.

So the BASETOPIC should get resolved to the topic which is being notified about (i.e. which was modified and now triggered a notification).

HTTP_HOST should get resolved to the http host name like configured in localsite.cfg, I think.

-- PhilippLeufke - 14 Dec 2009

I don't agree about %HTTP_HOST%, as it has a specific meaning that is not fulfilled by the value of $Foswiki::cfg{DefaultHost}, and is deprecated anyway - if you are trying to build a script name, use %SCRIPTURL. %BASETOPIC% is correct if you think about the mail as being a topic that is being populated by a search for changes. It changes anyway, if a topic is included from another topic - i.e. it has a variable value depending on context.

I really don't see this as particularly important. I'm afraid it's not something I'm going to spend time on. Reduced from 'Normal' to 'Low' priority - if someone else wants to work on it, they can raise it again.

-- CrawfordCurrie - 15 Dec 2009

Sorry, I still don´t agree. I understand how BASETOPIC is working, but thinking of mailnotify as a search started from WebHome is counter-intuitive for any user who doesn´t know how it is working.

According to VarBASETOPIC the BASETOPIC variable should get resolved to the topic which is requested by the user which is in my eyes the topic which has been modified and which is now being emailed to the user by mailnotify (i.e. he requested it). And it is in all but one cases not WebHome.

To make my motivation more obvious:

• Imagine we have a subscribed to all MeetingMinutes*?
• Each meeting minutes topic has a standard footer included which features a sentence like "Access this meeting minutes online at [full URL to topic]", to make the URL more popular.
• Now how to form this [full URL to topic]?
  • %TOPICURL% would be expected to result in the URL of the included footer (instead of the specific meeting minutes URL), but it expands to WebHome´s URL in mailnotify
  • as there is no option for passing parameters to TOPICURL like e.g. %TOPICURL{%INCLUDINGTOPIC%}%, I only see the way of building the URL in a way like http://%HTTP_HOST%/%WEB%/%INCLUDINGTOPIC% but this won´t work as the HTTP_HOST doesn´t get expanded in mailnotify like one would expect from the http rendered topic (where this works, of course).
  • the abovementioned way of using INCLUDINGTOPIC in the handmade URL only works if this is a first order INCLUDE. For nested INCLUDES we would need BASETOPIC to work in mailnotify like it does in http.

I want to stress, that I really think, that as many macros as possible should work in the same way for http rendered topics as well as for topics sent via mailnotify. Anything different will only confuse users (and me).

-- PhilippLeufke - 15 Dec 2009

PS: Maybe extending the functionalities of TOPICURL (like mentioned above) and INCLUDINGTOPIC{as a function of INCLUDE depth} would be worth to think about?

---

I hear what you are saying, and have some sympathy. However it's pretty low on my radar. If you want to attach a patch, then I'll certainly give it more consideration.

-- CrawfordCurrie - 15 Dec 2009

Revisiting this. It's correct to say that mailnotify should respect topic preferences/context. It should also respect the context (preferences) of the user who is the target of the mail. Changed the headline from "mailnotify doesn't expand BASETOPIC, TOPICURL and HTTP_HOST properly" to reflect this.

-- CrawfordCurrie - 30 Apr 2014