Versão 71

Novidades

Modernização visual do sistema

O sistema passa a adotar um design mais leve e responsivo baseado no Material Design 3, melhorando a experiência do usuário, em especial em dispositivos com telas menores.

O novo design passa a adotar um padrão de cores configuráveis que permite que o sistema se integre melhor à identidade visual da empresa. Além dos padrões de cores pré-configurados, é possível criar novos padrões de forma simplificada. A seguir são relacionadas as principais novidades.

Nova interface de pesquisa global do sistema

A interface de pesquisa global de dados no sistema foi recriada com o objetivo de proporcionar uma experiência de uso mais dinâmica, responsiva e com melhor desempenho na busca de processos e relatórios do menu, registros cadastrais, logs transacionais e operações do sistema.

Os processos e relatórios acessados recentemente pelo usuário passam a ser exibidos na interface de busca, tornando-a uma alternativa ágil de acesso, dispensando a abertura e navegação no menu do sistema.

Novo menu de processos e relatórios

O menu de processos e relatórios do sistema passa a contar com três modos de exibição:

• Flutuante: abre deslizando sobre a interface do sistema. Não diminui a área útil de exibição dos processos e relatórios, no entanto, deve ser reaberto a cada utilização. Similar ao comportamento do menu anterior do sistema.
• Fixo: exibido de forma permanente na lateral esquerda da interface. Diminui a área útil para exibição dos processos e relatórios, mas torna mais ágil a utilização do menu.
• Compacto: variação do modo fixo projetada para telas menores. Nesse modo, são exibidos apenas os ícones dos módulos.

O usuário passa a poder configurar os seus processos e relatórios favoritos por meio de um novo botão na barra do processo, que passam a ser exibidos com destaque no menu por meio da opção “Acesso rápido”. Nesta opção, os processos e relatórios favoritos passam a poder ser renomeados, reordenados ou agrupados da forma que o usuário achar mais produtiva.

Os módulos do sistema passam a ser exibidos no menu com maior destaque e passam a poder ser fixados a fim de serem exibidos com maior prioridade e na ordem desejada pelo usuário.

Navegação otimizada de abas

A barra de abas de processos e relatórios abertos passa a ser integrada na barra principal e passa a ter maior responsividade e adaptabilidade ao tamanho da tela do navegador.

O usuário passa a poder reordenar as abas, além de poder listar e pesquisar todos os processos e relatórios abertos. Essa funcionalidade torna mais ágil a navegação entre abas, em especial em dispositivos com tamanhos de tela menores ou quando há muitos processos e relatórios abertos.

Menu de perfil do usuário

Foi criado o menu de perfil do usuário com objetivo de agilizar o acesso às configurações pessoais e de segurança do usuário, informações do sistema, bloqueio e encerramento da sessão do usuário.

O novo menu substitui o antigo módulo “Perfil do usuário”, sendo acessível diretamente da barra principal do sistema por meio de um botão que exibe a imagem de perfil do usuário. Essa imagem passa a poder ser capturada diretamente pelo usuário por meio da webcam do seu computador ou da câmera do seu dispositivo.

Integração com soluções externas de chatbot e suporte

O sistema passa a simplificar a integração com soluções externas de chatbot e suporte, permitindo que seja criado um botão customizado na barra principal do sistema que controle a exibição da interface da solução integrada, permitindo o uso dessa solução dentro do sistema.

Inicialmente foram disponibilizadas configurações simplificadas para as soluções da Octadesk, Movidesk, Chatling e Dante AI, sendo essas últimas duas baseadas em ChatGPT. No entanto, outras soluções podem ser integradas via customização.

Melhoria da usabilidade dos botões via atalhos de teclado

Os botões textuais de processos e grades passam a ser acionados via atalhos combinando a tecla de acesso definida para o botão em conjunto com a tecla “Alt” em vez de “Ctrl + Shift”. Essa alteração permite que teclas de acesso mais representativas sejam associadas aos botões, pois o navegador, o sistema operacional e a grade do sistema reservam grande parte das teclas de acesso combinadas com “Ctrl + Shift”.

As teclas associadas a esses botões passam a ser listadas por meio da nova opção “Botões do processo” disponível no menu de ajuda do processo. Essas teclas também passam a ser exibidas na interface do sistema, logo abaixo do botão associado, se a tecla “Alt” for mantida pressionada.

Os demais atalhos de teclado passam a ser documentados por meio da opção “Atalhos do sistema” no menu do perfil do usuário.

Campos do tipo data passam a utilizar um calendário seletor de datas

Todos os campos do tipo “data” que exibam o formato completo da data (DD/MM/AAAA) passam a automaticamente exibir um botão que aciona um calendário para que a data possa ser selecionada de forma visual, respeitando os limites máximos e mínimos do campo.

O calendário apresentado poderá variar de acordo com o navegador utilizado.

Configuração das imagens de plano de fundo do sistema

Passa a ser possível personalizar o ambiente do sistema com imagens de plano de fundo. As imagens configuradas são exibidas quando nenhum processo estiver aberto, proporcionando um ambiente visualmente agradável sem prejudicar a usabilidade das interfaces do sistema. Se mais de uma imagem for configurada, elas serão alternadas automaticamente a cada dia, proporcionando uma experiência visual dinâmica.

Modo de desenvolvimento

No menu de perfil do usuário passa a ser possível ativar o “Modo de desenvolvimento”. Neste modo as chaves são geradas com um dos produtos selecionados pelo usuário (chaves negativas). Com esse modo ativo, é exibido um botão adicional na barra principal do sistema em que é possível alterar o produto para geração das chaves ou desativar o modo de desenvolvimento.

O modo de desenvolvimento substitui o processo “Desenvolvimento > Definir produto para criação de chaves”.

Melhorias de usabilidade nos relatórios

Os relatórios do sistema passam a contar com rótulos de colunas flutuantes, iluminação visual indicativa do nível do agrupamento e apresentação da hierarquia do agrupamento no rodapé da página.

Os rótulos flutuantes são ativados automaticamente com a rolagem da página. Os indicadores de nível e a hierarquia do agrupamento são exibidos de acordo com o posicionamento do mouse sobre agrupamentos, linhas ou totalizadores do relatório.

---

Mais detalhes das novas funcionalidades podem ser consultadas nos manuais abaixo:

• Manual do usuário do sistema
• Ambiente
• Integração com chatbot
• Pesquisa global do sistema

Contas de usuários de suporte

O sistema passa a possibilitar que os acessos dos funcionários e colaboradores do fornecedor do sistema às bases de dados para prestação de suporte sejam geridos de forma diferenciada dos usuários normais do sistema. Para isso foi criado o conceito de conta de usuário de suporte, permitindo maior controle ao administrador do sistema e adicionando um caráter temporário a esse tipo de acesso.

Usuários com esse tipo de conta sempre são autenticados por um provedor de identidade do fornecedor do sistema que garante a autorização desse usuário em acessar a base de dados para a realização de um suporte. O uso dessas contas também requer a autorização do administrador do sistema, que pode realizar essa autorização de forma manual, fluxo recomendado para bases de produção, ou de forma automática em ambientes de desenvolvimento e homologação, se assim o desejar.

Uma conta de suporte distinta é criada para cada usuário que necessite de acesso à base de dados, permitindo a rastreabilidade dos acessos e alterações desse usuário. Contas de suporte não são consideradas para fins de licenciamento, portanto elas não interferem nos controles de quantidade de usuários licenciados.

Mais detalhes no manual Contas de suporte.

Unificação das configurações dos servidores SMTP

A configuração do servidor SMTP no Manage do Engine deixa de existir e o sistema passa a utilizar por padrão as configurações existentes no cadastro “Administração do sistema > E-Mail > Servidores SMTP”. Essa unificação simplifica a configuração do servidor SMTP no sistema e elimina a necessidade de configurar manualmente o SMTP em cada servidor Engine.

Para possibilitar essa unificação, o cadastro de servidores SMTP passa a permitir que sejam informadas as credenciais do usuário SMTP, o nome e o endereço padrão do remetente dos e-mails enviados pelo sistema e também passa a ser possível indicar qual servidor SMTP deve ser utilizado por padrão pelo sistema caso não seja determinado um outro específico no momento do envio do e-mail.

As configurações existentes no Manage serão migradas automaticamente para o cadastro de servidores SMTP durante a atualização para a nova versão do sistema. No entanto, como podem existir configurações distintas nos servidores, é importante que o cadastro de servidores SMTP seja revisto logo após a conclusão da atualização do sistema.

Para o desenvolvedor, a experiência de uso da classe Email também foi revista. A configuração do servidor SMTP passa a ser realizada automaticamente com base no servidor padrão configurado na base de dados ou a partir da chave de um servidor SMTP cadastrado, tornando desnecessária a configuração das demais propriedades relacionadas ao servidor SMTP e do remetente do e-mail. Também foi criado o método Email.prototype.send que unifica e torna obsoletos os métodos Email.prototype.sendLocally, Database.prototype.sendEmail e Connection.prototype.sendEmail. Mais detalhes do uso dessa API na documentação JSDoc da classe Email

Execução de testes pelo VS Code

A extensão passa a contar com a execução de testes unitários e de integração diretamente no ambiente do VS Code. Essa funcionalidade permite que os desenvolvedores executem e monitorem testes pelo próprio editor. Mais informações na documentação da extensão.

Novo painel de resultados no VS Code

A extensão passa a agregar no painel inferior, na aba Engine Results, os resultados das execuções de código, os cálculos de planos de execução e as informações de chave. Dessa forma, todos esses resultados passam a ser apresentados em um local centralizado, sem interferir nos grupos de editores configurados pelo desenvolvedor.

A nova aba possui uma área que exibe um resultado por vez, bem como uma árvore lateral listando os resultados obtidos. Clicar em um item da árvore exibe o resultado correspondente. Se o item for de uma execução de código, clicar nele também abre automaticamente o arquivo de origem, facilitando a navegação e identificação dos arquivos que foram executados.

Mais informações na documentação da extensão.

