Reportar um problema - Avisos de clientes na página do produto, links partidos e preços errados com painel

Os seus clientes encontram as páginas estragadas antes de si

Todo o catálogo se vai desgastando. Um link de fornecedor deixa de funcionar, fica um preço da época passada, uma descrição perde justamente o detalhe de que o comprador precisa. Quem repara nisso são os seus visitantes — e se não lhes der uma forma de o dizer, limitam-se a sair.

Este módulo coloca um discreto botão Reportar um problema em cada página de produto. Um clique abre uma janela, o visitante explica numa frase o que está errado, e o aviso aterra no seu back office.

Quatro tipos de problema e uma frase

O visitante escolhe entre link partido, preço errado, informação em falta e outro — é você que decide quais dos quatro oferecer — e escreve uma descrição curta, entre 10 e 1000 caracteres, com um contador ao vivo enquanto escreve.

O nome e o e-mail são opcionais e só aparecem aos visitantes não registados; os clientes com sessão iniciada são identificados a partir da sua conta. O endereço de e-mail existe para uma única finalidade: avisar quem reportou de que o problema ficou resolvido.

Guardado primeiro, enviado por e-mail depois — e é aí que está tudo

O aviso é escrito na sua base de dados antes de se tentar enviar qualquer e-mail. Se o seu servidor de correio estiver a ter um mau dia, o aviso continua na sua lista. A falha vai para os registos em vez de ser mostrada ao visitante como um erro.

Esta ordem é a razão pela qual a versão 4 existe. Continue a ler.

Um back office que é mesmo um fluxo de trabalho

Os avisos chegam a uma lista que pode ir despachando. Filtre por estado, tipo de problema, categoria, intervalo de datas e texto livre na mensagem, no nome e no e-mail. Selecione vários e marque-os como em curso, resolvidos, como spam ou elimine-os numa só ação.

Cada linha expande-se para mostrar a mensagem completa, o produto — com ligações tanto à sua página na loja como ao seu editor —, quem reportou, as datas e horas, um seletor de estado e um campo de notas para a sua resposta. Os avisos passam por aberto, em curso, resolvido, duplicado e spam.

A exportação para CSV dá-lhe exatamente aquilo que os seus filtros selecionam nesse momento, não a tabela inteira.

Números que lhe dizem onde estão os problemas

Um painel de Resumo conta o que está à espera, o que chegou esta semana e este mês, o que já resolveu e o que era spam — e cada número é uma ligação direta para a lista já filtrada. Ao lado ficam os seus cinco produtos mais reportados, que costuma ser o caminho mais rápido até à página que realmente precisa de ser corrigida.

Um widget na página inicial do Painel de controlo mostra quantos avisos estão à espera e desaparece por completo quando não há nenhum.

Avise quem reportou de que já resolveu

Quando marca um aviso como Resolvido, uma caixa de seleção envia um e-mail a quem o reportou. Só é enviado se essa pessoa tiver deixado um endereço, e a sua nota segue dentro da mensagem. Não custa nada e é a parte de que os clientes se lembram.

Proteção anti-spam que não castiga as pessoas reais

Um campo armadilha (honeypot), um tempo mínimo de preenchimento e um token assinado com HMAC e limitado no tempo estão sempre ativos e não exigem qualquer configuração. O token dura duas horas e está associado ao produto, pelo que não pode ser reutilizado no resto do seu catálogo.

Além disso: um limite por visitante e por produto por hora (1 por predefinição, 0 para desativar) com um teto global fixo de 10 avisos por hora e por visitante por cima. A deduplicação arquiva como Duplicado o mesmo problema reportado pela mesma pessoa sobre o mesmo produto dentro de 24 horas, em vez de o alertar duas vezes — e todos continuam na lista.

O reCAPTCHA v3 opcional está disponível e desativado por predefinição. Carrega código da Google nas suas páginas de produto, por isso mencione-o na sua política de privacidade se o ativar.

