Usuários — visão geral

O módulo de Usuários é onde uma pessoa com permissão de gestão cadastra, edita, ativa/inativa e gerencia as permissões dos usuários do Portal 2.0, e onde qualquer pessoa autenticada mantém os próprios dados em "Minha conta" — perfil pessoal, dados médicos, segurança (senha, MFA, e-mail de recuperação), códigos internos e preferências de busca da worklist.

Este levantamento cobre a interface (Angular) do repositório mm-pacs-portal-main-interface, branch integration/with-fixlaudo, testada no ambiente https://task4.srv1812538.hstgr.cloud/.

Atenção — descompasso de branch confirmado neste levantamento. O ambiente de teste (task4) roda a interface na branch integration/all-features, não integration/with-fixlaudo (a branch que este levantamento foi mandado documentar). As duas divergem: a tela "Minha conta" em integration/with-fixlaudo tem uma sétima aba, Busca padrão (laudo) (/account/me/report-default-search), que não existe em integration/all-features — o accountSidebar do ambiente de teste só declara seis itens (confirmado lendo mm-pacs-portal-main-interface/src/app/app/routes/account.routes.ts nos dois worktrees). Essa aba é documentada abaixo a partir do código (with-fixlaudo), mas não pôde ser capturada — A confirmar — responsável: time de frontend; data: 24/09/2026: repetir a captura assim que o ambiente de teste for atualizado para uma branch que inclua a feature.

O que este módulo cobre e onde cada capacidade vive

