Feat/devltz/user

[DevlTz]

Trouxe na PR um modelo de usuário personalizado e recursos relacionados ao gerenciamento de usuários para o app users. As principais mudanças incluem a definição de um novo modelo User com campos adicionais, a adição de um modelo SearchPreference, a atualização do registro no admin, a criação de serializers e viewsets para interação com a API e a configuração do Django para usar o novo modelo de usuário. A API agora suporta endpoints de perfil do usuário e de favoritos.
Modelo de usuário e preferências:

• Introduzido um modelo User personalizado herdando de AbstractUser, com email único, campos user_type, age e gender, além da atualização das opções de Meta para nome da tabela e nomes legíveis no admin.
• Adicionado o modelo SearchPreference, ligado um-para-um ao User, armazenando filtros de busca de imóveis como tipo, faixa de preço, cidade e bairro.
• Criada a migration inicial para estruturar as novas tabelas User e SearchPreference.
• Registrados os novos modelos no admin do Django.
• Definido AUTH_USER_MODEL = 'users.User' nas configurações do projeto para ativar o modelo de usuário customizado.

API e serialização:

• Adicionados UserSerializer e SearchPreferenceSerializer para serialização e desserialização dos dados de usuário e preferências, incluindo lógica para atualizar preferências aninhadas.
• Implementado um UserViewSet com endpoints para o perfil do usuário autenticado (GET/PATCH) e um placeholder para gerenciamento de favoritos.
• Alterado o roteamento de URLs para usar um router do DRF com o novo UserViewSet.

Outras configurações:

• Definido um app label personalizado no UsersConfig.
• Comentado o mount do script de inicialização do Postgres em docker-compose.yaml (não relacionado diretamente aos recursos de usuário).

[luisaferreirass]

1. Padronização de linguagem

Vamo deixar tudo em ingês (acho que fica mais padronizado).
Precisaria alterar só a classificação dos tipos de usuário, o verbose name dos usuários e as mensagens nas views

 options={
                'verbose_name': 'Usuário',
                'verbose_name_plural': 'Usuários',
                'db_table': 'users',
            }

{"mensagem": "Aqui retornaremos os imóveis favoritos (precisa do model Property finalizado)"}

2. Views

Porque você usou o ModelViewSet e não o generics?

3. SearchPreference

Não entendi o sentido de armazenar isso no banco se já tem os filtros objetivos. Tem a ver com o algoritmo de recomedação? Fiquei meio confusa nessa parte.

4. Read only fields no serializer

read_only_fields = ['email', 'user_type'] # Evitar que o user mude o próprio email/tipo na route

O usuário deveria poder alterar o seu email e quem sabe virar um dia um locador. Então, acho que isso pode ser separado no serializer.

[DevlTz]

Ok ok, vejo algumas coisas agora q vc perguntou e fez o review :)

---

1. Padronização de linguagem

Sobre esse ponto, eu acho perfeito a gente padronizar, eu só não tinha certeza se a gente ia fazer exatamente em inglês, porque eu estava crente que ia ser em português o MVP pra gente também depois caso necessário, levassemos a ideia pra incubadora do IMD ou enfim, até pra apresentação, mas tranquilo se for o objetivo eu refatoro o models.py e outros do app de Users pra corrigir.

---

2. ModelViewSet vs Generics

Vamo lá, os dois vão fazer a mesma coisa no fundo — a diferença é que o ModelViewSet é um atalho que já
vem com todas as operações básicas prontas (listar, criar, editar, deletar...) sem precisar escrever
cada uma na mão. Usei ele no CRUD dos usuários porque é um que usa praticamente tudo isso, objetivo era reduzir uso de código repetido.

As generics que foi o que você usou no Properties elas servem pra quando a gente precisa de um controle mais
certeiro em cada rota.

Outra vantagem do ModelViewSet é que ele
facilita criar rotas extras como /profile/ e /favorites/ com bem menos configuração.

---

3. SearchPreference

ISSO! Os filtros do filters.py são pra busca contínua ou ativa — ou seja, aquilo que o usuário quer agora.
A SearchPreference salva o perfil base dele pra alimentar o algoritmo de recomendação.

A ideia é cruzar o histórico de preferências com os vetores dos imóveis pra gerar uma vitrine
personalizada na home e disparar alertas quando um imóvel com o perfil dele for cadastrado.

Isso faz parte um daqueles formatos que a gente conversou e eu falei no grupo --- Sobre poder pegar informações anteriores de úsuarios

---

4. read_only_fields

Concordo com a separação — vou criar
dois serializers distintos:

• UserProfileSerializer — para atualizações gerais do perfil (nome, idade, gênero etc.)
• UserAccountSerializer — para alterações mais claras como email e user_type, com
  validações extras

Só me confirma depois se é exatamente assim que você tava pensando >:)

Sobre cada campo:

• Email: Mudança de email normalmente exige confirmação no novo endereço, senão o usuário
  pode digitar errado e perder o acesso. Vou manter protegido e criar um endpoint específico
  depois — algo como POST /api/users/change-email/ — que lida com essa confirmação do jeito certo.

Acredito que pro MVP já vai servir

• user_type: Virar anunciante também seria transformar sua conta e aceitar novos Termos de Uso — não dá pra deixar isso aberto numa parte simples de perfil. O que eu pensei seria criar um endpoint específico
  POST /api/users/upgrade-to-advertiser/ que nela sim, trabalharia corretamente e lidaria com o que o que vc falou.

---