You are here: Foswiki>Tasks Web>Item12770 (24 Jun 2014, GeorgeClark)Edit Attach

Item12770: Formatted search attaches wrong webname prefix to output variables

Priority: Normal
Current State: Duplicate
Released In: 1.2.0
Target Release: minor
Applies To: Engine
Branches: trunk
Reported By: VickiBrown
Waiting For: VickiBrown
Last Change By: GeorgeClark
I maintain a Shared web with topics that are INCLUDEd into other webs. One such topic produces a tabular topic list with last edit date, parent, author...

The included code is

%TABLE{ headercolor="#000000" sort="on" }%
| *Topic* | *Parent* | *Created By* | *Last Modified* |
%SEARCH{ ".*" scope="topic" web="%INCLUDINGWEB%" type="regex" 
   nosearch="on" noheader="on" order="modified" reverse="on"
   format="| [[$web.$topic][$percntSPACEOUT{$topic}$percnt]] | $parent | $createwikiname | $date |" }%

When this is INCLUDEd into, e.g. my Vicki web, I should see something like this (expected):

Item12770 expected.png

Instead, I see this (actual):

Item12770 actual.png

The Search is returning the wrong web prefix for the $parent and $createwikiname variables. It should be using the web as specified in the web= parameter.

-- VickiBrown - 10 Mar 2014

The $createwikiname is working as documented. It returns the unqualified WikiName. To get the fully qualified name, use $createwikiusername

Also $parent is working as documented. It returns just the parent topic name. To qualify it, use $web.$parent. However you'll probably want to use a %IF to only expand the $web if $parent is non-blank.

It might seem to make sense that these should all return fully qualified topic names, but there are other applications where someone might really only want the parent topic name, or creator's user name.

-- GeorgeClark - 31 May 2014

Um... Shared.VickiBrown isn't an unqualified wikiname. It's an (incorrectly) qualitifed wikiname smile The "I should see" shows an unqualified name, which is, as you point out, what I should see. (But don't)

Similarly, as you point out $parent should return just the parent topic name. It doesn't (in the INCLUDED code).

George - you're repeating the bug description back to me. Look at the screenshots headers more carefully. (I added some bolding to the initial report to make it stand out more. smile

'>> It might seem to make sense that these should all return fully qualified topic names

No, it wouldn't; if I wanted fully qualified names, I'd ask for them. That's the point of this report. They shouldn't, but they appear to be (and the apparently fully qualified names are incorrect.)

-- VickiBrown - 31 May 2014

Okay. you are right. These are completely bogus expansions. The autolinking in my test case was throwing me off here. Expanding your test inside <noautolink> tags makes it obvious that they are wrong.

Setting this to confirmed. I've also recreated it on Foswiki 1.2. I'll mark it urgent so it has a chance of getting looked at for 1.2.

-- GeorgeClark - 31 May 2014

This does not appear to be a search bug. Search is doing the right think and returns an unqualified $createwikiname and $parent. You can prove this by putting the <noautolink> tags into the included topic surrounding the search. (Debug print's prove that search returns unqualified names). Here are trace results from Meta::getRev1Info() and the search format token expansion for $createwikiname
Meta: getRev1Info RETURNS WikiGuest 
2: ntopics | [[Litterbox.TheTopic][$percntSPACEOUT{TheTopic}$percnt]] | $parent | WikiGuest | 01 Jan 1970 - 00:02 |

So the bug? appears to be in the expansion of the %INCLUDE itself. Even with a noautolink around the including topic, the included topic gets expanded in the context of the included web.

I'm not sure if this is a bug or a side effect of includes working as designed. It's important that autolinking of wikiwords be done in the context of the included web, or they would be wrong. Since the include expands in the context of the included web, and doesn't specify noautolink, wikiwords are expanded in place. The more I ponder this, I don't believe it's a bug. Add <noautolink> tags surrounding either the entire search or around the individual $parent and $createwikiname fields and see if that works for you.

Other than that, if we change include to not expand wikiwords, I suspect we'd break a lot of things. Changed it back to Normal priority.

-- GeorgeClark - 31 May 2014

'>> So the bug? appears to be in the expansion of the %INCLUDE itself.


I say it's a bug somewhere because two variables that are supposed to hold and provide unqualified values are instead providing not only qualified values but incorrectly qualified values. (There is no Shared.PhotoAlbums. There is no Shared.VickiBrown. Those supposed topics do not exist. That's a bug.)

That... and the fact that the bug doesn't occur in TWiki 6. smile

-- VickiBrown - 31 May 2014

(FYI, is the exact same test page under Foswiki. Same files on the back end. I share data directories between TWIki and Foswiki instances. smile

-- VickiBrown - 31 May 2014

(FYI, I run noautolink by default. )

-- VickiBrown - 31 May 2014

In trying to debug this, could you add a <noautolink> tags surrounding the search in the topic that you include? I was able to recreate and then solve your issue by doing that. How do you set noautolink? By preference variable? Set in WebPreferences, User settings? Topic setting?

I suspect that maybe the INCLUDE macro is not honouring however you are setting noautolink.

So another thing to check is to use the INCLUDE without the search, just give it a wikiword to not autolink. If we can reduce this to a very simple case, and add a unit test to so we can fix it and make sure it never comes back.

-- GeorgeClark - 31 May 2014

Is this a duplicate of Item10949

-- GeorgeClark - 01 Jun 2014

This is definitely a dup of Item10949, and I have a fix. Unfortunately I am stumped trying to get the Unit Tests to set & pass along the NOAUTOLINK preference.

I'm checking in the fix anyway against both tasks, along with a unit test that will fail.

-- GeorgeClark - 01 Jun 2014

ItemTemplate edit

Summary Formatted search attaches wrong webname prefix to output variables
ReportedBy VickiBrown
Codebase 1.1.9
SVN Range
AppliesTo Engine
Priority Normal
CurrentState Duplicate
WaitingFor VickiBrown
Checkins distro:8bd9e8b3211a
TargetRelease minor
ReleasedIn 1.2.0
CheckinsOnBranches trunk
trunkCheckins distro:8bd9e8b3211a
I Attachment Action Size Date Who Comment
Item12770_actual.pngpng Item12770_actual.png manage 59 K 10 Mar 2014 - 21:00 VickiBrown screenshot - actual results
Item12770_expected.pngpng Item12770_expected.png manage 53 K 10 Mar 2014 - 21:00 VickiBrown Screenshot - expected results
Topic revision: r11 - 24 Jun 2014, GeorgeClark
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy