To test a restriction so that a product code was not visible on the front end site for apparel store (provided OOTB by Hybris), I made a restriction by going to BackOffice->Personalizatiopn and made a new personalization rule by giving the filter as :
{code} = '300392196'
And ApplyOn customerGroup
But still when I go to a site for my extension(mysitestorefront) like :
http://localhost:9001/mysitestorefront/?site=apparel-uk
I am able to search the product in "What You're looking for section".Am I doing some mistake in implementing the restriction?
Personalization apply to the direct flexible search query, but storefront search is based on Solr, it will make a query to Solr. All indexed products can be searched from the storefront. So if you restrict a product to be searched, then stop indexing it.
Which products should be indexed are defined by flexible search queries provided in full and update fields of your indexed type.
Go to HMC/BackOffice > System > Facet Search > Indexed Types > Select your indexed type > There you find full and update queries.
append your where clause (like where {code} != '300392196') to query and do full solr indexing
If you want to hide/show your product to the specific group based on some condition, then you can follow this steps
Related
In Azure Search you can boost a query by using first term || secondterm^2 to give more weight to a particular part of the query.
You can also filter for documents that belong to a particular group using search.in(): https://learn.microsoft.com/en-us/azure/search/search-query-odata-search-in-function
$filter=group_ids/any(g: search.in(g, '123, 456, 789'))
What I would like to do is boost a document if it belongs to a group but not restrict to only documents that belong to that group.
Something like:
search=mysearchterm^3&$filter=group_ids/any(g: search.in(g, '123, 456, 789'))^2
But (1) boosting on the filter doesn't seem to work and (2) this would restrict to only documents that belong to group 123,456,789. I would like it to only boost if it belongs, but not restrict to only those groups.
Is this possible?
I've had a look at "Tag Boosting": https://azure.microsoft.com/en-au/blog/personalizing-search-results-announcing-tag-boosting-in-azure-search/
But it doesn't seem relevant, it only seems possible to tag boost a top level string field, not a string or int field within a collection.
UPDATE:
I think i've figured it out as:
search=mysearchterm AND (group_id:123)^2
If you're using a complex collection it might be:
search=mysearchterm AND (groups/id:123)^2
Filters are designed to constrain your result set by filtering out documents that don't match the filter criteria. This process happens before term matching and scoring. Given that this is not what you are trying to do, I don't think filters are the right tools for the job.
You can try to instead craft a Lucene query that includes the logic you described:
mysearchterm OR (mysearchterm AND group_ids:(123 OR 456 OR 789))^2
I have many articles and each is assigned under different categories/subcategories.
What I'd like to do is at the end of individual article, I'll display a list of Related Articles based on the category(s) that the current article is placed. I've added a Repeater but don't really know what to put in Content Filter/Category Name to achieve this. Hope it's not so complex. Thanks for your input!
You can achieve this in Portal without touching the code if you need to. The following steps are how you can achieve it (though they are rough and ready!)
In your Article page type, create a new query. This queries job is going to be to link the existing Document to any others that share the exact same categories. Your query should look like this:
SELECT ##TOPN## ##COLUMNS##
FROM View_CMS_Tree_Joined rel
INNER JOIN CMS_DocumentCategory relcat ON relcat.DocumentID=rel.DocumentID
INNER JOIN CMS_DocumentCategory doccat ON relcat.CategoryID=doccat.CategoryID
WHERE ##WHERE##
AND rel.DocumentID doccat.DocumentID
ORDER BY ##ORDERBY##
Now, replace you Repeater with a Repeater with custom query. In the setting, choose your newly created query for the Query name field using the selector control.
Set the WHERE clause to be doccat.DocumentID={% CurrentDocument.DocumentID #%}
Pick the appropriate transformation and you should be good to go.
This method requires an exact category match, so Categories > Cars > Mazda will not match to Categories > Cars.
Hopefully this is of some use :)
This article may give you some idea on creating a filter, but I don't think this is exactly what you want. It does show you have to get the documents thru the API.
You could do a custom query, something like this
SELECT *
FROM dbo.View_CMS_Tree_Joined vctj
WHERE vctj.DocumentID IN
(
SELECT DocumentID
FROM CMS_DocumentCategory
WHERE CategoryID IN
(
SELECT CategoryID
FROM CMS_Category
WHERE dbo.CMS_Category.CategoryName = 'Name Here'
)
);
I am using solr for searching. I wants to improve my search result quality based on previously searched terms. Suppose, I have two products in my index with names 'Jewelry Crystal'(say it belongs to Group 1) & 'Compound Crystal'(say it belongs to Group 2). Now, if we query for 'Crystal', then both the products will come.
Let say, if I had previously searched for 'Jewelry Ornament', then I searches for 'Crystal', then I expects that only one result ('Jewelry Crystal') should come. There is no point of showing 'Compound Crystal' product to any person looking for jewelry type product.
Is there any way in SOLR to honour this kind of behavior or is there any other method to achieve this.
First of all, there's nothing built-in in Solr to achive this. What you need for this is some kind of user session, which is not supported by Solr, or a client side storage like a cookie or something for the preceding query.
But to achive the upvote you can use a runtime Boost Query.
Assuming you're using the edismax QueryParser, you can add the following to your Solr query:
q=Crystal&boost=bq:(Jewelry Ornament)
See http://wiki.apache.org/solr/ExtendedDisMax#bq_.28Boost_Query.29
How the search everything kind of application is indexing & keeping track of data into its search indexes.
Recently I have been working on Apache Solr which is producing amazing results for a search. But it was for one particular products catalog section that is being searched. As Solr is a stores it's data document, we indexed searchable fields as document in solr. I'm not sure how it can be used to build a search everything kind of search? And how should I index data into Solr?
By search everything I mean, to search into different module for information like Customers, Services, Accounts, Orders, Catalog, Support Ticket, etc. So search return results which is combined as a result from a single search form and user don't need to go into different forms for search that module?
Do I need to build different indexes for each such data models or store them into solr as single document? What is the best strategy to implement this.
You can store all that data in a single index with each document having an extra field that stores its type (Customer, Order, etc.). For the within-module search, just restrict the search query to documents of that type. For the Search All functionality, use copyField to copy all the relevant fields in each document type into one big field, and search with the document type field unconstrained.
Searching Magento with fulltext search engine and like method , it will store results in catalogsearch_fulltext table in "data_index" field where it stores value in the format like
each searchable attribute is separated with |.
e.g
3003|Enabled|None||Product name|1.99|yellow|0
here it store sku,status,tax class, product name , price ,color etc etc
It stores all searchable attribute value.
Now the issue is for Configurable product , it will also store the associated products name ,price ,status in the same field like
3003|Enabled|Enabled|Enabled|Enabled|None|None|None|None|Product name|Product name|associted Product name1|associted Product name2|associted Product name3|1.99|2.00|2.99|3.99|yellow|black|yellow|green|0|0|0|0
So what happen is if i search for any word from associated product, it will also list the main configurable product as it has the word in its "data_index" field.
Need some suggestion how can i avoid associated products being included in data_index, So that i can have perfect search result.
thanks
We are looking into our search as well and it has been surprising to see the inefficiencies included in the fulltext table. We have some configurable products as well that have MANY variations and their population in the fulltext search is downright horrendous.
As for solutions, I can only offer my approach to fix the problem (not completed: but rather in the process).
I am extending Magento to include an event listener to the process of indexing the products (Because catalog search indexing is when the fulltext database is populated). Once that process occurs, I am writing my own module to remove duplicate entries from the associated products and also to add the functionality of adding additional search keyword terms as populated from a CSV file.
This should effectively increase search speed dramatically and also return more relevent search results. Because as of now, configurable products are getting "search bias" in the search results.
This isn't so much of an answer as a comment, but it was too lengthy to fit in the comments but I thought this might be beneficial to you. Once I get my module working, if you would like, I can possibly give you directions on how you could implement a similar module yourself.
Hope that helped (if only for moral support in magento's search struggle)