Splync 1.14 Introduz Hard Delete e Soft Delete para Despesas

Hard delete remove permanentemente os dados do banco de dados através da exclusão física. Uma vez deletado, o registro não pode ser recuperado, a menos que existam backups. Soft delete funciona de forma diferente. Em vez de remover fisicamente os dados, o sistema os marca logicamente como deletados. Os dados permanecem no banco, mas são tratados como inativos. Por isso, registros com soft delete geralmente podem ser restaurados depois. Cada abordagem possui suas vantagens e desvantagens em termos de integridade dos dados, conformidade e experiência do usuário. Criar um serviço confiável e amigável de compartilhamento de despesas significa encontrar o equilíbrio certo entre retenção e limpeza de dados. No Splync, esse equilíbrio é crucial para confiança e usabilidade.

Antes da versão 1.14, deletar uma despesa no Splync significava remoção imediata e permanente do banco de dados. Isso gerava um problema sutil, mas sério, especialmente porque o Splync foi feito para ajudar casais e amigos a gerenciar orçamentos compartilhados com facilidade. Imagine um projeto compartilhado com dezenas de despesas. Se um parceiro ou amigo apaga uma entrada, acidentalmente ou não, esses dados somem sem deixar rastro. Isso pode levar a cálculos incorretos de acerto e, mais importante, abalar a confiança entre os membros. Em muitos casos, os usuários nem perceberiam que algo estava faltando. A versão 1.14 resolve isso ao introduzir visibilidade e reversibilidade. Agora, ao remover uma despesa, os usuários são notificados e têm a opção de restaurá-la, se necessário.

Na versão 1.14, a maioria das exclusões é tratada como soft delete. Quando um membro do projeto apaga uma despesa, os outros membros recebem uma notificação. Ao mesmo tempo, a despesa é movida para um estado de "lixeira", em vez de ser apagada fisicamente. Se for dentro de 7 dias após a exclusão, qualquer membro do projeto pode restaurar a despesa para a lista de despesas ativas. Isso reflete como muitos sistemas modernos lidam com exclusões, priorizando segurança sobre finalização. No entanto, nem todos os casos devem ser tratados da mesma forma. E se um usuário adicionar acidentalmente uma despesa privada a um projeto em grupo, ou uma entrada for completamente irrelevante? A remoção imediata pode ser necessária para evitar confusão ou preocupações com privacidade. Nesses casos, notificar todos e manter um registro recuperável pode não ser apropriado.

Para lidar com esses casos extremos, Splync 1.14 introduz condições controladas para hard delete. Uma despesa pode ser deletada permanentemente sem notificações se o usuário que a apaga for tanto o criador quanto o último editor, e se a exclusão ocorrer dentro de 30 minutos após a criação da despesa. Quando essas condições são atendidas, o sistema trata a ação como um desfazer rápido, em vez de um evento compartilhado. Todos os outros cenários de exclusão são padrão para soft delete. Desse modo, o Splync encontra um equilíbrio entre flexibilidade, privacidade e transparência.

Projetamos esse recurso para ser o mais intuitivo possível. Na versão 1.14, adicionamos um novo botão de filtro ao lado do botão de filtro de membros existente, permitindo que os usuários alternem entre despesas ativas e na lixeira. Como resultado, a área de filtro e classificação da interface foi ligeiramente atualizada. Para manter a interface simples e fácil de entender, os botões de filtro agora usam símbolos. Para uma despesa ativa, os usuários podem deslizar para a esquerda para deletá-la. Após tocar no botão de deletar, um alerta aparece para esclarecer se a ação resultará em um hard delete ou soft delete, para que os usuários possam prosseguir com confiança. Para uma despesa na lixeira, os usuários podem deslizar para a esquerda para restaurá-la.

Agora que melhoramos o fluxo de exclusão de despesas, o próximo passo é tornar a exclusão de projetos mais flexível. No momento, os usuários só podem deletar um projeto após liquidá-lo. Não há um jeito direto de deletar um projeto não liquidado, o que significa que os usuários precisam passar por etapas desnecessárias antes de removê-lo. Isso pode ser inconveniente em casos em que um projeto foi criado por engano, duplicado sem querer ou simplesmente não é mais necessário. Melhorar a exclusão de despesas foi um importante passo para resolver essa questão, pois deletar um projeto é mais complexo do que deletar uma única despesa. Isso pode afetar as despesas, saldos e confiança de todos os membros envolvidos no projeto. Por essa razão, a exclusão de projetos requer um design mais cuidadoso. Uma solução melhor está a caminho.