Aviso de confirmação ao alterar email do usuário no admin

TLDR: Ao alterar o email de um usuário no dashboard, exibir um confirm() avisando que o checkout continuará usando o email antigo — e que uma nova compra criaria uma conta duplicada — antes de permitir o submit.

Contexto

O admin pode editar o campo email livremente em StaffUserAdmin e CommonUserAdmin (apps/accounts/admin.py). O email é a chave de correlação com o checkout: save_checkout_ibft (apps/webhooks/tasks.py:50) faz User.objects.get_or_create(email=checkout.email, ...).

Consequência de alterar o email só no Onion:

  1. O checkout continua enviando o email antigo;
  2. get_or_create não encontra o usuário (o email mudou) e cria uma conta nova com o email antigo;
  3. O cadastro editado fica órfão — sem renovação, sem expires_at atualizado — e o usuário passa a ter duas contas.

Existe o webhook POST /webhooks/email-change (apps/webhooks/views.py) que faz a troca vinda do checkout; a troca manual no admin não tem contrapartida no checkout.

Hoje não há nenhum aviso: o admin edita e salva.

Objetivos

  • Avisar o admin, no momento do submit, quando o campo email foi alterado
  • O aviso deve citar o email antigo e o novo, e alertar que o cadastro pode ficar perdido
  • Cancelar o diálogo aborta o submit; confirmar salva normalmente
  • Não exibir nada quando o email não mudou, nem na criação de um usuário novo

Não-objetivos

  • Não bloquear a alteração nem exigir permissão extra
  • Não propagar a alteração para o checkout
  • Nenhuma mudança de model, migration ou API

Mudanças

Arquivo O que muda
templates/admin/accounts/user/change_form.html Sobrescrever {% block admin_change_form_document_ready %} com {{ block.super }} + um <script> que guarda o valor original de #id_email e, no submit do form, chama confirm() com o aviso caso o valor tenha mudado; return false cancela o submit

Segue o padrão já usado neste mesmo template — o botão “Reenviar email de primeiro acesso” usa onclick="return confirm(...)" — e o padrão de <script> inline em templates/admin/trials/trial/change_form_template.html.

Como BaseUserAdmin.change_form_template aponta para esse template, o aviso vale para StaffUser e CommonUser sem mudança no admin.

Texto do aviso

``` ATENÇÃO: você está alterando o email de para .

Isso pode causar problemas: o email deixa de corresponder ao email do checkout e este cadastro pode ficar perdido.

Deseja realmente prosseguir? ```

O aviso não instrui o admin a alterar o email no checkout — essa sincronização é feita por outro fluxo — e não cita “nova compra”, já que o checkout também envia eventos de parcela e renovação.

Como verificar

  1. Abrir um usuário em dash.*/accounts/commonuser/<id>/change/
  2. Salvar sem tocar no email → salva direto, sem diálogo
  3. Alterar o email e salvar → diálogo aparece com o email antigo e o novo
  4. Cancelar → permanece na página, nada é salvo
  5. Confirmar → salva normalmente
  6. Repetir em accounts/staffuser/<id>/change/ → mesmo comportamento
  7. Criar um usuário novo (/add/) → nenhum diálogo

Testes

A mudança é exclusivamente de template/JS, sem lógica Python nova — não há unidade a cobrir com make run.test. A verificação é manual, pelo roteiro acima.

Documentação

Nenhuma regra de negócio nova (.project/docs/rules/): é um guard de UX no dashboard, não muda comportamento de domínio. Apenas esta spec entra em .project/docs/README.md.