O endereço IP de quem reporta nunca é guardado

A limitação de frequência tem de reconhecer um visitante recorrente, por isso o módulo guarda hash_hmac('sha256', $ip, _COOKIE_KEY_) — um hash com chave baseada no segredo da sua própria loja — e nunca o endereço em si.

O que faz a diferença é a chave. Um SHA-256 sem chave de um endereço IP pode ser revertido em minutos calculando o hash dos quatro mil milhões de endereços IPv4; com uma chave que só a sua loja conhece, não pode. A própria bateria de testes do módulo verifica isto de forma explícita.

Os avisos são eliminados quando o respetivo produto é eliminado, e todos eles quando desinstala o módulo. Se o módulo oficial de RGPD psgdpr estiver instalado e ativo, o seu bloco de consentimento é apresentado no formulário automaticamente.

A versão 4 corrigiu um módulo que não entregava um único aviso desde a 3.1.0

Vale a pena dizê-lo sem rodeios, porque é a verdadeira razão para atualizar.

Quando o endpoint de submissão passou para controllers/front/ na 3.1.0, o caminho do modelo de e-mail que estava ao lado não foi atualizado, pelo que passou a apontar para uma diretoria que não existe. O Mail::Send() devolvia false, o módulo respondia die('0') — e como 0 é JSON válido, o front end interpretava-o e executava o tratamento de sucesso.

Todas as lojas com as versões 3.1.0 a 3.2.2 estavam a deitar fora os avisos dos seus clientes enquanto lhes agradeciam por os terem enviado. Quatro versões publicadas e, como nada era guardado, não havia nada para recuperar. Agora os caminhos de e-mail resolvem-se a partir de _PS_MODULE_DIR_, e o armazenamento acontece antes do envio.

Fechou também um relay de correio aberto

A versão 3.x lia o destinatário das notificações a partir de um campo oculto na página. Nunca era validado nem comparado com o endereço da própria loja, e era entregue diretamente ao Mail::Send().

Qualquer visitante anónimo podia fazer a sua loja enviar correio para o endereço que lhe apetecesse, com HTML sem escape no corpo, tantas vezes quantas quisesse. Apontado à sua reputação como remetente. O destinatário vem agora da configuração do módulo e de mais lado nenhum.

O secure_key que supostamente devia impedir isto era md5(_COOKIE_KEY_ . 'reportbrokenlink') — constante durante toda a vida da loja e impresso em cada página de produto. Lido uma vez, reutilizável para sempre. É agora um token assinado com HMAC, limitado no tempo e associado ao produto.

Aquilo que o visitante escreve também leva escape à saída, e não apenas limpeza à entrada. O PrestaShop substitui as variáveis dos e-mails com um simples str_replace e não faz escape de nada, pelo que uma cadeia sem escape permitiria a quem reporta introduzir uma ligação de phishing num e-mail que sai mesmo da sua loja.

O front end perdeu o jQuery 1.8.2 e todas as outras dependências

A versão 3.x carregava jQuery 1.8.2 a partir do CDN da Google em cada página de produto. Isso enviava o IP de todos os seus visitantes para a Google antes de qualquer consentimento, servia uma biblioteca de 2012 com quatro avisos de segurança publicados e substituía o jQuery do seu próprio tema para tudo o que corresse a seguir.

Já não resta nada disso. O front end é JavaScript e CSS vanilla, sem dependências — um ficheiro pequeno de cada, registados apenas nas páginas de produto. Sem jQuery, sem Bootstrap.

As submissões são agora POST. A versão 3.x enviava-as como GET — com uma opção post: "POST" que o jQuery não tem, pelo que usava silenciosamente o método predefinido — o que punha o endereço de e-mail de cada pessoa que reportava nos registos de acesso do seu servidor web.

Acessível porque foi construído assim

