Administração do sistema

A configuração deve ser feita nas políticas de segurança para os usuários e servidores que devem realizar o reinicio automático.

Para políticas de usuários:

1. Acessar o processo “Administração do sistema > Segurança > Políticas de segurança > Políticas de usuários”.
2. Encontre a política do usuário que deve fazer o reinicio automático.
3. Altere para o modo Formulário.
4. Habilite a opção “Reinício do Engine remoto”.

Para políticas de servidores:

1. Acessar o processo “Administração do sistema > Segurança > Políticas de segurança > Políticas de servidores”.
2. Encontre a política do computador que deve fazer o reinicio automático.
3. Altere para o modo Formulário.
4. Habilite a opção “Reinício do Engine remoto”.

Bases habilitadas para criar permissões para novas classes e arquivos de forma automática não copiam necessariamente todas as permissões existentes nas classes-mãe. Permissões de papéis não são sugeridas, pois o conceito de um papel é que ele seja um template de permissões criadas em uma base de desenvolvimento. Permissões para papéis não poderiam ser criadas na base atualizada, pois tornaria as permissões dos papéis diferente do template sugerido pelo sistema ou dos papéis Custom criados na base de Desenvolvimento.

Outros motivos para não sugerir as permissões:

• o administrator ter desabilitado a criação de permissões que ocorre nos processos de atualização; e
• o administrator ter indicado os grupos e usuários que devem ter as permissões sugeridas. Essas configurações estão disponíveis no processo “Administração do sistema > Atualização > Gestão de permissões”.

Observação: permissões com herança, ou seja, que possuem o campo “Aplicar na” preenchido com “Classe e filhas”, sempre são mantidas a cada atualização do sistema, independente da configuração do processo indicado acima.

Ver Diferenças entre Grupos e Papéis para mais detalhes.

Se a migração de servidor for realizada por meio da cópia do diretório de instalação do servidor Engine, as tarefas agendadas serão automaticamente copiadas, visto que elas são armazenadas dentro do diretório de instalação.

Caso a migração esteja sendo realizada para uma nova instalação do Engine, você poderá copiar as tarefas utilizando o processo Agendador de scripts. Para isto:

1. Abra o processo “Administração do sistema > Scripts agendados > Agendador de scripts” na instalação anterior do Engine, onde os scripts agendados estão cadastrados.
2. Selecione os agendamentos que devem ser copiados.
3. Selecione o botão “Exportar para arquivo” e escolha entre as opções “Realizar download” ou “Gravar no servidor”.
4. Se for escolhida a gravação no servidor, deve ser informado o caminho e o nome do arquivo para gravação e clicar no botão “Gravar”. Em seguida copie o arquivo gerado no servidor para uma pasta no servidor do Engine de destino;
5. Abra o processo “Administração do sistema > Scripts agendados > Agendador de scripts” na nova instalação do Engine.
6. Selecione o botão “Importar do arquivo” e escolha entre as opções “Realizar upload” ou “Ler do servidor”.
7. Se for escolhida a opção “Ler do servidor”, informe o nome e local do arquivo copiado no passo 4. Em seguida selecione a opção “Importar” e os agendamentos serão gravados no Engine local.

Pronto, sua nova instalação do Engine agora possui os scripts agendados que existiam na instalação anterior do Engine.

Um recurso importante na gestão de permissões do sistema é a possibilidade de criar grupos de grupos de usuários. Este recurso permite simplificar a configuração de usuários que necessitam da combinação das permissões de diversos grupos.

Supondo que temos os papéis “Operador de Caixa” e “Vendedor de Loja” definindo os processos, relatórios e permissões básicas para que os usuários possam executar estas funções. E que também temos os grupos “Usuários da Loja X” e “Usuários da Loja Y” que definem permissões de acesso aos dados específicos da loja, como depósitos, estabelecimento, local de escrituração, disponíveis e terminais de caixa. Se os os nossos operadores de caixa também puderem realizar vendas, teremos a seguinte configuração:

Usuário: Caixa X. Grupos: Operador de Caixa, Vendedor de Loja e Usuários da Loja X. Usuário: Caixa Y. Grupos: Operador de Caixa, Vendedor de Loja e Usuários da Loja Y.

Para simplificar, podemos criar um grupo chamado “Caixas” cujos grupos são Operador de Caixa e Vendedor de Loja. Desta forma, a configuração acima seria simplificada para:

Usuário: Caixa X. Grupos: Caixas e Usuários da Loja X. Usuário: Caixa Y. Grupos: Caixas e Usuários da Loja Y.

Para criar este grupo, basta ir no processo “Administração do sistema > Segurança > Grupos e usuários > Grupos” e adicionar um novo grupo, cujo campo Grupos seja preenchido com relação de grupos que ele irá agregar.

A criação de grupos que agregam outros grupos mais simples, simplifica a gestão das permissões e é uma prática recomendada para o administrador do sistema.

Ao fazer a importação de arquivo para o sistema, é possível vinculá-lo a um cadastro do sistema.

Quando for possível um cadastro ter uma imagem vinculada ao registro, haverá uma grade detalhe indicando as imagens já vinculadas.

Nessa grade é possível alterar as propriedades de configuração das imagens. Dentre as propriedades há a indicação se a imagem é a principal do cadastro ou não. Somente uma imagem pode ser definida como principal. Ao definir como principal, essa imagem será retornada em todos os locais que solicite a imagem padrão do registro.

