create new tag
, view all tags

Bug: Empty Notification After Renaming or Moving a Topic

Renaming or moving a topic puts an entry in notification of changes with the old topic name, thus the WebNotify e-mail lists the old topic name with a missing summary.

Test case

  • Move a topic to another web.
  • Wait for the notification e-mail.

Fix record

Altered the changes and mailnotify script to suppress non existing topics. In TWikiAlphaRelease. -- PeterThoeny - 22 Nov 2001


TWiki version: 01 Sep 2001
TWiki plugins: N/A
Server OS: N/A
Web server: N/A
Perl version: N/A
Client OS: N/A
Web Browser: N/A

Below text is copied from DevOpinionPoll

-- PeterThoeny - 24 Sep 2001

Just realized, that's a whole lotta pages here in Codev that I don't recall touching, trivially or otherwise. Most of those pages got tagged through Rename/move - I moved a bunch of topics to Plugins, and they're the referring pages that got updated. I'd count automatically updating a link to keep it pointing where it should as even more trivial than correcting a typo. NOT registering a change in this case would probably be OK, because it's almost misleading - there was a change, but it didn't affect content, and no-one even actually viewed the changed pages. Renaming/moving just one heavily referred-to page in a big web would change the profile. Say 30-40 topics that hadn't been touched in over three months appeared updated, it would give a completely wrong perception of activity, for one... It's an easy way to look real BUSY...

-- MikeMannix - 20 Sep 2001

So, it's a bug. In any case, I'd put forward that minor changes shouldn't appear in the WebChanges view as by their nature the author is proclaiming that they are not interesting and the reader of WebChanges only wants to see interesting changes.

-- MartinCleaver - 21 Sep 2001

I'd argue that all changes should be available somewhere (for readers). Keeping minor changes out of the WebNotify email is a good idea. Maybe providing an additional page like WebChangesAll or WebChangesMinor will help -- then WebChanges could list only non-minor changes.

-- RandyKramer - 25 Sep 2001

I'll try and fix the changes log to be against new topic rather than old topic.

The WebChanges page simply displays topics in reverse order of file modification date. The referring changes have changed and hence the change shows up. The changes script however will only show the changed topics using the .changes file, which is also used for email notication. We could just use the changes script for major changes, with link to WebChanges for all recent changes. It seems a shame to lose the generality and configurability that the %SEARCH% macro gives the WebChanges topic. How about modifying Search.pm to be able to use the .changes file in place of doing a grep. There is already an order parameter that alters search behaviour and this could be given an extra option of changes.

-- JohnTalintyre - 25 Sep 2001

A rename correctly add a change for the new topic, rather than the old topic. However, there could be entries in the .changes files for the old topic name. I think the best bet are for the changes and mailnotify script to check for topic existance. The alternative is to remove entries from the .changes file. Votes?

-- JohnTalintyre - 25 Sep 2001

Why would references to the old names in the .changes file cause a problem - surely people will just get redirected to the new topic?

I vote that rename should cause a message to be sent to people saying that the old topic has been renamed to the new name. Referring topics should not be notified of.

-- MartinCleaver - 25 Sep 2001

There is no redirect to the new topic as such. There is a special variable that is expanded when you try to view a page that can't be found, this will do a search a find the moved topic (as long as it's no moved again).

Martin said "I vote that rename should cause a message to be sent to people ...". Which people? The new page is the only one (i.e. not old page, or referring pages) put down as a change i.e going in .changes file, so people who subscribe get this in their emails - they have to look at the topic to see it's been renamed (either comparing revs or looking at line that says it's been moved).

  • Well, if I understand correctly, a rename will cause subscribers to see the creation of a new topic and possibly the deletion of the old. If so, it would be nice for them to be told explicitly that the topic had been renamed instead. -- MartinCleaver - 14 Nov 2001

-- JohnTalintyre - 25 Sep 2001

A simple solution is to add a line in .changes for the new location, not for the old location. TWiki::Store::saveTopic() has a flag where you can suppress the .changes entry.

-- PeterThoeny - 25 Sep 2001

As I said above, the .changes entry is added for the new location, not the old location. But, the old location could still have an entry from a previous change. So either the read of .changes should ignore topics that don't exist or the act of renaming should remove the old entry. Preference?

-- JohnTalintyre - 28 Sep 2001

Altered the changes and mailnotify script to suppress non existing topics.

This works for now, but does not address the problem of notifying users of renamed topics (old --> new).

-- PeterThoeny - 22 Nov 2001

Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r11 - 2005-02-15 - SamHasler
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.