• Gestão de usuários (/admin/users) — ver Gerenciar usuários.
• Minha conta (/account/me/*) — dados pessoais, dados médicos e segurança, ver Perfil próprio.
• Preferências pessoais — favoritos de busca, busca padrão da worklist, busca padrão do laudo e frases pessoais (snippets), ver Preferências pessoais.

Fora do escopo desta doc

• Associar usuários a uma unidade (app-associate-users, o modal usado na lista de Unidades e no wizard de criação de grupo) atribui um papel ao vincular um usuário a uma unidade, mas é uma tela da Administração, não deste módulo.
• Papéis, políticas e atribuição de papel por UUID (/admin/roles, /admin/tenant/:id/permissions, /admin/company/:id/permissions) pertencem a Permissões.
• Convites (POST /invitations e o fluxo de aceite) não têm tela própria identificada neste levantamento — o backend está documentado em Convites — API, mas nenhuma página do mm-pacs-portal-main-interface consome essas rotas. A confirmar — responsável: time de frontend; data: 24/09/2026.

Achados de código que não viraram tela (dead code)

Lendo src/app/pages/administration/user-groups e src/app/pages/account/ui/account-address, encontramos dois componentes exportados mas não roteados em lugar nenhum:

Componente	O que faria	Por que não é documentado como feature
UserGroupsComponent (src/app/pages/administration/user-groups)	CRUD de "grupos de usuário" favoritos (/api/user-groups, /api/users/:id/groups)	Nenhuma rota do admin.routes.ts ou de qualquer outro arquivo de rotas importa este componente — confirmado por busca no código. Não aparece em nenhum menu.
AccountAddressComponent (src/app/pages/account/ui/account-address)	Aba "Endereço" da conta (a chave de tradução ACCOUNT.MENU.ADDRESS = "Endereço" existe no pt-BR.json)	accountChildren (account.routes.ts) não declara uma rota address — o item nunca aparece no menu lateral de "Minha conta".

Não documentamos esses dois como funcionalidades ativas porque não há como uma pessoa chegar neles pela interface.

Quem acessa o quê: o padrão confirmado navegando

Testamos três perfis neste levantamento: administrator e doctor de docs-usuarios.md (ambos atribuídos só à unidade "Unidade Central Docs", sem atribuição no grupo "Clínica Docs Portal 2") e o administrador de plataforma e2e.preparation.admin, usado como referência de acesso irrestrito. Os outros sete perfis de docs-usuarios.md (manager, technician, resident, read_only, typist, requestor, financial) não foram testados navegando neste levantamento — mas o comportamento abaixo foi confirmado no código-fonte (identity-system-role.ts) para todos os nove, não é uma dedução isolada dos dois perfis testados. A confirmar — responsável: time de frontend; data: 24/09/2026: repetir a navegação com pelo menos mais um perfil (ex. financial) para checar visualmente.

O que a pessoa tenta	administrator	doctor	Administrador de plataforma
Ver o item Usuários no menu da Administração	Aparece	Aparece	Aparece
Abrir /admin/users por URL direta	Permitido (rota abre)	Permitido (rota abre)	Permitido
A lista carrega algum usuário	Não — sempre vazia, com toast de erro	Não — idem	Sim, com paginação
Botão Exportar CSV / Exportar permissões	Aparecem	Não aparecem	Aparecem
Botão + Cadastrar Usuário	Não aparece	Não aparece	Aparece
Botão Editar por linha	— (não há linhas)	—	Aparece
Ícone de histórico de auditoria por linha	—	—	Aparece
Menu Mais ações por linha (Gerenciar permissões, Integrações, Inativar)	—	—	Aparece
Ações Desbloquear conta / Resetar MFA	—	—	Aparecem (exclusivas de platform-admin)

Causa raiz: nenhum dos nove perfis tem atribuição de tenant

Diferente de outras telas de Administração, aqui o item de menu nunca esconde nada — o NavItem "Usuários" (admin.routes.ts) não declara requiredTenantPermission, então canDisplayNavItem (layout.component.ts:279-286) sempre retorna true e todo mundo vê o item. A rota (permissionGuard('user:read'), escopo 'any', em admin.routes.ts:277) também deixa todo mundo entrar: IdentitySystemRoleMinimumPermissions ( mm-pacs-portal-main-api/package/identity/authorization/core/models/identity-system-role.ts:29-46) garante USER_READ a todos os nove papéis de sistema, mesmo ao financial — que não tem nenhuma outra permissão própria.

O que de fato diferencia os perfis é a listagem em si e as ações de escrita, e a causa raiz é sempre a mesma: nenhum dos nove perfis do fixture tem uma atribuição em nível de grupo (tenant) — só na unidade.

1. A listagem exige tenant_id para quem não é platform-admin, e a tela nunca envia esse parâmetro. O backend documenta a regra explicitamente: "ator não platform-admin sem tenant_id" é recusado com TENANT_SCOPE_REQUIRED (400) — ver Diretório de usuários — API e a regra RN-02 lá descrita. Os filtros de /admin/users (user.component.html, seção Filtros) não têm campo de Grupo/Tenant — só Nome, CRM, E-mail, Telefone, Código do Chat e Status (user.component.ts:110-124). Como administrator e doctor não têm tenant algum na sessão (iamSession.tenants() vazio), a chamada sempre falha dessa forma, mesmo sem nenhum filtro aplicado ou com ?companyId=<unidade> na URL (testamos as duas formas). Ao vivo, isso aparece como a lista sempre vazia ("Nenhum usuário encontrado para os filtros aplicados.") mais um toast "The supplied data is invalid." — confirmado com os dois perfis.

   

2. Os botões de escrita checam permissão no tenant, não na unidade — e nenhum dos nove perfis tem tenant. canCreateUsers() (user.component.ts:149-151) usa iamSession.hasPermissionInAnyTenantScope('user:write'); a permissão concedida só na unidade não conta para essa checagem. O botão Editar da linha usa *appHasPermission="'user:write'; scope: user.groupId" (user.component.html:233) — o escopo passado é o tenant do usuário-alvo, não a unidade do ator. canManageUser() (user.component.ts:391-398, usado para exibir o Mais ações) segue o mesmo padrão. Isso explica por que administrator — apesar do nome — não consegue criar nem editar ninguém nesta tela: seu user:write só existe na unidade, e todos os controles de escrita aqui perguntam pelo tenant.

3. A ativação/inativação de usuário nem chega a tentar a chamada sem tenant. UserService.toggleActivity/inactivateUser (user.service.ts:617-668) chamam requireTenantId(), que lança uma exceção no cliente se não houver tenant resolvível — a mutação (registerIdentityTenantUser/toggleIdentityUserActivity, via GraphQL) é estruturalmente a via "Usuário por tenant" do backend (Usuário por tenant — API), nunca a via de plataforma. Não existe, nesta tela, um caminho que use Gerenciar usuário como administrador de plataforma — API — por isso só quem é platformAdmin de fato consegue criar, editar ou (des)ativar um usuário por aqui.

4. Exportar CSV/Exportar permissões e o ícone de auditoria usam checagem "em qualquer escopo", então aparecem para quem já tem a permissão correspondente concedida na própria unidade: administrator tem user:export e audit:read na unidade (herdados do papel de sistema Administrador) e por isso os vê; doctor não tem nenhuma das duas (DOCTOR_PERMISSIONS em identity-system-role.ts:184-197 não inclui user:export nem audit:read) e por isso não vê nenhum dos dois botões.

Ou seja: nenhum dos nove perfis do fixture de teste consegue criar, editar, (des)ativar ou gerenciar permissões de um usuário nesta tela — essa capacidade, neste ambiente, é exclusiva de quem tem uma atribuição de grupo (tenant) real ou é administrador de plataforma. O wizard de criação de tenant que gerou os nove perfis de teste (docs-usuarios.md) só concede papéis na unidade, então essa limitação é do próprio fixture, não necessariamente do produto para um cliente real — mas vale saber ao usar esses perfis para testar esta tela especificamente.

Páginas deste módulo

Página	Cobre
Gerenciar usuários	/admin/users — listagem, filtros, cadastrar/editar usuário, gerenciar permissões, integrações, desbloquear conta, resetar MFA, ativar/inativar, exportação
Perfil próprio ("Minha conta")	/account/me/personal, /professional, /security, /internal-codes — dados pessoais, dados médicos, segurança e o modo gestor (/account/:userId)
Preferências pessoais	/account/me/listing-presets, /default-search, /report-default-search e o modal "Frases pessoais" da barra superior

Relacionado

• ⚙️ API: Módulo Usuário — visão geral
• 🗂️ Administração — cadastro de grupos/unidades e a associação de usuário a unidade
• 🔐 Permissões — papéis, políticas e atribuição de papel
• 🔐 Autenticação — login e MFA usados para testar os perfis