Anexo do usuário
Anexo do usuário
Chat online. Esse é um code injection que eu tenho dentro de um Tally Forms, tá? Num domínio personalizado. E o que acontece? Eu tô tentando redirecionar o usuário pra um formulário do qual.com, que tá ficando embedado dentro do Tally. E eu tinha feito isso pra um outro formulário, de um outro produto que a gente tem aqui e tinha dado certo, tava funcionando perfeito, beleza, normal. Só que quando eu tentei agora trocar pra redirecionar pra um outro link, pra uma outra reunião, pra um outro link desse de formulário, né, a estrutura é praticamente a mesma, só muda o link do formulário e tals. Ele tá... parece que ele não tá conseguindo redirecionar pra esse link que eu tô colocando, beleza? Vou te passar alguns prints e contexto. Me explica, o problema tá no code injection ou tá em alguma configuração de redirecionamento interno?
Codigo novo (link para o prudto atual)
https://cal.com/matheus-libonatti-bojumf/bate-papo-com-matheus-libonatti-auto?layout=month_view&theme=light&name=@Nome&attendeePhoneNumber=@WhatsApp&metadata%5Borigem%5D=tally&metadata%5Bfluxo%5D=simulacao_consorcio_auto&metadata%5Bsubmissionid%5D=@submissionid&metadata%5Bnome%5D=@Nome&metadata%5Bemail%5D=@email&metadata%5Btelefone%5D=@WhatsApp
Pensou por 6m 19s
Gustavo, tem um problema confirmado no code injection, mas também precisa conferir a URL do bloco de embed no Tally. Pelo código que você mandou, trocar o link apenas naquela variável url não garante que o calendário passe a abrir a reunião nova.
O detalhe principal é este: seu script não escolhe uma nova reunião. Ele encontra um iframe específico e acrescenta parâmetros ao endereço que já está nele.
1. O código ainda está procurando a reunião antiga
Logo no começo do segundo script, você tem:
calPathMustContain: 'matheus-libonatti-bojumf/45min',
E depois usa essa configuração para localizar o iframe:
return (
src.includes('cal.com') &&
src.includes(CFG.calPathMustContain)
);
Traduzindo: “Só mexa no calendário se o endereço dele contiver matheus-libonatti-bojumf/45min.”
Mas a reunião nova tem outro caminho:
matheus-libonatti-bojumf/bate-papo-com-matheus-libonatti-auto
Portanto, o comportamento do código que você enviou é:
Endereço que está no embed do Tally O que seu script faz
Reunião antiga, terminando em /45min Encontra o iframe e acrescenta os parâmetros, mantendo a reunião antiga.
Reunião nova, terminando em -auto Não encontra um iframe que corresponda ao filtro e não aplica o preenchimento.
Esse desalinhamento está confirmado pelo código.
Por que ele não troca a reunião?
Porque você constrói a URL a partir do endereço que já existe no iframe:
url = new URL(originalSrc, window.location.origin);
Depois altera os parâmetros com url.searchParams.set(...), mas em nenhum momento altera url.pathname nem utiliza uma URL-base nova.
Ou seja: o nome calPathMustContain representa um filtro de busca, não o endereço de destino.
2. No print, você está alterando uma variável — não necessariamente o embed
No segundo print, a lógica está aproximadamente assim:
Quando WhatsApp não estiver vazio:
atribuir o link ao campo calculado "url"
Isso define o conteúdo de um campo calculado. Essa atribuição, sozinha, não configura uma navegação nem troca o endereço do calendário. No Tally, campos calculados guardam valores que precisam ser utilizados em outro lugar; o bloco de embed, por sua vez, recebe o endereço do conteúdo que será incorporado.
Além disso, seu JavaScript não lê esse campo calculado url em nenhum lugar. Ele lê nome, e-mail, telefone, alguns possíveis campos de identificação e o endereço do iframe.
Então, a pergunta técnica aqui é: o bloco do calendário na página final está realmente utilizando esse valor calculado ou continua com o link antigo gravado nele?
O print não mostra a configuração desse bloco, então não dá para afirmar qual dessas duas situações está acontecendo. E o texto “45m” no calendário não resolve essa dúvida: a reunião nova também pode ter 45 minutos.
Não confunda isso com “Redirect on completion”
Como você quer manter o calendário dentro do Tally, o caminho é a página de agradecimento com o embed.
A configuração Redirect on completion é outra coisa: ela leva o respondente para uma URL após o envio e, quando está habilitada, a página de agradecimento não é exibida. Portanto, eu não ligaria essa opção para tentar resolver o calendário incorporado.
3. Os seletores também continuam configurados para o formulário antigo
Seu código procura estes campos:
nome: 'input[aria-label="Nome completo (igual no seu documento)"]',
email: 'input[aria-label="E-mail"]',
telefone: 'input[aria-label="Celular com DDD"]',
Mas no formulário atual você está usando referências como Nome e WhatsApp.
Se os atributos aria-label dos campos publicados também mudaram, o script não vai capturar os valores. Ele não entende que “Celular com DDD” e “WhatsApp” representam a mesma informação: procura o atributo exatamente como você escreveu.
Aqui há uma ressalva importante: o nome da referência @Nome não prova, sozinho, que o input tenha aria-label="Nome". É necessário conferir o HTML do campo publicado.
Isso explica um segundo sintoma possível: você acertar o calendário, mas ele continuar sem receber nome e telefone.
4. O ajuste mínimo que eu faria
Primeiro: acertar o endereço do próprio embed
Na página final, abra a configuração do bloco onde o calendário aparece e, para isolar o problema, use diretamente esta URL, sem referências dinâmicas:
https://cal.com/matheus-libonatti-bojumf/bate-papo-com-matheus-libonatti-auto?layout=month_view&theme=light
Não estou falando do campo calculado url: estou falando do endereço configurado no próprio bloco de embed. O Tally permite inserir o endereço do conteúdo diretamente nesse bloco.
Assim você separa duas verificações: primeiro abrir a reunião certa; depois preencher os dados certos.
Segundo: corrigir o filtro no script
Troque:
calPathMustContain: 'matheus-libonatti-bojumf/45min',
Por:
calPathMustContain:
'matheus-libonatti-bojumf/bate-papo-com-matheus-libonatti-auto',
As duas alterações são complementares: o endereço do embed determina qual reunião abre; o filtro determina se o script vai atuar nela.
Terceiro: ajustar a captura dos campos
Confirmando que os aria-label publicados são Nome e WhatsApp, altere estas propriedades dentro de selectors:
nome: 'input[aria-label="Nome"]',
telefone: 'input[aria-label="WhatsApp"]',
Mantenha o seletor de e-mail somente conforme o campo que realmente existir nesse formulário. Não precisa inventar um campo de e-mail para corrigir a abertura da reunião.
Quarto: separar os dados deste produto
Seu código ainda usa:
storageKey: 'tripoli_cal_iframe_data_v2'
Para o formulário de automóveis, use uma chave própria, por exemplo:
storageKey: 'tripoli_cal_iframe_auto_v1'
Isso evita que os dois formulários reutilizem o mesmo registro durante testes na mesma aba e na mesma origem. O sessionStorage é separado por origem e aba, não pelo caminho de cada formulário, e sobrevive a recarregamentos.
Troque também as duas ocorrências do identificador de fluxo:
url.searchParams.set('fluxo', 'simulacao_consorcio_auto');
url.searchParams.set(
'metadata[fluxo]',
'simulacao_consorcio_auto'
);
Hoje, seu script grava simulacao_consorcio, mesmo que a URL fornecida tenha o sufixo _auto.
Cuidado com o formulário antigo: faça essas alterações na injeção específica do formulário de automóveis. O Tally permite injeção por formulário e por domínio; a injeção no domínio afeta todos os formulários conectados a ele. Não substitua a configuração global sem preservar o outro produto.
5. Seu link novo tem alguns detalhes de preenchimento para revisar
As referências @Nome, @WhatsApp e @submissionid precisam ser referências reais do Tally, não apenas texto colado. Nos campos do editor que aceitam referências, digite @ e selecione o campo correspondente. Não presuma que colar uma URL contendo @Nome automaticamente cria esse vínculo.
Também há uma diferença entre:
email=...
e:
metadata[email]=...
O primeiro é o parâmetro para preencher o campo de e-mail; o segundo é um dado adicional de metadata. Seu link novo só contém o segundo. Caso o e-mail exista no Tally e você queira preencher o campo correspondente no Cal, precisará enviar também email com o valor real. A documentação do Cal trata o preenchimento de campos e o envio de metadata separadamente.
Para o telefone, attendeePhoneNumber está correto quando a pergunta de telefone está habilitada no evento do Cal. O valor deve chegar com o código do país; ao montar a URL, o sinal + deve ser codificado como %2B, algo que URLSearchParams.set() cuida ao serializar.
Esses detalhes afetam o preenchimento, não explicam por si só por que a reunião antiga continuaria aparecendo.
6. Como confirmar qual reunião está carregando
Na página publicada, com o calendário visível, abra o console do navegador no contexto da página do Tally e execute:
(() => {
const resultados = [];
for (const iframe of document.querySelectorAll('iframe[src]')) {
try {
const url = new URL(
iframe.getAttribute('src'),
window.location.href
);
if (!['cal.com', 'www.cal.com'].includes(url.hostname)) {
continue;
}
resultados.push({
reuniao: url.pathname,
scriptAplicado:
iframe.dataset.tripoliCalUpdated === '1'
});
} catch {
// Ignora endereços que não possam ser interpretados.
}
}
console.table(resultados);
})();
Esse teste não altera nada nem imprime dados pessoais.
Se aparecer /45min, o endereço antigo ainda está chegando ao iframe — pelo embed ou por alguma outra configuração/script. O script que você enviou não transforma esse caminho no novo.
Se aparecer o caminho terminado em -auto, mas scriptAplicado estiver false, isso é compatível com o filtro antigo ignorando o calendário novo.
Se aparecer o caminho certo e scriptAplicado estiver true, a investigação passa para os valores capturados. Essa marca só significa que o script executou a atualização; não comprova que havia nome, telefone ou identificação disponíveis naquele momento.
Minha conclusão: o código precisa ser adaptado, sim. Mas, para resolver a reunião errada, o primeiro lugar a conferir é o endereço do próprio bloco de embed. Depois, alinhe o filtro e os seletores do script. Trocar somente o link na variável calculada não conecta automaticamente essas partes.
Estou considerando as barras invertidas e os da sua mensagem como efeitos da colagem no chat. Caso estejam literalmente dentro do code injection, também será necessário limpar essa formatação, pois ela pode invalidar o JavaScript.
Ó, vamos lá. Eu não quis ficar fazendo esse monte de teste, porque aquilo que já tá funcionando tá em produção, tá filé, não quero mexer, tá? Agora, eu fiz, eu criei um outro subdomínio, agora ele vai chamar auto.tripoliconsorcios.com.br e aí esse subdomínio eu já cadastrei dentro do Taly, já coloquei esse formulário apontando pro DNS lá bonitinho, tá tudo certo. Agora então o que eu quero? Que você, com base no code injection que eu te passei anterior, faça as alterações necessárias de code injection na parte do call.com. O resto pode trazer normal, porque se algum dia eu quiser colocar CEP, alguma coisa, já tá certo. Mas traga a parte do code injection do que eu te mandei ali em cima, ajustada para apontar para o novo formulário, tá? Pro nova agenda ali, beleza? Que é essa agenda aqui, eu vou te passar aqui o link agora, show?
E aí, isso porque eu assumi que o code injection tava apontando diretamente. Tava um iframe lá, tava embedado esse formulário ali, entendeu? Será que é isso? Será que eu, na verdade, eu só criei um bloco HTML e era só ter embedado o outro link? Pensem. Acho que eu fiz cagada, não precisava ter feito tudo isso. Mas agora que já separei, então tá. Só confirma se pode ser isso.
…
Reflexão interrompida
Nossa, demorou muito tempo aqui, brother. O que eu fiz? Eu botei o mesmo code injection que eu tinha te passado lá em cima nesse novo subdomínio que eu criei dentro do Tally, tá? Coloquei o link do meu formulário embaixo desse subdomínio novo também, tá? Então ele vai estar respondendo ao mesmo code injection, só que dentro do subdomínio novo. Embeddei o novo bloco ali, beleza? Embeddei esse novo bloco ali com o link dos 30 minutos, beleza, era isso, entre links da reunião. Então realmente era só ter embedado o link novo. Só que esse esquema de direcionar o URL pra passar os parâmetros e tals, ele não pegou os parâmetros que teoricamente eu mandei. Por quê? No modo antigo, quando eu redirecionava a pessoa, quando eu redirecionava a pessoa pra essa página de agendamento, que era uma thank you page, tá? Quando eu redirecionava isso, o que acontecia? Automaticamente, dentro do formuláriozinho do call.com lá, que estava embedado ali dentro, dentro desse formulário, ele já puxava os dados que já estavam na bolhinha. Então ele já puxava o mesmo e-mail que o cara usou, o mesmo WhatsApp e o mesmo nome, entendeu? E é isso que eu queria fazer, pras variáveis que eu tenho aqui, no caso e-mail e WhatsApp. Eu queria, tipo assim, que eu conseguisse passar essas variáveis ali. Aí agora eu não sei se eu tenho que adaptar o novo code injection, porque o nome dos campos lá no Tally, nesse Tally novo, mudei, né? Então antes tinha, tipo, nome completo, sei lá o quê; agora tá só nome, entendeu? Antes tinha, tipo assim, qual o seu melhor número? Era uma variável, né? Era uma pergunta lá do formulário. Agora tá, tipo assim, deixei só escrito WhatsApp, entendeu? Será que é isso? Pensa, mas, cara, eu prefiro velocidade do que punhetação, entendeu?
…
Pensou por 7m 13s
Sim. Você acertou o embed; faltou atualizar o script que preenche os dados. O código reaproveitado ainda procura a agenda /45min e os campos com os nomes antigos, como Nome completo (igual no seu documento) e Celular com DDD. Por isso, trocar apenas o embed resolveu qual agenda abre, mas não o preenchimento automático.
Código completo ajustado
Abra o arquivo, copie todo o conteúdo e substitua o code injection que está no subdomínio auto.tripoliconsorcios.com.br. Não cole abaixo do antigo: substitua. O arquivo já contém o script de CEP preservado e o de Cal.com atualizado.
Nesta versão, o preenchimento está preparado para:
Informação Campo procurado no Tally Parâmetro enviado ao Cal
Nome Nome, com alternativas para os rótulos antigos name
E-mail E-mail ou Email; também reconhece o campo do tipo e-mail email
WhatsApp WhatsApp, com alternativas para telefone attendeePhoneNumber
A agenda configurada é bate-papo-com-matheus-libonatti-auto, e o identificador do fluxo agora é simulacao_consorcio_auto. Também mantive a captura entre as etapas, para os dados continuarem disponíveis quando aparecer a página de agradecimento.
Um detalhe do lado do Cal: para o WhatsApp aparecer preenchido, a pergunta Phone number precisa estar ativada nessa nova reunião, em Advanced → Booking questions. É essa pergunta que recebe attendeePhoneNumber.
Validei a sintaxe e o preenchimento em simulação; não executei dentro do seu Tally publicado. Pode manter o embed novo como está e deixar o formulário antigo completamente intocado.
code_injection_tripoli_auto.txt
Documento
