I’d like to clear up a few questions about VTEX IO B2B. In one of VTEX’s B2B store documentation pages, it mentions adding the approved=true rule to the trade policy to block unapproved users. This works fine, but when I try to access a product page, I get an error, as if it were a search error. So, here are my questions:
Is it possible to display the product with a hidden price natively while still using the approved=true rule in the trade policy, or would it only be possible by removing and hiding the product price for unauthenticated/unapproved users in Master Data via script?
Also, if I have to remove the rule from the trade policy, would I need to use the Master Data API and filter by the logged-in user to check the approved column, or can I already get that just by using the “vtex.session-client” library?
Lastly, the user has the option to log in with a key sent by email, instead of filling out a pre-registration form (in legacy VTEX, all logged-out users were redirected to the /401 route, where they had to fill out a form to register, wait for approval, and only then proceed with purchases). I’m thinking of opening a modal when they try to click on a product and customizing the login/registration area in the site menu — what’s the best way to do this?
@caiquelins How’s it going? Let’s go through the points:
Displaying a Product with Hidden Price Using approved=true:
When you use the approved=true rule in the trade policy, the intention is to block unapproved users from accessing certain areas of the store. The error you’re getting when accessing the product page may be related to how the policy is configured or how VTEX is handling the search logic.
To display the product with a hidden price, you would need to remove the approved=true rule from the trade policy. You can then use a custom script to hide the price. This script can check the user’s status in Master Data and hide the price if they are not approved. This is a common method, but it requires custom development.
Using the Master Data API vs. vtex.session-client:
If you choose to remove the rule from the trade policy, you can use the Master Data API to check whether the user is approved. Another option is to use the vtex.session-client library, which lets you access user session information, including custom Master Data fields like the approved column.
The advantage of using vtex.session-client is that it already handles the user session and can be easier to integrate into your code, especially in front-end scripts.
Customizing Login/Registration with a Modal:
For customizing the login/registration flow with a modal, you can use VTEX IO’s native features combined with custom development.
You can create a modal that appears when an unapproved user tries to access the product page. This modal can be configured to show login or registration options.
Another approach is to use vtex.modal-layout to make it easier to build custom modals directly on the front-end, and adjust the login/registration menu behavior using JavaScript.
GENERAL NOTES
VTEX does not recommend store customizations and does not provide support if they cause issues down the line. So keep in mind that you proceed at your own risk, even if some non-native modifications are technically possible.
1. Maintenance and Updates:
Note: If you choose to hide prices via a custom script, keep in mind that any updates to VTEX IO or the front-end structure may require adjustments to the script.
Risk: Platform updates can break the implemented logic, resulting in incorrect price display or performance issues.
2. Dependency on Master Data:
Note: When using Master Data to check the user’s status (approved or not), there is a direct dependency on this API to load information correctly.
Risk: If Master Data experiences performance or availability issues, there may be slowdowns or failures in price display and access control, affecting the user experience.
3. User Experience:
Note: Displaying a modal for login/registration can be effective, but it must be implemented in a way that doesn’t frustrate the user. The modal should be fast and clear, with visible and easy-to-understand options.
Risk: If the modal is intrusive or doesn’t work correctly (e.g., fails to load, blocks the navigation flow), it can result in a high abandonment rate and a poor user experience.
4. Security:
Note: Making sure prices are truly hidden from unapproved users is crucial. The hiding logic must be secure and not rely solely on visual control (CSS), but rather on actual data access control.
Risk: If the hiding mechanism is poorly implemented, unapproved users could view prices by inspecting the source code or making direct API requests, compromising your pricing strategy.
5. Performance and Scalability:
Note: Custom scripts, especially those that perform real-time checks against Master Data, can impact page performance, particularly in scenarios with many simultaneous users.
Risk: High response times or server overload can affect the scalability of the solution, leading to slowdowns or even store failures during periods of high demand.
6. Code Readability and Maintainability:
Note: Adding custom scripts and specific logic can increase code complexity, making future maintenance more difficult.
Risk: If the team responsible for maintaining the code isn’t well familiar with the customizations made, applying fixes or improvements can become challenging, which may increase maintenance costs and response times to issues.
7. Compliance and Privacy Policies:
Note: The use of Master Data and manipulation of user sessions must comply with applicable privacy policies and regulations (such as LGPD, GDPR, etc.).
Risk: Improper handling of sensitive data can lead to privacy violations and legal issues, as well as negatively impacting customer trust in your store.
8. Consistency of Experience Across Devices:
Note: Make sure the implemented solutions work consistently across different devices (desktop, mobile, tablet).
Risk: Differences in behavior across devices can cause user frustration, leading to an inconsistent experience.
Hey Estevão, how’s it going? I have a question — in item 1, third bullet point, you mention that approved=true should be removed and a script should be generated to hide the price. But in that case, wouldn’t the Storefront Permissions UI settings be exactly that — the configuration of which blocks/items on the screen the user can see based on their access permissions?
Yeah, that makes sense. I left some possible paths that may exist for setting up this type of customization.
In this case, we know that user interface permission settings are key to determining which blocks or items on the screen a user can see, based on the access permissions assigned to them. However, when dealing with hiding prices for unapproved users, the control may require a dual approach:
Permission Settings: VTEX’s permission feature can be used to manage which parts of the site are visible to different user groups. This can include control over specific blocks that display prices. In this scenario, you would define user permissions to ensure that only approved users see the price block.
or
Script-Based Control: Additionally, to ensure an extra layer of security or customization, you can use custom scripts that check user approval and, based on that check, hide or display the price. Using a script is especially useful if you need more complex logic or if the default permissions aren’t granular enough to meet your needs.
For example, by removing approved=true and using a script to control price display, you ensure the price isn’t shown even in scenarios where interface permissions might fail or not apply properly. This can be useful for making sure only fully verified users (e.g., those who have gone through extra approval processes) can see prices.
In short: yes, permission settings are an essential part of controlling what the user can see in the interface, but adding scripts can offer more refined control and additional security for price display.
A few more thoughts: I’ve worked on projects where extra customization was needed due to the client’s business rules. In other words, what’s available out of the box in the native version just wasn’t enough.