Gostaria de tirar algumas dúvidas sobre vtex io B2B, em uma das documentações da vtex para lojas B2B, é informado sobre colocar a regra approved=true na política comercial, para travar usuários não aprovados. Isso funciona bem, porém se tento acessar a página de produto, recebo erro, como se fosse erro de busca. Sendo assim, seguem as dúvidas:
É possível exibir o produto com preço oculto nativamente mesmo utilizando a regra de approved=true na política comercial ou somente removendo e ocultando o preço do produto para usuários sem autenticação/aprovação no masterdata, via script?
Além disso, se tiver que remover a regra na política comercial, teria que usar a api do masterdata e filtrar o usuário logado e ver a coluna approved ou somente usando a biblioteca “vtex.session-client” eu já consigo?
Por último, o usuário tem a opção de se logar com chave enviada no e-mail, ao invés de preencher um pré cadastro (no vtex legado, todos os usuários deslogados eram levados para a rota /401, precisando preencher um formulário para se cadastrar e aguardarem a aprovação e depois de liberados, poderiam seguir com as compras). Penso em abrir um modal quando ele tentar clicar no produto e personalizar o menu do site na área de login/registro, qual a melhor forma de fazer isso?
Exibição de Produto com Preço Oculto Usando approved=true:
Quando você utiliza a regra approved=true na política comercial, a intenção é bloquear o acesso de usuários não aprovados a determinadas áreas da loja. O erro que você está recebendo ao acessar a página de produto pode estar relacionado à maneira como a política está configurada ou como a VTEX está tratando a lógica de busca.
Para exibir o produto com o preço oculto, você teria que remover a regra approved=true da política comercial. Em seguida, você pode utilizar um script customizado para ocultar o preço. Esse script pode verificar o status do usuário no Master Data e ocultar o preço se ele não estiver aprovado. Este é um método comum, mas requer desenvolvimento customizado.
Uso da API do Master Data vs. vtex.session-client:
Se você optar por remover a regra da política comercial, você pode usar a API do Master Data para verificar se o usuário está aprovado. Outra opção é usar a biblioteca vtex.session-client, que permite acessar informações da sessão do usuário, incluindo dados customizados do Master Data, como a coluna approved.
A vantagem de usar vtex.session-client é que ele já lida com a sessão do usuário e pode ser mais fácil de integrar ao seu código, especialmente em scripts front-end.
Personalização do Login/Registro com Modal:
Para a personalização do login/registro com a exibição de um modal, você pode utilizar as funcionalidades nativas do VTEX IO, combinadas com o desenvolvimento customizado.
Você pode criar um modal que é exibido quando o usuário não aprovado tenta acessar a página de produto. Este modal pode ser configurado para mostrar opções de login ou registro.
Outra abordagem é usar o vtex.modal-layout para facilitar a criação de modais customizados diretamente no front-end, e ajustar o comportamento do menu de login/registro usando JavaScript.
OBSERVAÇÕES GERAIS
A VTEX não recomenda customizações na loja e nem dá suporte caso isso cause algum problema no futuro. Portanto, estar ciente de que fique por conta e risco, mesmo que seja possível executar algumas modificações que não são nativas.
1. Manutenção e Atualizações:
Observação: Se você optar por ocultar preços via script customizado, lembre-se que qualquer atualização na VTEX IO ou na estrutura do front-end pode exigir ajustes no script.
Risco: Atualizações na plataforma podem quebrar a lógica implementada, resultando em exibição incorreta dos preços ou problemas de desempenho.
2. Dependência do Master Data:
Observação: Ao utilizar o Master Data para verificar o status do usuário (aprovado ou não), há uma dependência direta dessa API para carregar as informações corretamente.
Risco: Se o Master Data enfrentar problemas de performance ou disponibilidade, pode haver lentidão ou falhas na exibição de preços e controle de acesso, afetando a experiência do usuário.
3. Experiência do Usuário:
Observação: A exibição de um modal para login/registro pode ser eficaz, mas deve ser implementada de forma que não frustre o usuário. O modal deve ser rápido e claro, com opções visíveis e fáceis de entender.
Risco: Se o modal for intrusivo ou não funcionar corretamente (ex.: não carregar, travar o fluxo de navegação), isso pode resultar em uma alta taxa de abandono e uma má experiência para o usuário.
4. Segurança:
Observação: Garantir que os preços estejam realmente ocultos para usuários não aprovados é crucial. A lógica de ocultação deve ser segura e não apenas baseada em controle visual (CSS), mas sim no controle de acesso a dados.
Risco: Se a ocultação for mal implementada, usuários não aprovados poderiam visualizar os preços inspecionando o código-fonte ou fazendo requisições diretas à API, comprometendo a estratégia de precificação.
5. Performance e Escalabilidade:
Observação: Scripts customizados, especialmente aqueles que fazem verificações em tempo real com o Master Data, podem impactar a performance da página, especialmente em cenários com muitos usuários simultâneos.
Risco: Alto tempo de resposta ou sobrecarga do servidor pode afetar a escalabilidade da solução, levando a problemas de lentidão ou até mesmo falhas na loja em momentos de alta demanda.
6. Legibilidade e Manutenção de Código:
Observação: Ao adicionar scripts customizados e lógica específica, a complexidade do código pode aumentar, dificultando a manutenção futura.
Risco: Se a equipe responsável pela manutenção do código não estiver bem familiarizada com as customizações feitas, pode haver dificuldades em aplicar correções ou melhorias, o que pode aumentar o custo de manutenção e o tempo de resposta a problemas.
7. Compliance e Políticas de Privacidade:
Observação: O uso de dados do Master Data e a manipulação de sessões de usuário devem estar em conformidade com as políticas de privacidade e regulamentos aplicáveis (como LGPD, GDPR, etc.).
Risco: Um manuseio inadequado de dados sensíveis pode levar a violações de privacidade e problemas legais, além de impactar negativamente a confiança dos clientes na sua loja.
8. Consistência da Experiência em Diferentes Dispositivos:
Observação: Certifique-se de que as soluções implementadas funcionem consistentemente em diferentes dispositivos (desktop, mobile, tablet).
Risco: Diferenças no comportamento entre dispositivos podem causar frustração no usuário, levando a uma experiência inconsistente.
Ola Estevão, tudo bem? Uma dúvida, no item 1 terceiro bullet point, você menciona que o approved=true deve ser removido e um script deve ser gerado para ocultar o preço. Mas e neste caso, as configurações de permissão de interface do usuário não seriam exatamente essa configuração de quais blocos/ itens na tela o usuário pode ver dado sua permissão de acesso?
Sim, faz sentido. Eu deixei alguns possíveis caminhos que pode existir para configurar este tipo de customizalão.
No caso, sabemos que as configurações de permissão de interface do usuário são fundamentais para determinar quais blocos ou itens na tela um usuário pode ver, com base nas permissões de acesso atribuídas. No entanto, quando estamos lidando com a ocultação de preços para usuários não aprovados, o controle pode exigir uma abordagem dupla:
Configurações de Permissão: O recurso de permissão da VTEX pode ser usado para gerenciar quais partes do site são visíveis para diferentes grupos de usuários. Isso pode incluir o controle sobre blocos específicos que exibem preços. Nesse cenário, você definiria as permissões de usuário para garantir que apenas usuários aprovados vejam o bloco de preço.
ou
Controle por Script: Adicionalmente, para garantir uma camada extra de segurança ou personalização, você pode usar scripts personalizados que verificam a aprovação do usuário e, com base nessa verificação, ocultam ou exibem o preço. O uso do script é especialmente útil se você precisar de uma lógica mais complexa ou se as permissões padrão não forem suficientemente granulares para atender às suas necessidades.
Por exemplo, ao remover approved=true e utilizar um script para controlar a exibição do preço, você garante que o preço não seja exibido mesmo em cenários onde as permissões de interface possam falhar ou não se aplicarem adequadamente. Isso pode ser útil para garantir que apenas usuários totalmente verificados (por exemplo, aqueles que passaram por processos de aprovação extra) possam ver os preços.
Em suma: sim, as configurações de permissão são uma parte essencial para controlar o que o usuário pode ver na interface, mas a adição de scripts pode oferecer um controle mais refinado e segurança adicional para a exibição de preços.
Outras observações: já atuei em projetos onde precisou ter uma customização a mais por conta da regra de negócio do cliente. Ou seja, somente o que tem na versão nativa não foi suficiente.