nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Problem on Pure Metadata Search

jman

For pure metadata search (in Advanced Search) which do not need Indexer running. I assume it would be some kind of SQL/Database search but the result is very strange, the customer told me that search word not at the beginning of the metadata field cannot be found. The customer consider this as a very serious problem as it cannot work in a very basic way.

For example, there are 2 tasks with the following names,

"Important Overview"
"John's Demo - Important Overview"

When searching the task with name "Important", only the task "Important Overview" is returned.

When searching the task with name "Overview", no task is returned.

Any idea?

Thanks,
John

Find more posts tagged with

Comments

Migrateduser

Are you using HFB7?

Can you please try using a wild character (*) in front of the search text? The profile (database) search works differently from the full text search. The differences are explained in the online help for HFB7, I guess.

jman

Yes, it's HFB7.

I've checked the on-line help, it doesn't mention anything about putting a wildcard, anyway, I've tested it again by putting the wildward character in front of the search word but doesn't help.

In the HFB7 release note, it seems this is a known issue [38558] "Users cannot perform an exact text search for text-based metadata fields.", the resolution is "Users can now specify an exact search for text-based metadata fields by enclosing the text of a query in double quotes."

However, I tried the above by using the double quotes ("), but still doesn't work.

Any idea?

John

Nicholas

Try * with ", just a guess

Migrateduser

jman,

I checked deeper in the code. Please use % as the wild character in the property searches. In your example, %important% should return the expected results.

Sorry about the previous incorrect response; I really thought * was the wild character (in fact this was the customization made for a customer in a custom search connector, it never made to the main produt line).

jman

Hi Bijoy,

Thanks, it works.

Can you explain the meaning and purpoose of the "%" character?

Besides, although it works, customers may found it a bit strange to add such a character in order to get the expected result. Any reason to communicate to customer why WSMP is having such a search behaviour?

John

Migrateduser

It would not be surprise to many programmers as % is the wild character in SQL queries. So the server team maintained this in their apis. Clients should have mapped this to *; it really a nice to have. We will try to get it in 5.0