Compressão de dados utilizando o algoritmo Zstandard

O sistema passa a suportar a compressão e descompressão de dados utilizando o algoritmo Zstandard. Em geral, o algoritmo Zstandard consegue taxas de compressão similares ou melhores que o Zlib, com um custo de processamento menor. Ele também suporta dicionários de compressão, que têm o objetivo de melhorar a taxa da compressão de arquivos pequenos.

O algoritmo Zstandard passa a ser utilizado por padrão na compressão dos campos do tipo “memo” e em novos arquivos armazenados na LobStorage. Foram observados ganhos de desempenho em torno de 40% em testes sintéticos de leitura e gravação de campos “memo”, no entanto, os benefícios dessa alteração devem ser observados em menor grau em cenários reais de uso.

Os caches locais existentes continuarão a utilizar o algoritmo de compressão anterior, sendo necessário a recriação do cache para que eles possam se beneficiar da troca do algoritmo. O algoritmo em uso pode ser consultado nos processos “Administração do sistema > Monitoramento > Engines” e “Administração do sistema > Cache local > Tabelas e índices”.

Mais detalhes na documentação das APIs abaixo:

• Zstd
• ZstdCompressor
• ZstdDecompressor

Alterações significativas

Remoção de APIs de configuração de Temas e Telas de Login

A nova configuração de Temas e Telas de Login tornou obsoletas as APIs internas do Web Framework de personalização e suas classes de dados de configuração. Essas APIs e classes foram removidas do sistema, pois não seria possível manter o funcionamento da API anterior no novo modelo de configuração. Apesar de customizações que utilizem essas APIs serem incomuns, é importante que sejam pesquisados nos códigos-fontes a utilização de todas as classes, propriedades e chaves relacionadas abaixo. Na maioria dos casos, a revisão consistirá em eliminar o uso dessas APIs, classes e registros, devendo no seu lugar ser utilizados os novos processos de configuração disponíveis no módulo “Admin”.

Classes, módulos e propriedades de sessão removidas:

• UserAgent
• Theme
• uwi.personalization.Theme
• uwi.personalization.Environment
• uwi.personalization.Login
• session.frameworkUserAgent
• session.personalization
• session.config.design
• @nginstack/web-framework/keys/UserAgents.js
• @nginstack/web-framework/lib/personalization/Login.js
• @nginstack/web-framework/lib/personalization/Theme.js
• @nginstack/web-framework/lib/personalization/UserAgent.js

Classes de dados removidas:

• Agentes de usuário: -1898142319
• Temas: -1898143349
• Telas de Login: -1892604133
• Ambientes: -1892604132
• Relações entre Agentes de Usuário e Temas: -1898142305
• Relações entre Agentes de Usuário e Login: -1892604140
• Relações entre Agentes de Usuário e Ambiente: -1892604139

Registros removidos:

• Tema Padrão: -1892603868
• Agente de usuário Todos: -1898142316

Importante: a atualização do sistema para a versão 71 ou superior pode requerer a execução de uma segunda atualização para que as colunas obsoletas de configuração de temas e ambiente sejam removidas. Eventuais colunas sugeridas para remoção que estão em uso devem ser ignoradas na primeira execução.

Novas regras para definição do menu de navegação

A análise e identificação dos módulos do novo menu do sistema passam a considerar as regras da classe “Regras para definição da raiz do menu” disponível no caminho “Administração do sistema > Aparência e personalização > Ambiente”. Assim, o Web Framework passará a identificar, por padrão, os módulos a partir do diretório “/Menu”. Caso existam módulos definidos a partir do diretório “/products”, deve-se realizar a migração destes para “/Menu”, alternativamente, pode-se criar uma regra com maior prioridade com o campo “Raiz do menu” configurado com a classe “Raiz”.

O novo menu do sistema também deixa de suportar configurações específicas por usuário em arquivos x-class ou x-view. Portanto, o controle de visibilidade de processos e relatórios deve ser realizado exclusivamente via modelo de permissões do sistema. Dessa forma as seguintes propriedades e métodos do ViewDef e do ModelDef abaixo não poderão mais ser configuradas dentro de condições que testem o usuário da sessão ou os grupos dele:

• canNavigate
• icon
• displayName
• displayOrder
• fileAttributes

Classe XMLHttpRequest deixa de adicionar o charset automaticamente

A classe XMLHttpRequest deixa de adicionar automaticamente o atributo “charset” no cabeçalho “content-type” no envio de conteúdos textuais. Essa alteração tem o objetivo de tornar o sistema compatível com APIs governamentais que não permitem o uso do atributo “charset”, no entanto, ela pode afetar integrações com sistemas que dependem do atributo “charset”, como o próprio Engine. Para manter o comportamento anterior nas integrações existentes é recomendado que seja adicionado manualmente o “charset”, conforme exemplo abaixo:

• xhr.setRequestHeader('Content-Type', 'application/xml') (código original)
• xhr.setRequestHeader('Content-Type', 'application/xml;charset=utf-8') (código revisto)

