Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.
Comentário: alteração na restrição de campos em API, para se assemelhar ao uso via MDI

...

Exemplo: O usuário "Teste" não pode visualizar o campo gusuario.status. Logo, qualquer requisição feita tentando passar o campo status (active) em um filtro (como em: http://{{dominio}}:{{port}}/api/framework/v1/users?active=true) a API retornará erro 403. 

Nas Api'sAPIs, a permissão em uma rotina ou funcionalidade, para uma determinada coligada, se materializa como um filtro, limitando as informações às coligadas que o usuário tem acesso.

...

• Mesmo que o usuário envie uma requisição contendo, no Body, um campo com restrição de edição, a API irá ignorar esse campo enviado.

Caso ele possua algum valor default declarado explicitamente no seu mapeamento, o insert será feito com o valor default. 

Caso não possua um valor default, ele será preenchido na base com o valor default do tipo de dado. Ex.: Int = 0; String = null.

• Caso o campo com restrição seja uma PK, a chamada retornará um erro.

| PUT e PATCH:

 • Usuários que tenham restrição de edição de campos, conseguirão utilizar o PUT/PATCH apenas se a requisição não tentar alterar o campo com restrição.

...

Obs: Para a propriedade SkipCheckPropertyMapInfoForFieldLevelSecurity = False


| DELETE:

 • Usuários que tenham restrição de edição  • A restrição de campos , não conseguirão remover não influencia na remoção de registros. Caso o usuário possua um perfil com permissões para apagar o registro, será emitido um aviso informando o campo com restriçãoeste será removido independentemente de possíveis campos restritos ao usuário.