Item1611: Query search with defined form name misses forms which are included as Web.FormName

Description

When a DataForm (call it TestForm for now...) is enabled (e.g. in WebPreferences) by writing it with the web prefix, e.g.

   * Set WEBFORMS = Myweb.TestForm

then topics which include this form will be ignored when doing a query search like this:

%SEARCH{
type="query"
"TestForm"
nonoise="on"
format="   * $web.$topic"
}%

Changing the META tag from Myweb.TestForm to TestForm will make this topic visible for the query search.

This is not how I feel it should be since

• Myweb.TestForm and TestForm are equivalent regarding the wiki syntax
• a user would have to check the spelling in the WEBFORMS definition
• even if the WEBFORMS definition is correct, there might be older topics which have an "outdated" META tag featuring the web prefix

By the way: I could not manage to do a query on Myweb.TestForm, since the "." has a different meaning in a query search. Is it generally possible to do that?

-- PhilippLeufke - 10 May 2009

The primary problem is not the definition of WEBFORMS, but the string put into every topic instance on the META:FORM line. I suggest to use form.name ~ '*TestForm' as a workaround.

Myweb.TestForm and TestForm are equivalent only in the scope of the current web. There may be more TestForms in other webs.

-- OliverKrueger - 15 May 2009

This is a bug I would like to see fixed.

I suddenly understand why some things I tried two months ago did not work.

Elevating to urgent.

I tried to find the place where the code does the actual search but the search code has been split all over the place - I do not understand where to begin and where to end. In which exact file does the search for form name happen???

-- KennethLavrsen - 17 May 2009

I appreciate a clarification in the META:FORM line (always use a fully qualified name here).

What would an unqualified query find, if you have Web1.MyForm and Web2.MyForm? I have such scenarios in my installations, although I havent registered two MyForms in the same web.

-- OliverKrueger - 17 May 2009

As with so many things, it's not a bug, it's the side-effect of a feature. Whoever designed the forms elected to put an unqualified topic name into META:FORM, and this has stuck around for a long, long time.

Obviously the form name should be a fully qualified web name; it's so obvious, that you would have to be a complete numpty to think otherwise. Unfortunately, in most cases it isn't. Further, because of the legacy of unqualified names, searches that depend on the name being unqualified exist in many places.

So, what to do? Here are the choices:

1. Do nothing.
2. Munge the query, in some god-awful, unsupportable, inefficient way, so that it matches both qualified and unqualified names, even though the caller didn't ask it to.
3. Fully qualify the form name in the META:FORM, by fully resolving it when a topic is loaded. Thus when the topic is saved, the fully qualified name is saved. However, many existing searches will stop working.

When I was faced with this choice before, I picked (1) to avoid the usual compatibility-existing-topics-corporate-firewall-twiki-never-changes arguments. You can probably tell that I think (2) is a stupid idea. (3) is fractionally better, but doesn't answer the requirement when searching over legacy topics.

BTW this issue has been around since we used regexes to search meta-data. I think making it Urgent is an over-reaction.

-- CrawfordCurrie - 29 May 2009

Or (4): Do the same as in (3) but make SEARCH a little bit smarter. If the query in not fully qualified and there is no ambiguity site-wide, ignore the web part in the topics.

Personally I would still perfer (3), cause (4) motivates people to create bad queries.

-- OliverKrueger - 30 May 2009

Urgent puts attention on a bug. But if the fix is not obvious or could have side effects - it is better to wait and think it through.

Lowering to Normal again.

Is there a 1-liner docu thing we can do to aid the app developer given the current behaviour? It may make sense to declare the feature as working as designed and document precisely what the app developers should do if he has a mix of formnames with and without webname.

Let me look at that. Maybe we just close the bug with a docu update. For sure the side effects given for ALL the suggested fixes give me goosebumps.

-- KennethLavrsen - 16 Jun 2009

Regarding the workaround mentioned above with using wildcards ( form.name ~ '*TestForm' ). But what would it look like for querying a specific formfield, i.e. TestForm[name='Status'].value='good' ?

-- PhilippLeufke - 06 Jul 2009

• Simply: Status = 'good'

-- OliverKrueger - 07 Jul 2009

I understand so far, but if I want the Status = 'good' to be checked only in TestForm (and not all the other forms where a Status field is present), I only see the workaround using an AND:

• "form.name ~ '*TestForm' AND Status = 'good'"

Any other way of using wildcards with the TestForm[name='Status'].value='good' expression?

-- PhilippLeufke - 08 Jul 2009

Since there can be only one form attached to a topic at a time, I always use:

• "form.name ~ '*TestForm' AND Status = 'good'"

(We should probably move this discussion to a Support Item. On this topic we should discuss the need for a change of the default behaviour for incomplete form names.)

-- OliverKrueger - 08 Jul 2009