Esta alteração não afeta conteúdos binários ou do tipo “application/json”, nem conteúdos que não possuem caracteres acentuados ou símbolos além dos definidos no conjunto de caracteres ASCII. Para localizar os eventuais códigos que precisam de revisão, pode ser realizada uma pesquisa utilizando a expressão regular setRequestHeader\s*\(\s*('|")Content-Type('|")\s*,\s*('|")(application\/xml|.*\+xml|text\/.*)('|")\s*\) na extensão Engine DevTools do VS Code.

jQuery deixa de ser incluído no Web Framework

A biblioteca javascript jQuery deixou de ser utilizada no Web Framework e não será mais automaticamente incluída no sistema. Caso existam customizações avançadas que dependam dessa biblioteca, deve ser realizada a inclusão manual da dependência através do processo.

Reorganização do módulo Admin

O módulo “Admin” foi renomeado para “Administração do sistema” e alguns dos seus processos e relatórios foram renomeados e reorganizados na hierarquia do menu. Seguem as alterações mais relevantes:

• “Explorer” foi renomeado e movido para “Classes de dados > Explorador de registros”
• “Classes Explorer” foi renomeado e movido para “Classes de dados > Explorador de classes”
• “Agendador de scripts” foi movido para “Scripts agendados > Agendador de scripts”
• “Importação de documentos ou imagens” foi renomeado e movido para “Armazenamento de arquivos > Importação de arquivos”
• “Desfazer ou refazer alterações” foi renomeado para “Auditoria > Reversão de alterações”
• “Consultar alterações” foi renomeado para “Auditoria > Logs de alterações de registros”

UnionFileSystem passa a diferenciar letras maiúsculas e minúsculas

A UnionFileSystem passa a ser case-sensitive em todas as plataformas suportadas pelo Engine. Dessa forma, diferenças entre letras maiúsculas e minúsculas no caminho dos arquivos importados via require ou __includeOnce passam a gerar erro.

Caso necessário, um modo de compatibilidade pode ser ativado pelo código abaixo, que deve ser adicionado em um script de inicialização do Engine.

if (engine.platform == 'win32') {
  engine.unionFS.enableCaseInsensitiveMode();
}

Importante: o modo de compatibilidade deve ser utilizado apenas como uma estratégia temporária para permitir a revisão das customizações existentes que sejam afetadas por esta mudança de comportamento. Esse modo somente pode ser ativado na plataforma Windows e, enquanto estiver em uso, o sistema não será compatível com outras plataformas que são obrigatoriamente case-sensitive, como o Linux.

Fim do serviço do Engine 32 bits

A versão 32 bits do Engine deixa de ser distribuída a partir da versão 71. Conforme documentação de requisitos do sistema, todos os sistemas operacionais suportados pelo sistema suportam a arquitetura 64 bits, tornando desnecessário e ineficiente o uso do Engine 32 bits.

Com a eliminação do suporte à arquitetura 32 bits, o sistema passa a adotar o nome de executável “engine.exe” na plataforma Windows. Os nomes “engine64.exe”, “engine32.exe” e “iEngine.exe” continuam a ser suportados e migrarão automaticamente para a versão 64 bits. Mesmo com a migração, o nome do executável em uso é preservado a fim de garantir o funcionamento dos serviços e atalhos do Windows, no entanto, é recomendado que as instalações existentes gradualmente passem a adotar o novo nome a fim de facilitar o uso de ferramentas de monitoramento.

Reforçamos que as versões do Windows 7, 8, 8.1 e Server 2012 foram descontinuadas pela Microsoft e não são mais suportadas pelo sistema, nem pelos navegadores Chrome, Edge e Firefox. Devido às alterações significativas realizadas na versão 71, em especial na interface do Web Framework e nos compiladores utilizados na construção do Engine, é esperado que o sistema apresente graves falhas de estabilidade e integridade se ele ainda for utilizado nessas versões do Windows. Para evitar a indisponibilidade do ambiente, é importante que antes da atualização para a versão 71 ou superior seja verificado se todos os servidores e estações clientes atendem os requisitos mínimos para uso do sistema.

Remoção do evento onBlur

O suporte ao evento onBlur dos campos foi descontinuado. Atribuições realizadas a esta propriedade passarão a disparar um erro de forma a evitar que regras de negócio configuradas deixem de ser executadas. O uso desse evento deve obrigatoriamente ser revisto.

Melhorias

Administração do sistema

• O processo “Administração > Armazenamento de arquivos > Importação de arquivos” sofreu um conjunto de melhorias, e agora conta com:

  • Possibilidade de utilizar expressões no formato do nome do arquivo.
  • Variável para definir o separador a ser utilizado na divisão do nome do arquivo ao relacioná-lo com os campos ou expressões do formato escolhido.
  • Opção de tornar um relacionamento como principal no momento de sua criação, caso o tipo de importação possua essa opção.
  • Possibilidade de adicionar e editar conjuntos de campos de pesquisa na tabela “Formato do nome do arquivo”.

  Mais detalhes no manual do processo.

• O processo “Administração do sistema > Licenciamento > Produtos licenciados” passa a não requerer a autenticação como usuário “administrator” para adicionar ou remover licenças caso o usuário logado possua o escopo de autorização para uso da API de licenciamento. Por padrão, usuários do grupo “Administrators” passam a ter esse escopo de autorização.

• O processo “Administração do sistema > Auditoria > Reversão de alterações” passa a permitir consultar sua utilização por meio do botão “Histórico de utilização”.

• Foi criada uma nova opção de configuração dentro do processo “Administração do sistema > Replicação de dados > Registros ignorados” com objetivo de configurar as classes a serem ignoradas na replicação de dados.

• O processo “Administração do sistema > Licenciamento > Utilização do sistema” passa a detectar e sugerir a correção da assinatura de integridade dos registros das contas de usuários com o objetivo de garantir que contas com assinatura inválida não sejam erroneamente contabilizadas como ativas. É importante observar que modificações do tipo, estado ou senha da conta de usuário realizadas diretamente nos registros da tabela de usuários tornam a assinatura inválida, inutilizando a conta, sendo obrigatório o uso da API Security para a realização dessas modificações.

• O processo “Administração do sistema > Monitoramento > Engines” passa a exibir alertas caso os Engines estejam com alta utilização de recursos, sendo executados em sistemas operacionais não suportados ou em servidores com pouca disponibilidade de memória ou de espaço em disco. Mais detalhes no manual Monitoramento de Engines.

• O processo “Administração do sistema > Cache local > Tabelas e índices” passa a permitir a importação e exportação de índices do cache local. Com essa alteração os processos “Administração do sistema > Cache local > Exportar definições de índices” e “Administração do sistema > Cache local > Criar índices a partir do arquivo” foram removidos. Mais detalhes no manual Administração do cache local.

• O processo “Administração do sistema > Cache local > Tabelas e índices” passa a permitir visualizar o histórico de definições de índices do cache local, possibilitando que definições de índices anteriores sejam restauradas. Essa última opção permite acelerar a recriação dos índices após o descarte do cache local.

• A atualização do sistema passa a atualizar os Engines servidores cadastrados no processo “Administração do sistema > Atualização > Endereços de servidores” de forma paralela, tornando mais ágil a atualização do sistema em ambientes com uma quantidade elevada de servidores de aplicação.

• Os alertas de monitoramento dos Engines passam a ser apresentados como tarefas pendentes dos usuários do grupo “Administrators”. Essas notificações podem ser desativadas caso o monitoramento de Engines seja realizado por uma ferramenta externa. Para isso, deve ser utilizada a opção “Exibe alertas como tarefas pendentes” do processo “Administração do sistema > Monitoramento > Configurações”.

• Foi criado o processo “Administração do sistema > Classes de dados > Explorador de arquivos” que permite ao administrador visualizar e manipular os arquivos do sistema de arquivos virtual. Mais informações na documentação do processo.

Desenvolvimento

• O processo “Desenvolvimento > Revisão de códigos > Analisador de dependências” passa a permitir definir os tipos de problemas a serem analisados e a restringir a análise aos arquivos de chave positiva ou do produto Custom. A verificação também passa a ignorar arquivos incluídos por meio de expressões JavaScript.
• Foi criada a configuração “Configuração > Revisão de códigos” com o objetivo de configurar os arquivos e diretórios que devem ser ignorados pelos processos de revisão de códigos.
• A grade “Criação de Licença” do processo “Desenvolvimento > Produtos > Licenciamento > Criação de licença” agora agrupa por empresa as licenças a serem criadas.
• O processo “Desenvolvimento > Configurações gerais > Configurações gerais” passa a possuir filtro por produto e também passa a permitir definir a “Coluna” de cada configuração geral.
• O processo “Desenvolvimento > Atualização > Atualização de tabelas” passa a permitir remover da grade de alterações os registros que não foram modificados na base de dados de origem, tornando mais simples a visualização das alterações a serem enviadas. Ele também passa a identificar os registros removidos na base de dados de origem que ainda não foram excluídos da base destino, permitindo a sua remoção.
• O processo “Desenvolvimento > Atualização > Atualização da VFS” passa a sugerir a inserção e atualização das Resource Strings utilizadas nos códigos-fontes dos arquivos atualizados e também teve a alteração de filtros otimizada.
• Os processos “Atualização do sistema”, “Atualização de tabelas” e “Atualização da VFS” do menu “Desenvolvimento > Atualização” passam a permitir o uso de tokens de autorização para realizar a autenticação nas bases de dados. Este token pode ser criado acessando o processo “Administração do sistema > Atualização > Configuração” e clicando no botão “Criar token de autorização”.
• A API HTTP para atualização de sistema passa a também poder receber tokens de autorização para as bases de dados no lugar de nome de usuário e senha. Mais detalhes na documentação.
• O relatório final de atualização de sistema passa a contar com as seguintes informações:
  • Usuário que realizou a atualização.
  • Versões correntes do engine e do sistema na base destino.
  • Versões da atualização.
  • Data de início e duração da atualização.
• O processo “Desenvolvimento > Testes > Executor de testes” passa a ter a opção de executar testes em arquivos locais do sistema operacional do Engine em execução.
• O processo “Desenvolvimento > Base de dados > Atualização de estrutura” passa a alertar o usuário de alterações de tipos de colunas que exigem a reconstrução da tabela modificada e que podem requerer um tempo elevado de indisponibilidade do sistema.

Engine

• Foi criado o manual Integração com o Java com explicações e exemplos de uso da API Enginelet.
• O sistema passa a exibir uma mensagem de erro mais clara ao tentar remover uma classe que possui diretórios ou arquivos filhos.
• A classe File passa a contar com a propriedade eof, que indica se o final do arquivo foi atingido. Seu uso é recomendado no lugar de comparar os parâmetros position e size, já que consultar a posição pode ser uma operação cara, especialmente nos casos em que a codificação do arquivo é informada no construtor.
• Foi criada a opção filter na função File.listEntries com o objetivo de indicar se um arquivo ou diretório deve ser adicionado no resultado.
• A classe GzipFile passa a contar com a propriedade eof, que indica se o final do arquivo foi atingido.
• O Engine passa a utilizar o alocador de memória “Segment Heap” no Windows caso ele esteja disponível. O “Segment Heap” é um alocador moderno criado pela Microsoft com o objetivo de otimizar o consumo de memória de aplicações nativas. Nos testes preliminares realizados, observou-se um ganho significativo de desempenho, além de uma redução no consumo e na fragmentação da memória alocada pelo sistema. O “Segment Heap” está disponível no Windows 10, Windows Server 2022 e versões superiores. Em versões antigas do Windows, o sistema continuará a utilizar o alocador padrão “NT Heap”, não usufruindo das melhorias do novo alocador.
• O Engine passa a detectar automaticamente o Amazon Corretto 11 e 17 no Windows, sem a necessidade de configurar a variável de ambiente “JAVA_HOME” ou de utilizar o parâmetro de linha de comando “–JavaHome”.
• O Engine passa a detectar o Java instalado no sistema operacional a partir da variável de ambiente “PATH” caso não haja outras configurações disponíveis. Mais detalhes em Integração com o Java.
• Os parâmetros userId e password do método createLicense e o parâmetro administratorPassword do método addLicense da classe LicenseManager passam a ser opcionais. Nos casos em que estes parâmetros são omitidos, será verificado se o usuário logado possui escopo de autorização para uso da API de licenciamento. Por padrão, usuários do grupo “Administrators” passam a ter esse escopo de autorização.
• Foram criadas as propriedades engine.java.home, engine.java.version e engine.java.vendor com informações sobre o runtime Java integrado ao Engine via JNI. Mais detalhes em Engine.prototype.java.
• A classe Java EngineJavaInterface passa a suportar a execução de scripts da Union File System.
• A saída padrão e a de erro do Java passam a ser capturadas e registradas no arquivo “java.log” seguindo as regras definidas na página “Log > Configuration” do Manage. Com essa alteração, as saídas capturadas passam a ser gravadas no arquivo de log com a data e hora da ocorrência e os arquivos de log gerados passam a ser rotacionados automaticamente de forma similar aos demais logs do sistema.
• O sistema passa a contar com uma API HTTP de licenciamento. Mais detalhes na documentação da API.
• Foi criado o método LicenseManager.prototype.removeLicense com o objetivo de remover a licença de um produto do sistema.
• A classe XMLHttpRequest passa a permitir indicar a configuração do servidor proxy a ser utilizado na requisição HTTP.
• A classe Regex passa a contar com a nova sintaxe “SYNTAX_REG_EXP3”, que fornece um uso mais moderno de expressões regulares.
• Foi criada a propriedade Email.prototype.replyToAddress com o objetivo de indicar o endereço para o qual a resposta do e-mail deve ser enviada.
• Foi criado o método Email.prototype.setHeader com o objetivo de definir cabeçalhos adicionais nos emails enviados.
• Foi criada a propriedade Email.prototype.securityMode com o objetivo de indicar o modo de segurança do envio do e-mail, sucedendo as propriedades fullSsl e autoTls.
• Os métodos String.prototype.trimStart e String.prototype.trimEnd passam a estar disponíveis no runtime JavaScript padrão do Engine, conforme especificação ECMAScript 2019.
• Passa a ser possível configurar a diretiva de cache e o controle de acesso dos arquivos da “Lob Storage” armazenados por meio da API FileStorage. Mais detalhes no manual Vincular arquivos a cadastros.
• Foi criado o método Session.prototype.newSessionToken com o objetivo de criar um token de autorização temporário associado à sessão corrente do usuário.
• As APIs HTTP implementadas por meio do Framework REST passam a suportar que o token de autorização seja informado por meio do parâmetro de URL access_token. É importante observar que o token de acesso preferencialmente deve ser enviado no cabeçalho da requisição, evitando assim que o token seja exposto em ferramentas que monitorem ou registrem em log as URLs das requisições. O uso do parâmetro de URL access_token deve ser restrito aos cenários onde não é possível informar o token no cabeçalho da requisição.
• Foi criado o método Database.prototype.parallelQuery com o objetivo de permitir a execução de múltiplas consultas SQL com paralelismo.
• O método Database.prototype.insertLog passa a aceitar duas novas opções:
  • async: Se informada com valor true a inserção do registro de log transacional no banco de dados é realizada de forma assíncrona, sendo executada em segundo plano. Esse modo de inserção permite que rotinas que funcionem com o Engine offline gerem registros de log e também apresenta vantagem de desempenho, pois a rotina não precisa esperar que o log seja gravado no banco de dados. Essa opção não pode ser utilizada em conexões remotas.
  • tag: Permite informar um valor para ser preenchido no campo iTag da tabela de log.
• Foi criado o método Database.prototype.updateLogs com o objetivo de permitir atualizar registros da tabela de log. Inicialmente será possível alterar apenas o campo iFreshTrack da tabela iLog.
• Foram criados os métodos Engine.prototype.isEdgeServer e Database.prototype.isEdgeServer com o objetivo de identificar se o Engine local ou remoto foi configurado como servidor de borda da base de dados.
• Os métodos String.prototype.padStart e String.prototype.padEnd passam a ser definidos via polyfill no runtime JavaScript padrão do Engine conforme especificação ECMAScript 2017.
• A função Object.hasOwn passa a ser definida via polyfill no runtime JavaScript padrão do Engine conforme especificação ECMAScript 2022.
• O monitoramento de Engines passa a poder ser realizado por ferramentas externas por meio da nova API HTTP de monitoramento. Mais detalhes na documentação da API.
• O Engine passa a suprimir a porta do endereço do servidor no cabeçalho “Host” das requisições HTTP sempre que a porta for a padrão para o protocolo utilizado, adotando assim o comportamento observado na maioria dos navegadores. Essa modificação torna mais simples o uso do balanceador de carga HAProxy, pois este por padrão faz distinção dos endereços com e sem a porta.
• Os métodos Response.prototype.write e Response.prototype.writeln passam a suportar valores do tipo Uint8Array e ArrayBuffer.
• Foi criado o método Repository.prototype.getPropertyNames com o objetivo de obter os nomes de todas as propriedades armazenadas no repositório de dados compartilhados do Engine.
• Bases de dados IDO temporárias criadas pelo método IdoDBManager.prototype.createTempDatabase passam a ser mantidas pelo sistema até a finalização do Engine. Este comportamento pode ser modificado pela opção autoDrop. Ao ativar essa opção, o sistema passa a excluir a base de dados automaticamente quando não houver mais instâncias de IdoDB e DataSet que a referenciem.
• Tabelas de bases de dados IDO temporárias deixam de ser removidas automaticamente caso elas tenham sido nomeadas no momento da sua construção por meio do parâmetro tableName do método DataSet.prototype.create. Por padrão, tabelas nomeadas serão mantidas durante o tempo de vida da base de dados temporária, podendo ser removidas de forma antecipada pelo método IdoDB.prototype.dropTable caso seja necessário.
• Foi criada a propriedade Session.prototype.runtime com o objetivo de identificar o runtime JavaScript utilizado pela sessão.
• Foi criada a função match com o objetivo de verificar se uma string corresponde a um padrão de forma equivalente ao método String.prototype.match do runtime JavaScript Ije. Quando não for possível o uso de expressão regulares, deve ser dada preferência a nova função em vez do método da classe String, pois ela também é compatível com o runtime V8.
• Foram criados os métodos estáticos val(), str(), num(), date(), bool() e dbkey() na classe DBKey. Diferentemente dos métodos de instância, eles aceitam que o valor informado de chave seja nulo e retornam valores falsy do tipo esperado de retorno nesse caso.
• Foram criados os métodos val(), str(), num(), date(), bool() e dbkey() na classe Entity de forma análoga aos existentes nas classes DataSet e DBKey.
• A função File.createDirectory passa a criar recursivamente os subdiretórios do caminho informado.
• A classe Socket passa a permitir conexões seguras via protocolo TLS por meio da opção useTls do construtor.
• Foram criadas as propriedades readTimeout e writeTimeout na classe Database com o objetivo de configurar as propriedades de mesmo nome da instância da classe Connection utilizada na conexão à base de dados.
• O menu do Engine passa a contar com a opção “Conectar VS Code”, que abre o VS Code e atualiza o endereço da base de dados para o endereço local do Engine sendo utilizado. Mais informações na documentação da extensão.
• Foi criada a classe LobRecordIterator com o objetivo de permitir a leitura em massa de objetos da LobStorage.
• Foi criada a função uint8ArrayToBinaryString com o objetivo de converter um valor do tipo Uint8Array em uma string no formato conhecido por “Binary String”, onde cada caractere da string representa um byte do conteúdo binário.
• As classes Base64 e Base85 passam a suportar valores do tipo Uint8Array na codificação e decodificação de dados.
• O método addLob() da classe LobStorage passa aceitar valores dos tipos ArrayBuffer e Uint8Array no parâmetro content, facilitando a gravação de dados binários na LobStorage.
• Foi criada a API HTTP /api/devops/v1/update/vfs, com o objetivo de permitir a atualização de arquivos da VFS (Virtual File System) de forma automatizada.
• A função File.fileFromString passa a aceitar os tipos Uint8Array e ArrayBuffer quando gravados arquivos binários.
• Foi criado o tópico Diagnosticando erros de configuração de certificados digitais na base de conhecimento do Engine com o objetivo de auxiliar a resolução de problemas relacionados à configuração de certificados digitais no sistema.

Web Framework

• Foi criada a opção MasterDeleteAction.IGNORE com o objetivo de ignorar os registros das grades detalhe na exclusão de um registro da grade mestre. Ela é útil para os casos em que esses registros são temporários e sua remoção não deve ser persistida na base de dados.
• Foi criada a propriedade Column.prototype.labelTextAlign com o objetivo de configurar o alinhamento dos rótulos das colunas do relatório. Caso essa propriedade não seja informada, as colunas serão alinhadas com base na propriedade textAlign. Se essa última propriedade também não for informada, elas serão alinhadas de acordo com o tipo dos valores escritos na coluna.
• A tela de login passa a apresentar informações sobre o sistema e as novidades da versão no menu “Sobre o sistema”, acessível pelo botão “⋮” ao lado da versão do sistema. As informações apresentadas são:
  • Nome e fornecedor do sistema
  • Base de dados e empresa licenciada
  • Endereço IP do cliente
  • Versões do sistema, Engine e Web Framework
  • Licenças de códigos abertos utilizadas
• A funcionalidade de “Enviar por e-mail” dos relatórios do sistema passa a utilizar por padrão o e-mail do usuário logado como endereço de resposta das mensagens enviadas.
• Foi criada a propriedade SimpleDialog.prototype.autoSanitize com o objetivo de permitir desativar a sanitização padrão que é realizada pelo sistema a fim de prevenir ataques do tipo Cross Site Scripting (XSS).
• O sistema passa a fazer cache das imagens que requerem autorização de acesso, como as imagens de usuários, melhorando a experiência de uso das interfaces que apresentam essas imagens. Esse cache é ativado apenas em conexões seguras, portanto o uso do HTTPS passa a trazer benefícios de desempenho, além dos seus conhecidos benefícios de segurança. Reforçamos que o uso do HTTPS não requer custos adicionais com o uso de certificados emitidos pela Let’s Encrypt. É recomendado o uso de HTTPS em todas as bases de dados, inclusive nas de desenvolvimento e homologação. Mais detalhes no manual Configuração do HTTPS no Engine.
• Ao pressionar a tecla F5 o sistema passa a solicitar a confirmação do usuário caso haja pelo menos uma aba aberta.
• O sistema passa a permitir definir botões customizados na barra principal do sistema. Mais detalhes no manual Botões customizados.
• A barra de botões do processo passa a ter um botão fixo para recarregar o processo, sendo equivalente ao atalho Shift + F5.
• Os campos com controlType configurados com o valor color passam a exibir um botão para seleção da cor de forma visual e uma representação da cor selecionada. Com essa alteração, não é mais necessário realizar a criação de um campo auxiliar para manipular um campo que armazena a cor no formato RGB, sendo suficiente informar a propriedade controlType desse campo com o valor color. É necessária a revisão dos locais que utilizam a propriedade, com a remoção dos campos calculados adicionais que foram criados.
• Foi criada a propriedade FormDialog.prototype.autoSanitize com o objetivo de permitir desativar a sanitização padrão que é realizada pelo sistema a fim de prevenir ataques do tipo Cross Site Scripting (XSS).
• Foi criada a propriedade FormDialog.prototype.content com o objetivo de permitir informar conteúdo adicional no formulário. Este conteúdo será apresentado antes dos campos e logo abaixo do título.
• Foi criada a propriedade FormDialog.prototype.width com o objetivo de permitir informar a largura do formulário.
• Foi criado o evento processError na classe ProcessManager com o objetivo de permitir customizações aplicadas em todos os erros disparados no contexto de execução dos processos e relatórios do sistema.
• Foi criada a propriedade Button.prototype.help com o objetivo de permitir informar a ajuda dos botões dos processos e grades. Essa informação passa a ser exibida nos diálogos de ajuda do processo, da grade e na lista de botões do processo, disponível no menu “Central de ajuda”.
• A exportação de dados da grade para CSV e CSV Excel passa a ter a opção de escolher qual codificação de texto será usada para o aquivo, UTF-8 ou Windows-1252.
• Foi disponibilizada a propriedade Link.prototype.size que possibilita alterar o tamanho da fonte dos links de forma adaptável à densidade visual selecionada pelo usuário.
• A tela de login passa a utilizar o tema padrão do sistema com o objetivo de criar um padrão visual coeso do sistema. Caso necessário, ainda será possível configurar um tema específico para a tela de login em “Administração do sistema > Aparência e Personalização > Tela de login”. A nova configuração de tema substitui a configuração individual de cores e por esse motivo foram removidas as configurações gerais abaixo:
  • wf.login.colors.surface
  • wf.login.colors.background
  • wf.login.colors.error
  • wf.login.colors.link
  • wf.login.colors.onError
  • wf.login.colors.onPrimary
  • wf.login.colors.onSecondary
  • wf.login.colors.onSurface
  • wf.login.colors.primary
  • wf.login.colors.secondary
  • wf.login.colors.surface
• Foram criados os métodos de navegação first, next, prior, last, gotoBookmark, tryGotoBookmark, gotoRowId e tryGotoRowId na classe Grid com o objetivo simplificar a navegação na grade de forma programática.
• As classes Label, Link, ECharts e SimpleLayout passam a suportar o gerenciador de leiaute do processo, permitindo que eles possam ser apresentados lado a lado com outros componentes, entre eles a grade. A configuração da apresentação do componente deve ser realizada por meio da propriedade layout desses componentes. As propriedades column, span e breakLine da classe Grid passam a ser mantidas apenas para fins de compatibilidade, sendo recomendado o uso da nova propriedade Grid.prototype.layout. Exemplo:

  grid.layout.column = 1;
  grid.write();
  
  label.layout.column = 2;
  label.write();
  

• Foi criada a propriedade SimpleLayout.prototype.staticMode com o objetivo de desativar as funcionalidades do SimpleLayout que dependem do Web Framework, permitindo que ele possa ser renderizado fora do sistema, como em clientes de e-mail e em conversores de HTML para PDF.

Extensão VS Code

• A extensão passa a contar com o comando Engine DevTools: Use Recommended Settings, que lista as configurações recomendadas para o seu uso e dá a opção de ativá-las.
• Passa a ser possível sincronizar o cache local através do comando Engine DevTools: Synchronize Local Cache, ou acessando essa opção pelo menu de contexto da base de dados.
• A extensão passa a contar com a abertura do Engine Manage e do sistema no browser. Mais informações na documentação da extensão.
• A extensão passa a contar com a opção de configurar múltiplos endereços de servidor por base de dados. Mais informações na documentação da extensão.
• O desenvolvedor passa a poder configurar na classe “/Configuração/DevTools/Pesquisa” (-1891603334) uma lista de arquivos a serem ignorados na pesquisa textual da extensão. Também é possível escolher no momento da pesquisa se essa configuração será utilizada ou não. Mais informações na documentação da extensão.
• Passa a ser possível ordenar as bases de dados no grupo de bases ativas.
• A extensão passa a contar com os comandos Engine DevTools: Run Current Line on Engine (Ctrl+E L) e Engine DevTools: Run Current Line on Engine (New) (Ctrl+E Shift+L), que permitem a execução da linha de código onde está posicionado o cursor, reutilizando uma instância de execução ou forçando a abertura de uma nova instância, respectivamente.
• A exportação de dados da grade passa a ter a opção de escolher qual codificação de texto será usada para o aquivo, UTF-8 ou Windows-1252. Cada formato de exportação pode ser configurado para ter uma codificação padrão ou sempre perguntar a codificação ao usuário.

Defeitos corrigidos

Administração do sistema

• Ao consultar os eventos de erro no relatório “Administração do sistema > Auditoria > Eventos de erro” poderia ocorrer o erro “trailing junk after numeric literal at or near”.
• O processo de Replicação de Dados poderia deixar as contas de usuários em um estado inconsistente nas bases de dados destino após a modificação da senha dos usuários na origem.
• Ao replicar permissões utilizando o botão “Replicar nas classes filhas” no processo “Administração do sistema > Segurança > Permissões > Permissões” ocorria a limpeza dos campos de permissões das classes filhas que não eram visíveis na classe mãe. O sistema passa agora a copiar apenas os campos de permissões configurados para serem replicados e que estejam visíveis na classe utilizada como base da replicação.
• Ao alterar a senha de um usuário no processo “Administração do sistema > Segurança > Grupos, papéis e usuários > Usuários” poderia ocorrer uma inconsistência na grade de preenchimento da nova senha caso essa operação fosse realizada em vários usuários.

Desenvolvimento

• O processo “Desenvolvimento > Produtos > Licenciamento > Criação de licença” poderia, para certas entradas, gerar um valor inválido, ocasionando erro ao aplicar a licença na base de destino.
• A replicação de dados falhava no momento de remover as relações órfãs e as configurações de origem inválidas.
• O processo “Desenvolvimento > Atualização > Atualização da VFS” apresentava erro caso um arquivo com ação “Nenhum” estivesse selecionado ao prosseguir com a atualização. Isto acontecia quando uma inserção era ignorada por meio do fluxo de merge, ao salvar o conteúdo do arquivo origem como vazio.
• O processo “Desenvolvimento > Base de dados > Migração > Criar cópia” poderia falhar se houvesse uma tabela com nome similar a “iLog”.

Engine

• O Engine poderia travar caso um aplicativo externo, como um antivírus, bloqueasse a criação ou escrita do arquivo temporário criado pelo sistema durante a execução do método Scheduler.prototype.getTasks.
• As abas da IDE do Engine não eram reordenadas ao serem arrastadas.
• O sistema sempre permitia alteração de chaves do produto caso a chave pertencesse a um produto listado nas Changeable Licenses do usuário, mesmo quando a base não estivesse habilitada para desenvolvimento.
• O sistema poderia gerar uma quantidade excessiva de logs caso o Engine atingisse o limite de arquivos abertos imposto pelo sistema operacional.
• Ao gravar um arquivo “x-class” na classe “Raiz” na IDE do Engine ocorria o erro “sourceFile has no properties” se fosse registrado um listener usando a API legada de eventos.
• O Engine poderia dar preferência ao runtime Java 8 em detrimento de outras versões mais recentes do Java instaladas, mesmo que a versão 8 não fosse a instalação padrão.
• O método runScript da classe Java EngineJavaInterface ignorava os erros ocorridos durante a execução do script. Agora os erros passam a ser registrados no arquivo “main.log” e o método runScript passa a lançar os erros corretamente no ambiente Java em vez de retornar null.
• O sistema permitia efetuar login via provedor de identidade mesmo se a base não estivesse licenciada.
• Os métodos Connection.prototype.createKey e Database.prototype.createKey não validavam se a quantidade de chaves informada era positiva. Informar um valor negativo poderia provocar a geração de chaves duplicadas.
• As redefinições de senhas de usuários realizadas na tela de login não eram consideradas na verificação de reuso de senhas do sistema.
• A classe XMLHttpRequest ignorava a variável de ambiente ENGINE_PROXY e a opção de linha de comando --NoProxy.
• O método Classes.prototype.getRemoteChildren poderia travar caso houvesse uma classe na base de dados remota que não existisse na base corrente.
• Ao mover um arquivo utilizando o método VirtualFileSystem.prototype.moveFile poderia ser criado um registro na iVfsLob de chave positiva associado a um arquivo de um produto, de chave negativa.
• A validação das regras de formação de senha não considerava o “@” como símbolo.
• Erros ocorridos no Engine servidor poderiam ser exibidos com uma mensagem genérica quando utilizado HTTPS através do Google Cloud Load Balancing.
• Logins realizados por meio de provedores de identidade não estavam sendo registrados no log para fins de auditoria.
• A coluna Workload na página de monitoramento de requisições do Manage não apresentava o tipo de carga informado na propriedade Database.prototype.workloadType ou na opção workloadType do método Database.prototype.query.
• O login na IDE do Engine falhava caso houvesse um provedor de identidade cadastrado com um código contendo espaços ou símbolos especiais.
• O applyUpdates de múltiplos DataSets poderia falhar com o erro genérico “Request failure” caso a gravação das alterações de um dos DataSets levasse mais que 10 minutos. Por padrão, esse limite passa a ser de uma hora e a mensagem de erro passa a indicar se a falha foi provocada por um erro de timeout na leitura ou escrita dos dados.
• A função parseDate poderia falhar caso o dia corrente fosse o último dia de fevereiro de um ano bissexto.
• A propriedade Number.MAX_VALUE retornava indevidamente um valor equivalente a Infinity.
• Ao utilizar argumentos do tipo DBKey nos métodos da classe ScriptRunner ocorria o erro “Invalid Variant to JSValue conversion”.
• A navegação em DataSets originados a partir do cache local poderia travar caso fosse utilizado um índice com expressão lookup e houvesse uma transação de escrita concorrente.
• Login via provedor de identidade não funcionava com a versão mais recente do Keycloak.
• O método Database.loginBySession poderia não verificar se o nome da base de dados coincidia com o da sessão.
• A instalação do Engine como serviço falhava se o nome do serviço contivesse um espaço.
• A função incDate incrementava a data em um dia caso o parâmetro days fosse informado com o valor 0.
• A função JSON.stringify retornava o valor 'null' em vez de undefined quando o valor a ser serializado era uma função ou indefinido.
• A propriedade engine.arch retornava o valor 'x32' em vez de 'ia32' na arquitetura Intel x86 32 bits.
• O método DataSet.prototype.iterate alocava memória desnecessária no runtime JavaScript Ije e poderia provocar o esgotamento da memória do servidor caso fosse utilizado em DataSets com quantidades muito elevadas de registros.
• O método [Base64.decode] retornava undefined em vez de uma string vazia caso fosse informado um conteúdo vazio a ser decodificado.
• O delta de alterações de um DataSet era descartado silenciosamente caso fosse adicionado um campo após o DataSet ter sido modificado. O sistema passa a impedir a modificação do esquema de um DataSet caso haja alterações pendentes de efetivação, sendo recomendado que as modificações de definições de campos ocorram antes de qualquer alteração ou logo após um applyUpdates.
• A função File.createDirectory falhava caso fosse informado um caminho de diretório relativo.
• A propriedade Session.prototype.application não era inicializada corretamente em sessões Stateful criadas pela classe ScriptRunner.
• As rotas HTTP definidas em arquivos locais da Union File System poderiam não estar disponíveis logo após a inicialização do Engine.
• Ao cancelar a inserção de um registro, o DataSet poderia não retornar à posição anterior.
• O Engine poderia parar de funcionar caso fosse informada a própria instância do DataSet como parâmetro dos métodos copy() e copyStructure.
• O método Scheduler.prototype.getTasks poderia falhar com o erro “Nenhum registro disponível” caso tarefas fossem removidas durante a sua execução.

Extensão VS Code

• Ao salvar um arquivo de definição de classe, a extensão não checava a existência de erros de definição no código.
• A grade de resultado da execução de script apresentava os campos sem limitação de largura na exibição inicial, dificultando a visualização quando havia campos com conteúdo muito extenso.
• A cópia de uma célula da grade de resultados utilizando “Ctrl+C” não preservava os saltos de linha.
• A busca textual utilizando expressões regulares interpretava todo o conteúdo do arquivo como uma só linha ao invés de procurar correspondências em cada linha separadamente.
• Ao excluir uma variável na view de variáveis, sempre a última da lista estava sendo excluída no lugar da escolhida.
• A execução de código tentava manter a sessão viva desnecessariamente, quando ela ainda estava em uso. Isto gerava erro em uma execução mais longa.
• A exportação de registros selecionados da grade para CSV ou TSV criava um arquivo vazio.
• A apresentação dos nomes de usuário no histórico de alteração da Virtual File System exibia as setas da barra de rolagem indevidamente.
• As requisições HTTP/HTTPS executadas pela extensão poderiam ter a URL resolvida para um endereço IPv6, que é um protocolo ainda não suportado nativamente pelo sistema.

Web Framework

• As colunas dos relatórios poderiam ser agrupadas incorretamente caso uma coluna de um grupo tivesse a propriedade visible definida com o valor false.
• Os eventos beforeDelete e afterDelete de registros detalhes eram disparados indevidamente no momento da exclusão de um registro da grade mestre mesmo se a opção masterDeleteAction da grade detalhe não fosse MasterDeleteAction.DELETE. Caso estivesse com essa configuração, os eventos eram disparados em duplicidade.
• Os elementos da tela de login poderiam ser apresentados de forma sobreposta em dispositivos móveis.
• Campos do tipo booleano das grades criadas com a função newSettingsGrid não atualizavam corretamente a configuração geral para falso caso o valor padrão fosse verdadeiro.
• Ao pressionar a tecla “Tab” em campos com o tipo date em grades de variáveis, o foco poderia retornar indevidamente ao campo.
• Ao pressionar a tecla “Tab” em um campo com lookup o foco era direcionado para um botão do navegador, após a grade de lookup ser exibida na tela.
• Campos com a propriedade hasInformedControl ativa eram apresentados com uma largura levemente superior à configurada, dificultando o alinhamento dos campos.
• O sincronismo da grade poderia falhar caso o redirecionamento de um processo para outro fosse interrompido com um erro.
• Ao “cancelar” uma grade de lookup de campos do tipo combo em modo formulário, não era restaurado o valor anterior à abertura da grade lookup.
• A tela de login compacta projetada para dispositivos móveis de baixa resolução poderia ser apresentada indevidamente em telas maiores caso a opção de escala de resolução do Windows estivesse ativa.
• A barra de ferramentas da grade detalhe poderia não ser ocultada caso a propriedade grid.toolbar.visible fosse definida com o valor false.
• O upload de arquivos poderia falhar caso o nome do arquivo contivesse símbolos.
• Todos os erros gerados durante a execução de um script via executeScript eram considerados inseguros e suas mensagens eram suprimidas para os usuários sem permissão de ver os detalhes técnicos das mensagens de erro.
• O uso do método Process.prototype.write antes da escrita da primeira grade impedia a renderização de grades lado a lado.
• Os eventos beforeChange e afterChange poderiam não ser emitidos corretamente na alteração de campos logo após a execução do método Grid.prototype.scroll.
• As tarefas pendentes criadas pelos scripts “x-pendingTask” (.ipt) não eram atualizadas pelo sistema após a sua criação.
• Ao avançar para uma próxima ocorrência na pesquisa da grade poderiam ser exibidas ocorrências já apresentadas anteriormente.
• A posição da grade poderia ser perdida após a execução do método Grid.prototype.refresh.

Outras alterações

Administração do sistema

• O processo “Administração do sistema > E-Mail > Testar servidor SMTP” deixa de existir e sua funcionalidade foi incorporada no processo “Administração do sistema > E-mail > Servidores SMTP” por meio do botão “Enviar e-mail de teste”.
• O processo “Administração do sistema > Segurança > Políticas de segurança > Provedores de identidade” foi movido para o caminho “Administração do sistema > Segurança > Provedores de identidade”.
• As imagens vinculadas aos usuários passam a ser gravadas na classe de dados “/Dados/Sistema/Large Objects/Imagens de usuários”. A antiga classe de dados “/Dados/Arquivos/Imagens/Imagens de usuários” foi removida e os eventuais arquivos vinculados aos usuários foram migrados para a nova classe de dados. Como consequência, o acesso às imagens de usuários deixa de ser público e passa a exigir um token de autenticação.
• Foi removido o botão “Configurar telas customizadas” do processo “Administração do sistema > Aparência e Personalização > Tela de login”. A customização de uma nova página de login passa a ser realizada via arquivo de configuração no diretório “/Configuração/Web Framework/Login”. Mais detalhes no manual Tela de login.
• O uso do processo “Administração do sistema > Segurança > Grupos, papéis e usuários > Usuários” era restrito para usuários do grupo “Administrators”. Essa exigência foi eliminada, permitindo um controle mais granular do acesso a este processo pelo modelo de permissões do sistema.
• O processo “Administração do sistema > Servidores > Engines servidores” foi movido para “Administração do sistema > Atualização > Endereços de servidores” e sua finalidade foi restringida a indicar os endereços dos servidores que devem ser atualizados automaticamente pelo processo “Atualização do sistema”.
• O processo “Administração do sistema > Servidores > Serviços” foi removido. Em seu lugar devem ser utilizados processos que apresentem uma visão sobre os tipos de serviços específicos como “Administração do sistema > E-mail > Servidores SMTP” ou “Administração do sistema > Serviços em nuvem > Armazenamento de objetos”.
• O relatório “Administração do sistema > Segurança > Permissões > Permissões do grupo” foi removido, sendo recomendado o uso do “Administração do sistema > Segurança > Permissões > Análise de permissões” como substituto.

Desenvolvimento

• O processo legado “Desenvolvimento > Configurar monitor de Engines” foi removido, assim como as classes de dados relacionadas a esse processo. O monitoramento dos Engines pode ser realizado por meio do processo “Administração do sistema > Monitoramento > Engines” na versão atual do sistema.
• O processo “Executor de testes” foi movido para “Desenvolvimento > Testes > Executor de testes”.
• O processo “Análise do log do Profiler” foi renomeado e movido para “Desenvolvimento > Profiler > Analisador de logs do Profiler”.
• O processo “Sincronizar permissões de papéis” foi renomeado para “Atualização de permissões de papéis”.
• O processo “Sincronizar configurações gerais” foi renomeado para “Atualização de configurações gerais”.
• As classes legadas sld.git.Git e sdl.git.GitRepository foram removidas do sistema. Para consultar e manipular repositórios Git locais, é recomendado que sejam criados scripts que utilizem diretamente o aplicativo de linha de comando git.
• No processo “Desenvolvimento > Build do sistema > Configuração” foram realizadas as seguintes alterações:
  • O grupo de configurações “Base escrava” foi renomeado para “Base de testes”, tornando mais claro o papel da base de dados no processo de build.
  • A autenticação das bases de dados durante o processo de build passa a utilizar tokens de autorização em vez de credenciais de usuários. As credenciais existentes serão descartadas, sendo necessária a reautorização das bases de dados configuradas. Antes dessa reconfiguração, será necessário atualizar as base de dados de teste e destino manualmente via processo “Desenvolvimento > Atualização > Atualização do sistema”.
  • Passa a ser necessário registrar os escopos de autorização requeridos pelos testes unitários e de integração na propriedade “requiredAuthScopes” da configuração “/Configuração/Testes” (-1891604183). Após a modificação dessa propriedade será necessário reautorizar a base de testes na configuração do build.

Engine

• As APIs de integração do Engine com o Java passam a requerer o runtime Java 8 ou superior.

• O método JavaImporter.prototype.getClassesFromPackages foi removido, pois ele fazia uso de APIs internas do Java que não existem mais no Java 9 ou superior.

• O método JavaImporter.prototype.importJavaBean deixa de suportar a possibilidade de informar um pacote Java, sendo agora restrito ao uso de classes Java. Dessa forma, o método passa a sempre retornar uma string em vez um array de strings.

• Foram realizadas as seguintes alterações nas classes Java de integração com o Engine:

  • A classe “com.nginstack.engine.enginelet.Enginelet” foi movida para “com.nginstack.engine.Enginelet”.
  • A classe “com.nginstack.engine.enginelet.EngineJavaInterface” foi movida para “com.nginstack.engine.EngineJavaInterface”.

  Os caminhos anteriores das classes foram mantidos para fins de compatibilidade.

• A funcionalidade de publicação de serviços Java por meio da classe global JavaServer foi descontinuada na plataforma. A publicação de serviços web Java continua sendo possível, no entanto ela deve ser realizada por meio de uma classe Enginelet customizada. Com essa alteração, todas as bibliotecas Java do diretório javalibs do Engine foram migradas para o produto Erp Core. Elas serão eliminadas no futuro, na medida em que os serviços web Java forem substituídos por rotas HTTP.

• O limite de tamanho dos valores gravados em colunas do tipo CLOB foi alterado de 88MB para 256MB. Esse limite passa a também ser validado na gravação dos registros na base de dados, garantindo que os registros gravados possam ser lidos posteriormente pelo sistema. O limite corrente do sistema passa a estar disponível na constante Limits.MAX_CLOB_SIZE.

• O antigo protocolo de comunicação entre Engines raw Iap, que não usava o HTTP, deixa de ser suportado pelo sistema. Eventuais URLs que iniciem com o esquema “iap://” passa a ser tratadas com o esquema “http://”.

• A funcionalidade de backup automático do cache local do Engine que havia sido desativada por padrão na versão 52 foi removida do sistema de forma definitiva. Com essa alteração, a variável de ambiente “NGIN_DBCACHE_AUTO_BKP”, a opção de linha de comando “–EnableDBCacheBackup” e as opções “BackupSchedule” e “MaxBackupInterval” da configuração “Other” do Manage passam a ser ignoradas pelo Engine. Para garantir a redundância e alta disponibilidade dos Engines, é recomendado que se utilize mais de uma instância do Engine. Mais detalhes sobre esse assunto podem ser observados no manual Alta disponibilidade.

• As propriedades remoteAddress, remoteHost e remotePort da classe Socket passam a ser somente para leitura e os métodos read, readln, peek e write passam a ter um timeout padrão de 60 segundos.

• O grupo “Todos” deixa de incluir o usuário “anonymous” por padrão e passa a representar todos os usuários autenticados do sistema.

• A quantidade máxima de campos por tabela suportada pela classe DataSet foi incrementada de 1022 para 2046. O limite corrente passa a estar disponível na constante DataSet.MAX_FIELDS_PER_TABLE.

• O registro de login e logout de usuários nos logs transacionais passa a ser configurado pela nova propriedade “loginAuditingEnabled” na configuração de realms localizada em “/Configuração/Realms”. Por padrão, apenas as sessões de usuários do Web Framework passam a ter esse controle ativo. Aplicações desenvolvidas no sistema com o uso de sessões stateful precisam ter a sua configuração de realm revista caso seja necessário o registro de logins de usuários para fins de auditoria. Mais detalhes em RealmConfig.prototype.loginAuditingEnabled e SessionConfiguration.prototype.loginAuditingEnabled.

• O Engine deixa de suportar a opção de comando de linha “–RetentiveDNSCache”. Essa opção ativava uma implementação legada do cache de DNS que poderia gerar comportamentos incorretos no sistema.

• As propriedades log e logEnabled da classe Email foram descontinuadas e passam a sempre retornar uma string vazia e false. Os logs de envio de e-mail devem ser lidos no Engine responsável pelo envio ou na tabela de log transacional (iLog).

• O método Connection.prototype.getDatabaseNames passa a retornar os nomes das bases de dados configuradas em um Engine servidor de borda.

• O Engine deixa de dar suporte às seguintes versões de SGBDs que foram descontinuadas pelos seus fornecedores:

  • PostgreSQL 10 e 11. Versão 12 passa a ser a mínima requerida.
  • Oracle 12g. Versão 19c passa a ser a mínima requerida.

• O sistema passa a ser compatível apenas com o Microsoft SQL Server 2019 ou superior, descontinuando o suporte da versão 2017. Mais detalhes em requisitos do sistema.

• O tamanho máximo do nome dos identificadores no banco de dados foi alterado de 30 para 63 (limite atual do PostgreSQL). Com essa alteração, o sistema passa a sugerir nomes mais explicativos para os índices criados a partir da definição do modelo de dados. A operação de renomear índices não possui um custo de processamento significativo e será sugerida durante a atualização do sistema.

• A API checkRange foi renomeada para checkDateRange e passa a desconsiderar as horas entre as datas por padrão.

• A propriedade Scheduler.prototype.maxSimultaneousTasks foi renomeada para maxConcurrentTaskCount. O nome anterior continua a ser suportado para fins de compatibilidade com os códigos existentes.

• O sistema passa a impedir a modificação de DataSets do cache local originados de tabelas configuradas para não terem os seus dados replicados no cache (cachedData = false). O sistema mantém essas tabelas sem registros no cache a fim de permitir que o desenvolvedor crie DataSets temporários dessas tabelas sem a necessidade de realizar consultas na base de dados. No entanto, alguns códigos erroneamente inseriam registros diretamente nas tabelas vazias que são mantidas no cache, o que poderia gerar um problema de integridade. A partir desta versão, essas alterações passarão a ser bloqueadas com o erro “Cannot modify a read-only dataset”. Os eventuais registros inseridos nas versões anteriores passarão a ser excluídos automaticamente na inicialização do sistema.

• As API legadas dos leitores de código de barra SymbolCS1504 e SymbolCS2000 foram removidas do sistema.

• A classe SerialPort sofreu as seguintes alterações:

  • Os timeouts foram unificados nas propriedades readTimeout e writeTimeout. As propriedades readIntervalTimeout, readTotalTimeoutMultiplier, readTotalTimeoutConstant, writeTotalTimeoutMultiplier e writeTotalTimeoutConstant passam a ser deprecated.
  • O construtor passa a admitir como primeiro parâmetro uma string com o nome da porta. Este parâmetro ainda aceita apenas o número da porta a fim de manter a compatibilidade.
  • O uso avançado de controle de fluxo de hardware passa a ser feito com os métodos getCTS, setRTS, getDSR e setDTR.
  • Foram eliminadas as seguintes propriedades: dtr, rts, outDsrFlow, dsrSensitivity, xOnChar, xOffChar, replaceCharOnParityError e parityErrorChar.

• O modo estrito passa a ser ativo por padrão no runtime JavaScript V8.

• As APIs do Engine passam a retornar chaves como valores do tipo number em vez de DBKey no runtime JavaScript V8. O manual Boas práticas passa a conter recomendações de uso da classe DBKey.

• A classe legada GenericBarCodeScanner foi removida do sistema. O seu uso era desnecessário com os leitores de código de barra atuais.

• Foram removidas as propriedades fullResult e resultString da classe Pop3 e o método login passa a dar erro caso ocorra falha na autenticação.

• A classe OpenSSL incluída via biblioteca “ufs:/ngin/util/OpenSSL.js” foi removida. No seu lugar deve ser utilizada a classe CryptoPKey.

• A instalação da versão Linux do Engine passa a ser permitida em qualquer base de dados. O suporte ao Linux ainda é considerado experimental e mais detalhes podem ser obtidos no manual Suporte ao Linux.

• O terceiro parâmetro opcional opt_transferEncoding dos métodos addPageContent e addResourceContent da classe HtmlToPdf foi eliminado, tornando obrigatório que o conteúdo informado nesses métodos seja o original, sem uma codificação prévia.

• O sistema passa a utilizar o Microsoft Visual C++ Runtime 2022 no Windows. Esse runtime é distribuído com o Engine, mas, para o seu correto funcionamento, é necessário que o componente Universal C Runtime do Windows esteja atualizado. Para isso, o Windows Update deve estar ativo e sendo executado periodicamente.

• O Engine passa a utilizar o compilador GCC 13 na versão Linux. A versão mínima da glibc requerida pelo sistema passa a ser a 2.39.

• A biblioteca OpenSSL foi atualizada para a versão 3.0.16.

• A biblioteca zlib foi atualizada para a versão 1.3.1.

• A biblioteca “libpq” utilizada no acesso ao PostgreSQL foi atualizada para a versão 16.8.

• A biblioteca Qt foi atualizada para a versão 5.15.16.

Extensão VS Code

• Foram alterados os seguintes comandos:
  • Abort Execution on Engine remapeado para Ctrl+E Shift+B.
  • Run on Engine (New Tab) e Run Selection on Engine (New Tab) renomeados para Run on Engine (New) e Run Selection on Engine (New) e remapeados para Ctrl+E Shift+R.
  • Rerun on Engine passa a não ter keybinding por padrão.
  • Update From remapeado para Ctrl+E Shift+U.
• Foi realizada a migração da extensão para o ESLint 9, que passa a utilizar o padrão de configuração flat. Os desenvolvedores devem atualizar o ESLint e instalar globalmente o plugin @stylistic/eslint-plugin em suas máquinas. Bases com configurações de ESLint customizadas devem utilizar um arquivo eslint.config.js na raiz da VFS. Arquivos eslintrc passam a ser ignorados pela extensão. Mais detalhes na documentação.

Web Framework

• O processo “Administração do sistema > Aparência e personalização > Ambientes” foi renomeado para “Ambiente”. Não é mais suportada a criação de ambientes customizados por grupos de usuários ou navegadores. Essas configurações foram substituídas por novas parametrizações gerais que se aplicam a todos os usuários.
• A propriedade Column.prototype.column passa a ser considerada legada. Esta propriedade não deve ser utilizada em novos relatórios e sua utilização deve ser gradualmente eliminada, pois ela deverá ser eliminada no futuro.
• A propriedade useEngineSmtpServer da configuração Configuração > Web Framework > Ambiente deixa de existir e a configuração do servidor padrão passa a ser realizada no cadastro “Administração do sistema > E-mail > Servidores SMTP”.
• Os campos “Nome do usuário SMTP” e “Senha do usuário SMTP” foram removidos dos cadastros de grupos, papéis e usuários do sistema. A configuração das credenciais de acesso ao servidor SMTP passa a ser realizada exclusivamente no cadastro “Administração do sistema > E-mail > Servidores SMTP”.
• A classe “Perfil do usuário” foi removida do menu do sistema e seus processos foram incorporados ao novo menu “Perfil do usuário” na barra principal. É necessário mover eventuais processos filhos customizados da classe “Perfil do usuário” para outra classe do menu do sistema.
• Com a nova versão do menu principal, a funcionalidade de controle de visibilidade de itens do menu e as propriedades tooltip e defaultProcess da classe ViewDef foram descontinuadas e não são mais suportadas no sistema. Devido a isso, a coluna “Itens visíveis” do grupo “Menu de navegação” da grade de “Usuários” deixa de ser relevante e foi removida.
• As grades de vínculos de cadastros com arquivos, definidas pelas classes filhas de “Relações entre cadastros e arquivos” (-1898141863), passam a remover os arquivos da Virtual File System e da Lob Storage durante a remoção de registros, caso eles não sejam vinculados a nenhum outro registro.
• Foi criado o escopo de autorização api.webFramework para permitir a construção de tokens de autorização restritos às APIs de uso interno do Web Framework. Esse escopo é atribuído automaticamente para todos os usuários do sistema e sua criação não afeta o controle de acesso ao ambiente do Web Framework que continua a ser controlado pela “Política de Segurança” do usuário.
• O campo “Atalhos” foi removido dos cadastros de grupos, papéis e usuários do sistema. Os dados que estavam cadastrados no campo foram migrados como registros na classe “Favoritos” para cada usuário que tivesse o atalho. A configuração de atalhos para processos e relatórios passa a ser realizada diretamente pelo usuário utilizando o botão “Adicionar aos favoritos” ou “Remover favorito” no respectivo processo ou relatório.
• As propriedades autoShortcutKeyMode e showFriendlyFrameworkErrors da classe “/Configuração/Web Framework/Ambiente” deixam de ser suportadas pelo sistema.
• A propriedade tableViewHeight da classe ViewDefField foi removida e não é mais suportada. Para alterar a altura e largura máximas de imagens em campos com o controlType “image” devem ser utilizadas as propriedades zoomMaxHeight e zoomMaxWidth respectivamente.
• A propriedade iconPath da classe de eventos GetTreeIconEvent foi substituída pela propriedade icon e passa a aceitar apenas identificadores de ícones da biblioteca de ícones do Web Framework. Mais detalhes podem ser obtidos no manual Ícones.
• Campos do tipo “radio” não serão mais suportados em diálogos FormDialog, o seu uso passa a ser substituído pelo tipo “combo” sem necessidade de revisão dos códigos.
• Campos do tipo “date” serão alinhados à direita por padrão. O alinhamento do campo pode ser modificado pela propriedade alignment da classe ViewDefField.
• O método prompt da classe Process teve sua API alterada para receber um objeto literal como terceiro parâmetro com as configurações adicionais do diálogo. O método continua aceitando a API anterior, com as seguintes ressalvas:
  • o parâmetro opt_verticalAlign foi descontinuado e será ignorado. A apresentação das opções sempre será na vertical utilizando botões de seleção do tipo radio.
  • ao informar o parâmetro opt_defaultOptionIndex o item configurado neste índice virá automaticamente marcado.
  • ao informar o parâmetro opt_escapeIndex o item configurado neste índice será removido da lista de respostas possíveis e será incluído no diálogo o botão “Cancelar” e o tratamento para a tecla escape. Não será possível personalizar o rótulo do botão de cancelamento.
• Com a alteração estrutural do diálogo de ajuda, recomendamos que seja realizada uma revisão de conteúdo e estilo dos textos de ajuda do processo, dos botões, das grades e dos campos, atentando-se principalmente, mas não exclusivamente, à não existência de texto de ajuda, ao uso de salto de linha (\n) e ao uso de conteúdo HTML, pois poderá haver impactos visuais no conteúdo.
• A biblioteca “ECharts” foi atualizada para a versão 5.6.0.
• Os componentes textuais automáticos dos gráficos da biblioteca “ECharts” passam a ser traduzidos para português do Brasil.
• Os gráficos da biblioteca “ECharts” passam a exibir o tooltip das séries, bem como a opção “Salvar como imagem” de forma padrão. Ambos os comportamentos podem ser desligados individualmente nas opções de configuração do gráfico.
• Com a adoção do sistema de densidade visual variável e dos temas configuráveis no Web Framework, recomendamos que seja removido o uso da propriedade fontSize da classe Label e que seja realizada uma revisão em estilos CSS específicos que alterem a fonte ou a cor deste componente. É recomendado o uso da nova propriedade size que é adaptável à densidade visual selecionada pelo usuário.
• A execução de tags <script> deixa de ser suportada nas classes Link, SimpleDialog e Label, mesmo com a propriedade autoSanitize desligada. Caso alguma customização avançada necessite do uso dessas tags é necessário que estas sejam injetadas através do método write da classe Process.
• O botão passa a permitir o envio de parâmetros para o processo quando este estiver apontando diretamente para uma interação, ou seja, quando não estiver utilizando o evento onClick. Para enviar parâmetros utilizando o evento deve-se utilizar o método setNextInteraction do processo.
• A propriedade Button.prototype.parameters passa a ser documentada como API legada, sendo recomendado o uso da propriedade params como alternativa.
• A classe AnchorCollection passa a se chamar LinkSet. A instância dessa classe é realizada internamente pelo Web Framework e seu uso externo não é recomendado. A API pública não sofreu alterações que necessitem revisão.
• Os valores dos parâmetros informados no método SimpleLayout.prototype.writeLink passam a ser considerados por todos os links definidos na coluna. Anteriormente eles eram considerados apenas pelo primeiro Link. Essa modificação de comportamento pode afetar links que utilizem o mesmo nome de parâmetro nas propriedades parameters e params, cenário de uso que já não era recomendado, e precisarão ser revistos caso sejam utilizados em colunas com múltiplos links.
• A propriedade legada actived deixou de ser suportada na classe Link e na classe Button. Em seu lugar devem ser utilizadas as propriedades Link.prototype.enabled e Button.prototype.enabled
• A propriedade writeLinkPerRecord da classe Column passa a ser documentada como API legada e seu uso não altera mais o funcionamento dos links do relatório. Recomenda-se a remoção do uso dessa propriedade.
• O método Link.prototype.writeToClient passa a ser considerado API legada e seu uso não altera mais o funcionamento dos links. Recomenda-se a remoção das chamadas desse método dos códigos atuais. Não há necessidade de revisão uma vez que o comportamento dessa API foi incorporado ao método Link.prototype.getHtml.
• A classe legada CssExtractor foi removida do sistema, pois o seu uso no envio de e-mails tornou-se desnecessário.
• As propriedades css, cssClass, labelCssClass e columnGroupHeaderClass da classe Column do SimpleLayout passam a lançar erro caso sejam informadas classes CSS com nomes inválidos. Elas também deixam de permitir a injeção de atributos HTML de uma forma geral e passam a suportar apenas as construções class="custom-class" style="prop: value" para fins de compatibilidade. Eventuais atributos adicionais informados nessas propriedades passam a ser ignorados pelo sistema. Para informar estilos CSS em linha, passa a ser recomendado o uso das novas propriedades cssStyle, labelCssStyle e columnGroupHeaderCssStyle, conforme exemplo abaixo:

  col.cssClass = 'custom-class';
  col.cssStyle = {
   'font-weight': 'bold'
  }; 
  

• A classe SimpleLayout passa a gerar um erro caso sejam escritos registros que não sejam descendentes do nó raiz em relatórios do tipo árvore. Antes os registros eram silenciosamente ignorados, mascarando uma falha na lógica de escrita do relatório ou de integridade dos dados escritos.
• O parâmetro legado skinScriptKeyOrUrl do método Process.prototype.getSimpleLayout() e do construtor new SimpleLayout() deixa de ser suportado e passa a ser ignorado pelo sistema. Customizações visuais via scripts não são recomendadas, pois elas podem conflitar ou serem sobrepostas pelas configurações do tema em uso no sistema. Se necessário, o comportamento anterior pode ser mantido executando o script indicado por skinScriptKeyOrUrl diretamente, conforme exemplo abaixo:

  (function () {
    eval(virtualFS.getFileContent(skinScriptKeyOrUrl));
  }).bind(sl)();
  

• A propriedade SimpleLayout.prototype.mustIncludeCssFiles foi renomeada para includeCss e o seu valor padrão passa a ser false a fim de otimizar a visualização de relatórios dentro do Web Framework.
• As funções getSimpleLayoutCssFileKeys, getSimpleLayoutCss, uwl.css.getReportCssFileKeys e uwl.css.getReportCss foram removidas do sistema, pois os estilos CSS dos relatórios passam a ser dinâmicos com base nas configurações de tema e preferências do usuário. Caso necessário, os estilos CSS requeridos pelos relatórios podem ser gerados pela função SimpleLayout.formatCssStyle, no entanto, é importante observar que esses estilos são carregados automaticamente pelo sistema e são necessários apenas para relatórios exibidos fora das interfaces do sistema. Nesse cenário de uso, esses estilos também podem ser incluídos automaticamente por meio da opção SimpleLayout.prototype.includeCss.
• A classe SimpleLayout passa a utilizar estilos CSS mais complexos que somente são interpretados corretamente por alguns dos clientes de e-mail (e.g. Gmail) se forem declarados em uma única tag “style” no cabeçalho do documento HTML. Por esse motivo, rotinas de envio de e-mail devem dar preferência a construir essa tag manualmente com estilos otimizados para leitores de e-mail em vez de embarcar os estilos CSS via propriedade SimpleLayout.prototype.includeCss. Ver o exemplo de uso da função SimpleLayout.formatCssStyle para mais detalhes.
• As propriedades uwi.config.pendingTaskProcessKey, uwi.config.pendingTaskUpdateTime e uwi.config.pendingTaskCountFunction foram removidas e o controle de tarefas pendentes passa a ser configurado na classe “/Configuração/Web Framework/Tarefas pendentes”. Mais detalhes no manual Tarefas pendentes.
• Os scripts do tipo “x-pendingTask” (.ipt) deixam de receber o parâmetro “taskKeys”. Esse parâmetro já não era utilizado nas versões anteriores do sistema e sempre era informado com uma string vazia.
• As propriedades licenseKey e scriptKey da classe PendingTaskManager foram removidas, pois elas não tinham finalidade prática e poderiam gerar inconsistências na geração de tarefas pendentes.
• As grades no modo tabela passam a ter uma largura mínima. Caso os campos definidos neste modo não atinjam essa largura, será criado automaticamente um complemento visual semelhante a um campo, porém, que não permite interação e que possuirá a largura restante disponível.
• Os campos deixam de aceitar o valor “auto” nas propriedades ViewDefField.width e ViewDefField.tableViewWidth. Caso seja atribuído o valor “auto”, este será ignorado, permanecendo o valor anterior ou um valor padrão de acordo com o tipo do campo.
• Os eventos “lookupDisplay” e “openKey” definidos nas classes de dados passam a ser adicionados nos campos lookup dessas classes apenas se os campos não definirem esses eventos, evitando a execução de listeners cujos resultados normalmente são ignorados e que eventualmente não podem ser substituídos.
• O diálogo de autenticação passa a disparar um erro caso o tempo máximo de espera para a resposta seja atingido.