Splync 1.14 introduz Hard Delete e Soft Delete para despesas

O hard delete remove permanentemente os dados do banco de dados por meio de exclusão física. Uma vez que um registro é deletado dessa forma, ele não pode ser recuperado a menos que existam backups. Já o soft delete funciona de forma diferente. Em vez de remover fisicamente os dados, o sistema os marca logicamente como excluídos. Os dados permanecem no banco de dados, mas são tratados como inativos. Por isso, registros com soft delete geralmente podem ser restaurados posteriormente. Cada abordagem tem suas próprias 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 de dados e limpeza. No Splync, esse equilíbrio é crucial tanto para a confiança quanto para a 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 é projetado 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 deletar uma entrada, seja acidental ou intencionalmente, essa informação desaparece sem deixar rastros. Isso pode levar a cálculos incorretos de liquidação e, mais importante, minar a confiança entre os membros. Em muitos casos, os usuários nem percebiam que algo estava faltando. A versão 1.14 resolve isso introduzindo visibilidade e reversibilidade. Agora, quando uma despesa é removida, 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 exclui 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 estiver dentro de 7 dias da 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 definitividade. No entanto, nem todos os casos devem ser tratados igualmente. E se um usuário, por acidente, adicionar uma despesa privada a um projeto de grupo ou uma entrada for totalmente 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 adequado.

Para lidar com esses casos atípicos, o Splync 1.14 introduz condições controladas para o hard delete. Uma despesa pode ser excluída permanentemente sem notificações se o usuário que a está deletando for tanto o criador quanto o último editor da despesa, e se a exclusão ocorrer dentro de 30 minutos da 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. Dessa forma, o Splync equilibra 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 membro 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 um 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 podem deletar um projeto apenas após liquidá-lo. Não há uma maneira direta de deletar um projeto não liquidado, o que significa que os usuários devem passar por etapas desnecessárias antes de remover um projeto. Isso pode ser inconveniente em casos em que um projeto foi criado por engano, duplicado involuntariamente ou simplesmente não é mais necessário. Melhorar a exclusão de despesas foi um passo importante para resolver esse problema, pois deletar um projeto é mais complexo do que deletar uma única despesa. Pode afetar as despesas, os saldos e a confiança de todos os membros do projeto envolvidos. Por esse motivo, a exclusão de projetos requer um design mais cuidadoso. Uma solução melhor está a caminho.