Soft Delete

Interface SoftDeletable

Entidades que suportam soft delete implementam com.erplider.core.domain.base.SoftDeletable:

public interface SoftDeletable {
    void delete();
    void restore();
    boolean isDeleted();
}

A base BaseEntity já implementa essa interface através de uma coluna deleted_at (Instant, nulável). isDeleted() retorna deletedAt != null.

Entidades que suportam o padrão

CandidateEntity, VacancyEntity, ClientEntity, ClientUnitEntity, ClientContactEntity, UserEntity, BenefitEntity e UserSessionEntity estendem BaseEntity.

ApplicationEntity tem a coluna deletedAt, mas não implementa os métodos de soft delete nem expõe filtro deleted no DTO de busca — ainda não segue o padrão completo.

Endpoints por recurso

Cada controller segue a mesma convenção de rotas (exemplo para candidate, mesma coisa vale para vacancy, client, client-units, user):

O hard delete usa a mesma permissão do soft delete — ainda não existe uma permissão dedicada (<recurso>:force-delete, por exemplo) para restringir quem pode apagar de forma definitiva.

ClientContact e Application só têm soft delete implementado; não há endpoint /force para eles.

Filtrando por status de exclusão

As listagens (GET) aceitam um parâmetro deleted (boolean) no filtro DTO:

public record CandidateFiltersDTO(
    @Nullable Boolean deleted
) {}

• deleted=false (ou omitido): apenas registros ativos
• deleted=true: apenas registros excluídos (soft-deleted)

Não existe um endpoint agregado que liste os itens excluídos de todos os recursos de uma vez — cada recurso precisa ser consultado separadamente. O frontend faz isso na página Lixeira (ver Visão Geral do Frontend).

Auditoria

Toda operação de delete é registrada via @Audit(action = AuditAction.SOFT_DELETE | AuditAction.HARD_DELETE).