During a recent deployment I was seeing some interesting behaviour in search scopes that were defined for custom objects. The key issue was that I could enter in a search parameter that would work fine for the object when I was already in the custom objects page but when called from the home page, the search parameter was ignored and all objects would be returned.
A bit of digging around with some coworkers found that the problem was associated with the URL that is provided for navigation from the home page. In most cases, the default URL that is used would be the one that you get when you first open that object type from the “All Resources” page. For example:
However, when the object was clicked the URL that would be formed using the base URL provided with the system added suffixes was:
Note how the searchtype parameter is prefixed by a ? indicating a second query string. The string appears to be lost in translation as the objects ALL show up and are not limited by the parameter I had entered in the search box (“testing” as indicated by the last part of the URL “content=testing”)
Modifying the home URL slightly (although it does make for an ugly URL) seemed to have made the environment work okay. The fix was to modify the URL such that the search scope was present and the string ended with an & to show another parameter. For example:
This results in a URL generated when doing the query that actually repeats the searchtype parameter in the string however, the second one that was appended with the leading question marks appears to be ignored and the query works okay. The resulting URL is:
Now that this change has been made, the system is working fine with the custom object searches returning scoped results based on the provided string in the search field from the home page.