Pular para o conteúdo principal

Detalha um usuário

GET 
/user/:iduser

Retorna o cadastro completo do usuário na empresa: dados pessoais e profissionais (função, cargo, escala de trabalho, supervisor imediato e módulo atual), flags de vendedor, técnico e comissão, funções (UserJobPositionList), perfis de acesso (UserPrivilegeGroup), regras de comissão (SalesmanComission), vínculos de empresa/filial faturadora (UserCompanyInvoice), centros de distribuição (UserCompanyDistributionCenter), categorias de fornecedor (UserCompanySupplierCategory), categorias e grupos de endereço de estoque (StockKeepingUnitLocationCategories, StockKeepingUnitLocationGroups), etiquetas do colaborador (Tags) e a auditoria de alterações (UserLog) e de acessos (LoginLog).

O parâmetro Type troca o endpoint para dois modos enxutos, usados no carregamento da tela inicial: Tours devolve apenas os tours de apresentação já vistos e Dashboard devolve a configuração de painel já resolvida (a pessoal quando existe, senão a do perfil de acesso) junto com as preferências de arrumação da home.

No modo padrão considera apenas o vínculo ativo (status=1); informe status na query para buscar por outro status. Quando não há vínculo no status pedido, retorna um array vazio ([]) com status 200. Com status=3 (convite pendente, ver POST /user), a pessoa ainda não aceitou entrar na conta: vêm só o nome e o e-mail mascarado (Login, null quando é login interno); os dados pessoais e de acesso (UserCpfCnpj, UserTelephone, UserExtenalId, UserImageUrl, MFA, PIN, tours, IDModuleFavorite, LastLogin, LastPasswordChange) vêm null, e UserLog e LoginLog vêm vazios.

Alertas de gráfico (ChartAlert=1). Com ChartAlert=1, o endpoint devolve, para o painel de alertas do Dashboard personalizado, o que o servidor registrou sobre os alertas de gráfico com aviso do usuário (ChartAlertStatusList): a situação de cada um (disparado, normal, ainda não checado, com erro ou sem valor para comparar), a última checagem, o último valor medido, o último aviso e, por alerta, os eventos mais recentes (disparou, avisou, voltou ao normal, falhou, desistiu…). Só leitura. Só o texto 1 liga o modo; com qualquer outro valor o parâmetro é ignorado.

  • De quem são as linhas. Sempre do usuário do token. O {iduser} do caminho tem de ser esse mesmo usuário, senão 400 sem dado nenhum; nenhum outro parâmetro nem o corpo escolhe outro usuário, e nenhum privilégio (nem o de editar o painel de outras pessoas) abre a linha de outra pessoa. Usuário ausente no token: 400.
  • Não combina com Type. ChartAlert=1 junto com Type (qualquer valor) dá 400. status é ignorado.
  • Sem filtro pela conta do subdomínio. O painel pessoal é um só por usuário, aberto em qualquer conta dele, e cada alerta monitora a conta em que foi criado: ela vem em IDCompany e AccountName.
  • Privilégio. O modo não exige privilégio: a linha é do próprio usuário, e quem perdeu o privilégio de editar continua recebendo o aviso.
  • O que nunca vem. A configuração do alerta (condição, destinatários, janela), que já está no DashboardConfig do usuário (PUT /user/{iduser}); o detalhe do envio por destinatário (só as contagens, em Delivery); o texto do erro dos envios; e o texto do código exception. Endereços de e-mail nos motivos que vêm saem mascarados (c***@dominio).
  • Casamento com o painel. Cada alerta é identificado pela tripla (PanelId, WidgetId, AlertId), a mesma do DashboardConfig. Um registro sem alerta correspondente no documento é de um salvamento ainda não sincronizado, e é atualizado ou removido no próximo salvamento do painel.
  • Datas. Texto YYYY-MM-DD HH:MM na hora de parede de São Paulo (horário de Brasília), sem fuso e sem Z. Não converter de fuso.
  • Resposta. Sempre um objeto com Version: 1. Sem nenhum alerta com aviso: Alerts vazio. Se só o histórico falhar, a situação vem e EventsAvailable é false. A resposta não é guardada em cache.

Convites pendentes (Invite=1). Com Invite=1, o endpoint devolve, em vez do cadastro, os convites para conta que o usuário do token ainda pode responder, de qualquer conta (lista de UserInvitePending): vínculo pendente, sem resposta, dentro do prazo de 7 dias e com a empresa ativa. É o aviso que o app mostra depois do login (“Você foi convidado para a conta X”). A resposta pelo app vai no campo InviteAnswer do PUT /user/{iduser}; a do link do e-mail, no POST /user/password-reset com Invite=1. Só leitura. Só o texto 1 liga o modo; com qualquer outro valor o parâmetro é ignorado.

  • De quem são as linhas. Sempre do usuário do token. O {iduser} do caminho tem de ser esse mesmo usuário, senão 400 sem dado nenhum. Usuário ausente no token: 400.
  • Não combina com ChartAlert, Type nem ReportSchedule. Invite=1 junto com qualquer um deles (qualquer valor) dá 400. status é ignorado.
  • Sem filtro pela conta do subdomínio. O convite é para outra conta, e a lista é a mesma em qualquer conta em que a pessoa esteja logada.
  • Privilégio. O modo não exige privilégio: a lista é do próprio usuário.
  • Resposta. No máximo 20 convites, do mais novo para o mais antigo; sem convite pendente, []. Falha na consulta também devolve [], e o convite continua valendo pelo link do e-mail.

Request​

Responses​

Detalhe do usuário (array com 1 item) ou [] quando não há vínculo no status pedido. Com ChartAlert=1, a situação dos alertas de gráfico do usuário (ChartAlertStatusList): sempre um objeto com Version: 1, os alertas em ordem de criação, no máximo 200 (Truncated diz se havia mais). Com Invite=1, os convites pendentes do usuário do token (até 20, do mais novo para o mais antigo; [] quando não há nenhum ou quando a consulta falha).

Última atualização em