Ajustes· 3 ítems

Versión 1.63.2

Las notas de versión están escritas en portugués, el idioma en que se desarrolla DeskcommCRM. Tu navegador puede traducirlas, o puedes abrir esta página ya traducida.

Abrir en Google Traductor

Corregido3

O tempo na etapa do card do Kanban não zera mais a cada nota ou mensagem

O rodapé do card do Kanban contava o "tempo no estágio" a partir da última atividade do negócio: qualquer nota, edição ou mensagem na conversa zerava o relógio de um negócio parado na mesma etapa havia dias. Agora o tempo é contado a partir da entrada na etapa atual (a coluna crm_leads.stage_changed_at, carimbada pelo banco desde a migration 0071), e só mudar de etapa zera o relógio. Negócio sem esse registro cai na data de criação, nunca na última mensagem. Contribuição de @webtecnica (PR #1908).

Excluir um contato que já passou por retorno automático não perde mais o histórico

Quem tentava excluir pela tela um contato que já passou por um retorno automático levava um erro e ficava com a ficha na base sem histórico: as mensagens e as conversas já tinham sido apagadas quando a exclusão foi recusada. A auditoria registrava contact.delete_blocked com apagados: ["messages","conversations"] — o rastro exato do estrago.

O defeito tinha duas metades e as duas foram consertadas. O banco recusava com 42501 o DELETE que chega em cascata quando a ficha é apagada, porque o gatilho de proteção do follow-up não distinguia cascata de escrita direta — agora ele distingue pela profundidade do gatilho: a cascata passa, quem apaga um turno de follow-up pela API com sessão de usuário continua sendo recusado, como sempre. E a rota, que apagava mensagens, conversas e a ficha em três passos separados, passa a chamar uma função única: as três saem numa transação só, ou sai tudo ou não sai nada.

Ficha com compromisso na agenda continua sendo recusada antes de qualquer coisa ser apagada, e uma exclusão que falhe por qualquer outro motivo deixa o histórico exatamente onde estava. Nada muda para quem opera além de a exclusão passar a funcionar. Não exige ação.

Contribuição de @webtecnica (#1912).

Só gerente ou administrador consegue cancelar ou apagar uma inscrição de follow-up pelo acesso direto ao banco

Qualquer membro da organização, inclusive quem só tem o papel de visualizador, conseguia apagar ou alterar uma inscrição de follow-up, ou um fluxo inteiro, falando direto com o banco pela chave pública do sistema e pela própria sessão, sem passar pelas telas e sem ficar registrado na auditoria. Apagar a inscrição levava junto o histórico dela e as mensagens de follow-up já agendadas. Agora só quem tem o papel de gerente ou de administrador consegue criar, alterar, cancelar ou apagar uma inscrição ou um fluxo de follow-up por esse caminho, que é o mesmo papel que as telas e a API já exigiam. A leitura continua liberada para todos os membros, e as telas e os envios automáticos funcionam como antes. Não há nada para fazer: a regra entra sozinha na próxima atualização.

← Volver a todas las versionesVer en GitHub