3 weeks ago
I have this requirement:
the products included into a set of given categories must be visible only to a specific userGroup. Users that don't have the specific userGroup can't see the categories and the products included into those categories.
so, I have a category (e.g. monitor_&_TV) visible only to the a single userGroup (e.g. mediaCustomerGroup).
After added the mediaCustomerGroup to general>Category Visibility>'visible to' list of the category monitor_&_TV and activated the searchRestriction 'Frontend_RestrictedCategory' (as suggested here https://help.sap.com/docs/SAP_COMMERCE_CLOUD_PUBLIC_CLOUD/7e47d40a176d48ba914b50957d003804/8c5b1eb58... ) the category page return 404 for the user that don't are present into the 'visible to' list. This is perfect, it's exactly what I want, but this is only a portion of my requirements.
The problems are:
How can I hide the products?
For resolve the 1st, I tried to write the restriction (following the existing 'Frontend_RestrictedCategory' logic) below but it works the other way around... so, I'm a little bit confused. How it's possible that the restriction works fine for the categories but not for the product?
INSERT_UPDATE SearchRestriction ; code[unique=true] ; principal(uid)[unique=true] ; query ; restrictedType(code)[unique=true] ; active ; generate
; Frontend_RestrictedProduct ; customergroup ; Exists ({{select {c2ug:pk} from {CategoryProductRelation as c2p JOIN Category2PrincipalRelation as c2ug on {c2p:source}={c2ug:source}} where {c2p:source}={item:pk} AND {c2ug:target} IN ( ?session.user, ?session.user.allGroups )}}); Product ; TRUE ; true
Solution for solr ?
Request clarification before answering.
I suggest investigating the feature Product Visibility Based on Category and Catalog Version, introduced in version 2211.32. (I’m not sure which version of 2205 includes this feature.) In the documentation, look for Enabling Product Visibility Based on Category with Solr to understand how to achieve your goal with Solr.
Regarding your question, 'How is it possible that the restriction works fine for the categories but not for the product?', my answer would be that restricting the visibility of products is not straightforward. This is because searching all the categories of a product is challenging with a query, as there may be multiple levels of categories. Let me explain this with an example:
Assume the category hierarchy of a product is as follows: C1 > C2 > C3 > C4 > P1.
If you want to restrict C2 or C3 instead of C4, you would need to traverse the category hierarchy of the product to make the restriction work. To do this, you’d need two additional JOINs in your query with the CategoryCategoryRelation table. Furthermore, since the category hierarchy might be dynamic—meaning that some products may have 3 levels while others have 5, depending on your catalog—it becomes difficult to implement restriction logic with a simple query.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
hi @mansurarisoy, I will study the solr part, thanks a lot. About the visibility of products depending on categories, I'm not agree with you for a simple reason: when you set (using your example) the visibility on C2, the visibility is applied recursively on children categories (after you add the user group in 'visibility to' on c2, the same usergroup is added on C3 and C4, you just need to synchronize, this stuff works).
Also, I forgot to write on my post that my restriction (Frontend_RestrictedProduct) works in the opposite way (it redirect to 404 when a mediaCustomerGroup user try to open product page of a product, product child of monitor_&_TV category). So, basically, my idea is correct, probably I'm lost on the 'where' (or on the relations) of the query.
For be more clear (and using your example):
C1 > C2 > C3 > C4 > P1
U1, U2, aU (aU = anonymous user)
U1 element of UG1
C2 visible to UG1
C1 (no limitation on 'visibility to'): visible to all
C2 (manually added UG1 to 'visibility to'): visible only to Ui where Ui are element of UG1 (category page is hide, it works)
C3 and C4 (they inherit the UG1): visible only to Ui where Ui are element of UG1 (category pages for C3 and C4 are hide, it works)
P1 (my expectation: Product page for P1 must be hide for U2 and aU, visible for U1; how it works OOTB: P1 is visible to all; OOTB + my_restriction: P1 is hide for U1 and visible to U2 and aU)
Yes, you’re absolutely right. It’s handled in the CategoryPrepareInterceptor; I missed that implementation. In this case, we should consider the note in the documentation: "Frontend restriction on category is deactivated by default for performance purposes." Even the current version of the restriction might cause performance degradation, so adding additional JOINs to the query could make things worse. I suggest thoroughly testing your changes to the restriction with regard to performance.
And for the query I think you should change {c2p:source}={item:pk} part to {c2p:target}={item:pk} since target side of the CategoryProductRelation is Product type. Your final restriction should be
EXISTS ({{select {c2ug:pk} from {CategoryProductRelation as c2p JOIN Category2PrincipalRelation as c2ug on {c2p:source}={c2ug:source}} where {c2p:target}={item:pk} AND {c2ug:target} IN ( ?session.user, ?session.user.allGroups )}})
Hi @mansurarisoy,
FYI, I reached all the goals following instruction on the documentation.
I'm able to restrict visibility of category page, product page and solr search adding 'visibility to' to categories, update 3 search restrictions and updating solr index (following the documentation that you linked).
I still have issues but them are caused by customisation written for my client.
So, it works, thanks a lot.
Hi @MarcoCoppola I’m glad to hear that it works for you! Thank you for letting me know the result—I truly appreciate it. Kindly accept my answer as the solution so that others know it’s achievable, and the community becomes more useful to everyone.
User | Count |
---|---|
18 | |
3 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.