Parte do épico Central de perfil do profissional (frente: backend). Mocks são base direcional, não fonte de verdade.
Objetivo: Endpoints de edição de perfil por seção, sempre no usuário do token.
Arquivos: Modify src/controller/userController/index.mjs, src/routes/index.mjs, src/services/validationService.mjs · Test src/tests/profileEdit.test.mjs
Dependências: #86 (campos no User)
O que fazer:
- Endpoints por seção (autenticados, atualizando sempre
req.userId — nunca um id do body):
- Dados Pessoais:
name, birthdayDate (manter o contrato numérico/epoch do validateBirthDate), telefone, bio, endereço residencial. O endereço é tratado dentro deste endpoint localizando o subdocumento de address[] do próprio usuário — não reusar o PUT /address (exige addressId).
- Serviços:
professionalSpecialties, otherProfessionalSpecialties, professionalServicePreferences.
- Local de Atendimento: o subdocumento
clinic (chaves em inglês) — não confundir com address[].
- Métodos de Pagamento:
acceptedPayments.
- A foto reusa
POST /auth/uploadPhoto.
- CPF (
CNPJCPFProfissional) não entra nas respostas (retornar só confirmação, não o documento) — LGPD.
- Re-moderação: se o perfil está
aprovado e a edição toca especialidades/serviços/local, voltar publicationStatus para em_analise. Campos menores (bio/foto/telefone/pagamento) ficam live.
Test scenarios: cada endpoint atualiza só a sua seção, no usuário do token; sem token → 401; id de outro usuário não tem efeito; atualização parcial não apaga; editar campo regulado de perfil aprovado → em_analise; resposta não traz CPF; birthdayDate inválido → 400.
Pronto quando: o profissional edita cada seção (sempre a própria), o CPF não vaza e editar campo regulado re-dispara a análise.
Parte do épico Central de perfil do profissional (frente: backend). Mocks são base direcional, não fonte de verdade.
Objetivo: Endpoints de edição de perfil por seção, sempre no usuário do token.
Arquivos: Modify
src/controller/userController/index.mjs,src/routes/index.mjs,src/services/validationService.mjs· Testsrc/tests/profileEdit.test.mjsDependências: #86 (campos no User)
O que fazer:
req.userId— nunca um id do body):name,birthdayDate(manter o contrato numérico/epoch dovalidateBirthDate),telefone,bio, endereço residencial. O endereço é tratado dentro deste endpoint localizando o subdocumento deaddress[]do próprio usuário — não reusar oPUT /address(exigeaddressId).professionalSpecialties,otherProfessionalSpecialties,professionalServicePreferences.clinic(chaves em inglês) — não confundir comaddress[].acceptedPayments.POST /auth/uploadPhoto.CNPJCPFProfissional) não entra nas respostas (retornar só confirmação, não o documento) — LGPD.aprovadoe a edição toca especialidades/serviços/local, voltarpublicationStatusparaem_analise. Campos menores (bio/foto/telefone/pagamento) ficam live.Test scenarios: cada endpoint atualiza só a sua seção, no usuário do token; sem token → 401; id de outro usuário não tem efeito; atualização parcial não apaga; editar campo regulado de perfil aprovado →
em_analise; resposta não traz CPF;birthdayDateinválido → 400.Pronto quando: o profissional edita cada seção (sempre a própria), o CPF não vaza e editar campo regulado re-dispara a análise.