A janela é uma janela de diálogo a sério: o foco entra nela, o Tab fica preso lá dentro, o Escape fecha-a, e o foco volta ao botão de onde veio. Os erros são anunciados aos leitores de ecrã, os indicadores de foco são visíveis, o prefers-reduced-motion é respeitado e passa a ecrã inteiro abaixo dos 480 px.

Ao abrir, é também deslocada para o <body>. Renderizada no seu lugar original, ficava dentro do <form> de adicionar ao carrinho do tema — um formulário aninhado que estragava o layout e podia submeter o que não devia.

Compatibilidade

PrestaShop 1.7 a 9, PHP 7.2 a 8.3. A interface do módulo está disponível em oito idiomas: alemão, espanhol, francês, inglês, italiano, neerlandês, polaco e turco. O português não está entre eles — esta página está em português, mas o back office do módulo não; escolha uma das oito línguas acima para trabalhar nele.

Sem overrides, sem alterar o núcleo nem o tema, sem jQuery. Cinco hooks, uma tabela na base de dados. Ao desinstalar são eliminados a tabela, todos os avisos guardados e todas as definições — por isso exporte primeiro para CSV se os quiser conservar.

Perguntas frequentes

Os meus clientes precisam de conta para reportar alguma coisa?

Não, e o recomendável é deixar ativados os avisos de visitantes não registados: normalmente são eles que reparam numa página estragada. Se preferir, pode restringir o botão aos clientes com sessão iniciada com uma única definição.

Onde aparece o botão?

Nas páginas de produto, ao lado da informação do produto ou por baixo dela — displayProductAdditionalInfo ou displayFooterProduct (os dois hooks disponíveis). Se o seu tema esconder um, mude para o outro nas definições do módulo.

O que acontece se o meu servidor de correio falhar?

Não se perde nada. O aviso é guardado antes de se tentar enviar qualquer e-mail, a falha vai para Parâmetros avançados → Registos, e o aviso fica à sua espera na lista. Esta é a maior diferença em relação à versão 3.

Os endereços IP de quem reporta são guardados?

Não. A limitação de frequência usa um hash SHA-256 com chave baseada no segredo da sua própria loja, nunca o endereço em si. O nome e o e-mail são opcionais e são recolhidos apenas para que possa avisar de que resolveu o problema.

Um visitante diz que o formulário lhe indicou que tinha expirado.

O token assinado dura duas horas, por isso quem tenha deixado uma página de produto aberta mais tempo vai ver essa mensagem. Recarregar a página resolve. Os tokens estão associados ao produto, que é precisamente o que impede a sua reutilização noutro ponto do seu catálogo.

Porque é que alguns avisos ficam marcados como Duplicado e não me chegam por e-mail?

A deduplicação está ativada por predefinição: a mesma pessoa, o mesmo produto e o mesmo tipo de problema dentro de 24 horas são arquivados como duplicado em vez de o alertarem duas vezes. Continuam todos na lista — filtre pelo estado Duplicado, ou desative a definição.

Posso tirar os avisos do PrestaShop?

Sim. A exportação para CSV dá-lhe exatamente aquilo que os seus filtros atuais selecionam. As células que começam por um caractere que uma folha de cálculo interpretaria como fórmula (=, +, -, @, tabulação ou retorno de carro) são neutralizadas de propósito, para que ninguém consiga introduzir uma fórmula de folha de cálculo num ficheiro que você vai abrir.

Precisa de jQuery ou de Bootstrap?

Nem de um nem de outro. O front end é JavaScript e CSS vanilla, um ficheiro pequeno de cada, carregados apenas nas páginas de produto. Se estiver a investigar um clique que não faz nada, veja na consola se há algum erro de código alheio na página.

O que acontece aos meus avisos se desinstalar o módulo?

São eliminados, juntamente com todas as definições — é-lhe pedida confirmação antes. Exporte para CSV de antemão se achar que os vai querer mais tarde.