Item11173: TOPICINFO is wrong on trunk and 1.1.4
Priority: Urgent
Current State: Closed
Released In: 1.1.4
Target Release: patch
Noticed that my topic dates were displaying incorrectly on 1.1.4.
The TOPICINFO metadata appears corrupted in the debug view of the topic.
File contents
data/System/Macros.txt
from the svn checkout
xMETA:TOPICINFO{author="ProjectContributor" date="1231502400" format="1.1" version="$Rev$"}%
File display
http://trunk.foswiki.org/System/Macros?raw=debug
xMETA:TOPICINFO{author="BaseUserMapping_999" date="1309515309" format="1.1" version="1"}%
The last user modifying the topic is shown as
UnknownUser, where as the metadata
ProjectContributor exists and should be valid. I'm also seeing incorrect topic dates shown, although in this example, the date 1 July 2011 is correct. Noticed this when trying to rewrite the $Rev$ strings to version 1. No matter what I was writing in the TOPICINFO date field, I get today's date. ... ah - it shows the file system date instead of the topicinfo data. This means that file system maintenance that touches files will update last modified dates. This is not right.
--
GeorgeClark - 08 Oct 2011
Ah. Not quite.
The problem is deciding what TOPICINFO means when a topic has been edited outside of the normal history process. There are three states a topic can be in:
- No history
- .txt is more recent than most recently logged history
- .txt is consistent with history
Obviously 3 is where we want to get to; 2 is irrelevant here, and 1 is the state we ship topics in.
When a new topic is created by Foswiki it managed the TOPICINFO and inserts the correct username in the TOPICINFO. However a topic generated outside Foswiki could have anything in the TOPICINFO. It can't be trusted. Rather than risk the topic being wrongly attributed to whoever happens to be in the TOPICINFO when such a topic is created, I elected to ignore the TOPICINFO in case 1, and assign the topic to UnknownUser instead, as that reflects the system's view of the topic more accurately (as well as skipping the requirement to read the topic).
Similarly the date in the TOPICINFO is ignored and the date used is the system date.
I grant that no-history is a special case. We can modify the behaviour to respect TOPICINFO for a no-history topic with minimal impact.
--
CrawfordCurrie - 09 Oct 2011