Para a criação de uma regional nova, é necessário acessar a tela oculta em: http://localhost:9060/#/r2/configParams, e clicar na aba de regionalização.
Ao cadastrar uma regional, os dados de configuração default serão criados via código para aquela regional, essa abordagem é para mitigar os problemas de não permitir alterar as configurações da regional pai, e a filha já nascer com as suas próprias configurações.

Para tornar uma entidade passível de criar os dados default automaticamente, é necessário que o serviço tenha uma interface, e que ela herde a interface DefaultEntityCreator<?>
Não é possível colocar direto no serviço, pois pôr haver a anotação @Transactional, irá quebrar na subida por problema de proxy.

Cada artefato terá que ter o seu respectivo Controller que implementando a interface DefaultEntitiesCreatorClient, e no UserManagement, o seu respectivo Outbound, para que o UserManagement efetue a requisição.
Também está disponível a Interface DefaultEntitiesCreatorService que podemos criar um serviço no nosso artefato e injetar todos os serviços que implementam ele, e disparar a criação default em um laço.
Após isso, sobrescrever o método T createDefault(), a entidade já estará passível de ser chamada pelo fluxo.

Em alguns casos, é necessário que algumas entidades sejam criadas antes, que é o caso de Categoria, Causa e Status de Ocorrência, pois é utilizado na configuração default da Faixa de Temperatura.
Atualmente está sendo utilizado o @Order do Spring para definir a ordem dos serviços que devem vir a frente.

• A criação das entidades default só acontece quando está sendo criada uma Unidade, que é filha de uma Company. A lógica para isso é feita da seguinte maneira: A Company é filha da Super, então precisa ver se o pai do meu pai tem alguma regional. O permissionGroup Super não tem pai, então na criação de regionais do tipo Company, não é disparado o broadcast de criação default.

Parâmetros genéricos:

Para consumir parâmetros genéricos sem procurar pelos ready only, e pegar do permission_group logado, é necessário atualizar no banco a coluna "use_only_current_pg" para true.

Dados default:

Nas planilhas abaixo, encontram-se os dados que são criados automaticamente em uma base limpa.
Ela serve como um guia para a extração de todos os dados que são criados via migração, para a conversão para a criação via código.

EXECUÇÃO                               PLANEJAMENTO

Visão geral da Regionalização conforme o menu.

Tipo de criação possui 2 tipos 

1. Estática: Criação dos dados a partir de código do backEnd.
2. Dinâmica: Criação dos dados pegando do pai, fazendo uma cópia.

Configuração

• Roteirização

• Rastreamento

• KPI

OBS sobre as telas:

1. Integrações

• Configuração
  • Rastreamento

• Configuração
  • KPI

Relatórios

EXTRA:

• Arquivo para criar usuário com perfil TOTVS ( rodar os comandos sql em ordem )

Atenção (Temporário)

niveis: ( totvs → companhia → unidades )

Ao decorrer do desenvolvimento da regionalização das entidades no tre, ao buscar uma entidade ela traz os próprios e dados e os do pai (como diz o conceito do permissionGroup), como o banco de instância única continua em construção com o andamento da regionalização, algumas regionais pai ainda possuem alguns dados de entidade que não condiz como o banco vai ficar no final. Por isso, foi criado uma solução temporário para as entidades trazerem apenas os dados da própria regional, com isso facilitando teste durante a regionalização do tre.

Para fazer isso, é necessário colocar a notação abaixo na classe persitente. Com esse será chamado um interpector da hora da consulta que apenas irá trazer os dados da atual regional (Execução)

@Filter( name = PERMISSION_GROUP_WITHOUT_READ_ONLY_FILTER )

Vale destacar que essa solução é temporária, apenas quando não terminamos de regionalizar todas as entidades e arrumarmos o banco para instância única. Após ser concluído a regionalização todas essas notações serão apagadas.