Priority: Urgent
Current State: Confirmed
Released In: 2.2.0
Target Release: minor
Noticed that all the topics in my System web were displaying
UnknownUser in the revision info.
For example: Displaying "raw=all" for
System.WebHome
Store |
META:TOPICINFO |
PlainFileStore |
{author="BaseUserMapping_999" comment="" date="1506129583" format="1.1" version="1"} |
RcsLite |
{author="ProjectContributor" date="1457496285" format="1.1" version="1"} |
RcsWrap |
{author="ProjectContributor" date="1457496285" format="1.1" version="1"} |
Actual Meta |
{author="ProjectContributor" date="1457496285" format="1.1" version="1"} |
--
GeorgeClark - 23 Sep 2017
This has been confirmed at a live site that System web topics show
UnknownUser. If this is intended to work this way, is there something I need to do when building a release so that the files all have valid meta?
--
GeorgeClark - 23 Sep 2017
I think this is probably a function of the _saveDamage that is done when not history of the topic exists. If damage has to be saved, then it defaults to the unknown user rather than reading the existing meta-data. See then comment in
PlainFileStore.pm starting at line 1099 for the reasoning.
You could solve this by generating and shipping a history file, or by changing the logic in the
PlainFileStoreContrib, perhaps by modify line 1144 to:
. ($meta && $meta->{author} ? $meta-{author} : $Foswiki::Users::BaseUserMapping::UNKNOWN_USER_CUID
However that would end up with file modified by an external process being associated with the last author to modify that file in Foswiki, which may be undesireable. Perhaps
. ($meta && $meta->{author} && $meta->{author} eq 'ProjectContributor' ? $meta-{author} : $Foswiki::Users::BaseUserMapping::UNKNOWN_USER_CUID
would be the best compromise
--
Main.CrawfordCurrie - 23 Jan 2018 - 10:32
Unfortunately that patch doesn't help. The _saveDamage routine is called during topic or attachment save. The problem described above happens during topic read.
sub readTopic
sets the revision to 0 if there is no history. Then the block at line 176 ends up applying all the defaults.
# Patch up the revision info with defaults. If the latest
# file is more recent than the youngest history file, then
# use these defaults too.
I really don't understand why we can't trust the topic META when the history is missing.
- If the topic is newer than the history, and the history exists, then clearly the META text cannot be trusted.
- Replace stored META with the UnknownUser, rev= #revs+1, and file timestamp.
- But if the topic exists without any history at all:
- If .txt file timestamp
= META date
timestamp, then trust the META information.
- If .txt file timestamp < META data, then change to UnknownUser, file Timestamp, rev=1
The latter is a useful situation at least on RCS systems, where it makes sense to wipe out the history. It seems to me that the Plain File and RCS stores should have similar behavior when history has been removed.
--
GeorgeClark - 06 Feb 2018
The reason for not trusting the META was because an external agent editing the topic couldn't be trusted to correctly set the META. Not so much of an issue for the version, but an issue for the author as someone could end up being attributed with an edit they didn't perform.
--
Main.CrawfordCurrie - 07 Feb 2018 - 10:28