Item14494: PlainFileStoreContrib shows ProjectContributor as UnknownUser

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

Commenting is disabled while not logged in