Por exemplo, o cadastro de Recursos tem imagens vinculadas. Várias imagens podem ser vinculadas ao registro, porém só uma delas pode ser definida como principal. Dessa forma, ao tentar capturar a imagem padrão do recurso, será mostrado a imagem que foi configurada na grade detalhe com o campo Principal preenchido.

Para que um produto do sistema possa ser utilizado, ele deve estar licenciado. Para adicionar a licença de um módulo é necessário que a chave de licenciamento tenha sido gerada. Se a base que está acessando já está licenciada, pule para o próximo tópico, mas se estiver curioso de como funciona o licenciamento, continue lendo abaixo:

Para adicionar a licença de um módulo siga os passos:

1. Acesse o processo “Administração do sistema > Licenças > Produtos licenciados”.
2. Clique em Adicionar.
3. Informe a chave fornecida pelo administrador, informe a senha do usuário Administrator, confirme a senha e clique em Gravar.

A autenticação multifator (MFA) adiciona uma camada extra de segurança ao exigir dois ou mais fatores de verificação para autenticação. No sistema, o MFA pode ser configurado por meio de provedores de identidade externos suportados, como Google Workspace, Microsoft Entra, Keycloak, ou outros provedores OpenID Connect (OIDC) compatíveis. O uso de provedores de identidade permite centralizar a gestão de autenticação e políticas de segurança, além de melhorar a experiência do usuário ao utilizar credenciais já existentes e fluxos de autenticação familiares.

Para ativar o MFA, deve ser utilizado o processo “Administração do sistema > Segurança > Provedores de identidade” para configurar o provedor desejado seguindo as instruções específicas de cada serviço. Certifique-se de que o MFA esteja habilitado nas configurações do provedor externo (Google Workspace, Microsoft Entra, Keycloak, etc.) antes de configurar a integração no sistema.

Uma vez configurado o provedor de identidade, deve-se criar uma política de autenticação associada ao provedor no processo “Administração do sistema > Segurança > Políticas de autenticação” utilizando a classe “Políticas de autenticação externa”. Essa política deve ser atribuída na política de segurança dos usuários ou grupos de usuários que utilizarão o MFA.

Após a configuração, os usuários serão automaticamente direcionados para o processo de autenticação multifator do provedor de identidade configurado. É recomendável testar a configuração com um usuário de teste antes de aplicar a todos os usuários da organização.

Mais detalhes no manual Provedores de identidade.

Deve ser utilizado o processo “Explorador de arquivos” localizado no menu “Administração do sistema > Classes de dados”. Nele, podem ser exportados arquivos por meio do botão “Download” ou todo o conteúdo de um diretório por meio do botão “Exportar diretório”.

A mudança de classe de um registro no sistema equivale, conceitualmente, a excluir o registro de uma classe X e inserir em uma classe Y. Assim ao mudar a classe de um registro, o sistema critica a permissão de exclusão de registros na X.

Para solucionar esta crítica do sistema, você deve acionar o administrador do sistema para que ele libere a permissão para o que o seu usuário possa excluir registros da classe X.

A mudança de classe de um registro no sistema equivale, conceitualmente, a excluir o registro de uma classe X e inserir numa classe Y. Assim ao mudar a classe de um registro, o sistema critica a permissão de inclusão de registros na classe Y.

Para solucionar esta critica do sistema, você deve acionar o administrador do sistema para que ele libere a permissão para o que o seu usuário possa inserir registros da classe Y.

Após um upgrade algumas pastas podem ser apagadas fazendo com que seus arquivos filhos fiquem órfãos na iVFS, estes arquivos são movidos para a pasta Dados/Sistema/Órfãos.

O cliente deve analisar quais estão sendo utilizados e fazer a recolocação para o local correto no sistema ou, em caso negativo, pode realizar a exclusão manual dos mesmos (clicando-se com o botão direito no script e escolhendo a opção delete).

Estes arquivos pertencem somente a base de destino e caso deletados não serão inseridos novamente em uma futura atualização.

Durante uma atualização cada base que a recebe vai apresentar a sua própria relação de arquivos órfãos, então o procedimento de remoção ou adequação dos script pode ser feita independentemente para cada uma.

Importante notar que está relação não é de arquivos que ficaram órfãos durante o processo de upgrade, mas sim de todos os arquivos órfãos no sistema, os quais já podem estar nesta situação há mais tempo.

Acessar o processo “Desenvolvimento > Atualização > Atualização do Engine” a partir da base da qual se deseja que a atualização seja enviada.

Preencher os campos com os dados da base de destino.

Após a execução do processo ter sido concluído com sucesso, reiniciar a base de destino para que a atualização seja efetivada.

Esse erro ocorre ao tentar habilitar a criação de chaves CUSTOM na base de desenvolvimento e a mesma possui produtos licenciados incorretamente. Possivelmente há algum produto do sistema licenciado de modo incorreto na base na qual o usuário está tentando habilitar a criação de chaves CUSTOM.

Caso a base de dados não seja utilizada para desenvolvimento de produtos do sistema, pode ser que ela tenha sido copiada a partir de uma base de dados que possuía definições de desenvolvimento de produtos. Nesse caso, é necessário desativar o desenvolvimento desses produtos antes de habilitar a criação de chaves CUSTOM utilizando o processo “Desenvolvimento > Produtos > Faixas de chaves”.

Para habilitar a permissão de um usuário criar chaves custom, acesse “Administração do sistema > Customização > Configuração.” Clique em Inserir, digite o login do usuário e salve as alterações.

Para criar uma chave custom pela IDE clique em “Tools > License to create keys > Custom”. Caso não seja possível alterar o código, clique em “Tools > Enable product changes”.