OFBiz
  1. OFBiz
  2. OFBIZ-4755

E-commerce search does not always functioning correctly

    Details

    • Type: Bug Bug
    • Status: Patch Available
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      There seems to be a number of problems with the way e-commerce search works. I'll just a name a few examples of things I have tried that don't seem to work the way I think they should. I can delete a catalog from a store and the catalog still shows up and is completely searchable. I can delete a part from a catalog, then search the catalog and it still shows up, if you click the part from the search results you get a NullPointerException error. To take things a step further, after deleting the main catalog from the web store, I changed it to View Allow instead of Browse Root, then I even changed every category within the catalog to internal and search still finds parts from that catalog. Then I created a new catalog and category and put a product within. From here I can drill down to the part from the newly created catalog, but when I click on the part for details, it still directs me to the other catalog!

      1. ecommerceSearch2.patch
        0.7 kB
        Jeremy Olmstead
      2. ecommerceSearch1.patch
        0.7 kB
        Jeremy Olmstead

        Activity

        Hide
        Jeremy Olmstead added a comment -

        Okay, that is perfectly logical. I tried it exactly as you suggested, but still can't get it to work. It's odd because as soon as I set parameters.SEARCH_CATALOG_ID from within KeywordSearch.groovy, I print out a debug message that shows it has been set correctly. Immediately following this is the call to processSearchParameters, but a debug message in this Java method shows that SEARCH_CATALOG_ID is not a part of parameters! Any idea what I could be missing here?

        Thanks,
        Jeremy

        Show
        Jeremy Olmstead added a comment - Okay, that is perfectly logical. I tried it exactly as you suggested, but still can't get it to work. It's odd because as soon as I set parameters.SEARCH_CATALOG_ID from within KeywordSearch.groovy, I print out a debug message that shows it has been set correctly. Immediately following this is the call to processSearchParameters, but a debug message in this Java method shows that SEARCH_CATALOG_ID is not a part of parameters! Any idea what I could be missing here? Thanks, Jeremy
        Hide
        Scott Gray added a comment -

        Your patch includes the catalog using currentCatalogId which is sourced from a call to "CatalogWorker.getCurrentCatalogId(request);"
        There is no reason whatsoever why that same method can't be used to source the catalog id AFTER the form is submitted.

        In KeywordSearch.groovy just change:

        ProductSearchSession.processSearchParameters(parameters, request);
        prodCatalogId = CatalogWorker.getCurrentCatalogId(request);
        result = ProductSearchSession.getProductSearchResult(request, delegator, prodCatalogId);
        

        to

        prodCatalogId = CatalogWorker.getCurrentCatalogId(request);
        parameters.SEARCH_CATALOG_ID = prodCatalogId
        ProductSearchSession.processSearchParameters(parameters, request);
        result = ProductSearchSession.getProductSearchResult(request, delegator, prodCatalogId);
        

        Voila, no need to pass it through the form and no risk of exposing products from private catalogs.

        Show
        Scott Gray added a comment - Your patch includes the catalog using currentCatalogId which is sourced from a call to "CatalogWorker.getCurrentCatalogId(request);" There is no reason whatsoever why that same method can't be used to source the catalog id AFTER the form is submitted. In KeywordSearch.groovy just change: ProductSearchSession.processSearchParameters(parameters, request); prodCatalogId = CatalogWorker.getCurrentCatalogId(request); result = ProductSearchSession.getProductSearchResult(request, delegator, prodCatalogId); to prodCatalogId = CatalogWorker.getCurrentCatalogId(request); parameters.SEARCH_CATALOG_ID = prodCatalogId ProductSearchSession.processSearchParameters(parameters, request); result = ProductSearchSession.getProductSearchResult(request, delegator, prodCatalogId); Voila, no need to pass it through the form and no risk of exposing products from private catalogs.
        Hide
        Jeremy Olmstead added a comment -

        The search is its own little form within the page and catalog id was not part of the form. Adding the SEARCH_CATALOG_ID field makes it part of the form so that when the search is submitted the catalog is known. Before applying this patch the catalog was not known when the search form was submitted. As an example, try this: go to the demo front end store http://demo-trunk.ofbiz.apache.org/ecommerce/control/main. Change the catalog from default to test (default in this case works as expected, but test does not). Now search for Cap (this is a product which is in the Rental Catalog and should not be available on the main site). You get a hit because the keywordsearchbox.ftl had no idea what catalog to search and therefore searched all catalogs regardless. From here if you click the link to the detail page you get a NullPointerException.

        Show
        Jeremy Olmstead added a comment - The search is its own little form within the page and catalog id was not part of the form. Adding the SEARCH_CATALOG_ID field makes it part of the form so that when the search is submitted the catalog is known. Before applying this patch the catalog was not known when the search form was submitted. As an example, try this: go to the demo front end store http://demo-trunk.ofbiz.apache.org/ecommerce/control/main . Change the catalog from default to test (default in this case works as expected, but test does not). Now search for Cap (this is a product which is in the Rental Catalog and should not be available on the main site). You get a hit because the keywordsearchbox.ftl had no idea what catalog to search and therefore searched all catalogs regardless. From here if you click the link to the detail page you get a NullPointerException.
        Hide
        Scott Gray added a comment -

        (Keeping in mind I haven't looked at the code)

        We seem to know which catalog to search when rendering the form. Why do we need to pass it through the form in order to figure it out after submission?

        At the very least the post-submission logic should verify that the catalog is attached to the current product store.

        Show
        Scott Gray added a comment - (Keeping in mind I haven't looked at the code) We seem to know which catalog to search when rendering the form. Why do we need to pass it through the form in order to figure it out after submission? At the very least the post-submission logic should verify that the catalog is attached to the current product store.
        Hide
        Jeremy Olmstead added a comment -

        I separated the patches into two. I agree with what you are saying, but still think that the hidden SEARCH_CATALOG_ID should be a part of the solution. How else is the site going to know which catalog to search? We need something more, of course, to address what happens when either no catalog is specified or when a catalog is specified that either doesn't exist or is, as in my case, private.

        Show
        Jeremy Olmstead added a comment - I separated the patches into two. I agree with what you are saying, but still think that the hidden SEARCH_CATALOG_ID should be a part of the solution. How else is the site going to know which catalog to search? We need something more, of course, to address what happens when either no catalog is specified or when a catalog is specified that either doesn't exist or is, as in my case, private.
        Hide
        Scott Gray added a comment -

        Hidden inputs aren't the way to solve this, it would be trivial for a user to change the value and expose products that shouldn't be searched.

        Also, it's better to fix one problem per patch.

        Show
        Scott Gray added a comment - Hidden inputs aren't the way to solve this, it would be trivial for a user to change the value and expose products that shouldn't be searched. Also, it's better to fix one problem per patch.
        Hide
        Jeremy Olmstead added a comment -

        Heidi, could you try the attached patch to see if it resolves your issue? Also, be sure you have a search category linked to your catalog with all products you want searchable in there. I setup a search category linked to my "internal" catalog with nothing in it and, with the patch, everything seems to work the way I was expecting.

        Show
        Jeremy Olmstead added a comment - Heidi, could you try the attached patch to see if it resolves your issue? Also, be sure you have a search category linked to your catalog with all products you want searchable in there. I setup a search category linked to my "internal" catalog with nothing in it and, with the patch, everything seems to work the way I was expecting.
        Hide
        Jeremy Olmstead added a comment -

        I have found two things that I believe are a problem with the search and the patch I uploaded seems to resolve the issues I was having. The first problem is that the eCommerce site does not filter by catalog. You could search any catalog and potentially get product to show up in your search from the main catalog whether you wanted them to or not. Adding a hidden SEARCH_CATALOG_ID to the keywordsearchbox.ftl file fixed this. The other problem was when you clicked a link to a product detail page and did not have a specific category specified, it would end up defaulting to the products "primary category" even if that primary category was in a catalog you didn't want visible on the web. By eliminating the primary category selection in productdetail.groovy, it seemed to then default to the desired category in my cases.

        Show
        Jeremy Olmstead added a comment - I have found two things that I believe are a problem with the search and the patch I uploaded seems to resolve the issues I was having. The first problem is that the eCommerce site does not filter by catalog. You could search any catalog and potentially get product to show up in your search from the main catalog whether you wanted them to or not. Adding a hidden SEARCH_CATALOG_ID to the keywordsearchbox.ftl file fixed this. The other problem was when you clicked a link to a product detail page and did not have a specific category specified, it would end up defaulting to the products "primary category" even if that primary category was in a catalog you didn't want visible on the web. By eliminating the primary category selection in productdetail.groovy, it seemed to then default to the desired category in my cases.
        Hide
        Heidi Dehaes added a comment -

        Also when searching a product which is the ONLY member of a separate search category (category of type search category) , only that product may show up. Which is not the case. All products are showing up.
        The use of a search category should work also for normal search as for advanced search.

        Show
        Heidi Dehaes added a comment - Also when searching a product which is the ONLY member of a separate search category (category of type search category) , only that product may show up. Which is not the case. All products are showing up. The use of a search category should work also for normal search as for advanced search.

          People

          • Assignee:
            Unassigned
            Reporter:
            Jeremy Olmstead
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development