# Ordenar campos e seções personalizadas entre seções standard

Permitir na montagem de formulários no Builder poder ordenar campos e seções personalizadas entre as seções standard, de forma que consiga deixar os campos personalizados que possuem informações relacionadas ou complementares próximas às standard, assim facilitando o uso da aplicação e melhorando a experiência de usuário.

## 2. Back-end
### 2.5 Crud elementos
Não há necessida de alterações no PUT visto que não há permissão para realizar alteração do elemento nesta chamada. Ao realizar essa chamada hoje já retorna a mensagem `"A ordem não pode ser alterada através desta requisição. Use o /change-order para executar essa operação."`.

Alterar validação no insert permitindo inserir elementos em qualquer local na raiz.

Alterar validação no `/change-order` para permitir alterar ordem dos elementos que estão na raiz independete se é standard.

### 2.7 Custom-entries
Não será necessário alteração.

## 3. Front-end
### 3.2 Builder
#### 3.2.2 Cadastro elementos
##### 3.2.2.1 Builder de formulário
Manipulação em Reorder:
- [x] Root context
- [x] Fluxo de contexto de seção(fluxo isolado)
- [x] Drag and drop

Toda validação existente para bloqueio da ação de Drag and Drop, entre elementos 'ROOT'(standards e personalizados) deve ser anuladas, deixando a opção do usuário estar manipulando a ordem entre campos personalizados e seções/elementos standards.

Pontos de atenção para (add/reorder):
- Elementos standard estarão aptos a serem reordenados, porém apenas no escopo root;
- Elementos standard que estejam no escopo de seção standard não terão reordenação;
- Elementos personalizados só poderão ser reordenados entre standards no escopo root;
- Não será possível mover campos personalizados para seções standards;
- Não será possível mover quaisquer tipo de campos standards para seções personalizadas;
- Toda adição de novo elemento poderá ser efetuado em qualquer posição do escopo root;

Implementações necessárias:
- Remoção das regras de bloqueio de reordenação entre elementos standards e personalizados, tendo foco no escopo ROOT apenas;
- Testes e doc no que for possível(se possuir fluxo isolado);

Implementações desejáveis/inviáveis:
- Não será possível estar aplicando testes nas alterações de fluxo global, pois os testes não estão realizados, fugindo assim da solução base para débitos técnicos;

#### 3.2.4 Preview

O Preview não é para ser impactado visto que utilizamos os elementos standards não suportados como stubs, e os não stubs sendo maioria como seção já mapeada. Porém é necessário validar se esta sendo aplicado a ordenação na exibição/renderização de todos os campos, caso o preview realmente precise refletir isso, visto que não teremos suporte ao mobile no momento.

### 3.3 Midgard

Todo componente standard que é referenciado como um elemento root no builder do btb sendo ele do tipo seção ou não, deve se criar uma ligação/referência junto a um novo wrapper chamado BTBWrapper. Esse wrapper tem a finalidade de ser identificado com o mesmo id dos elementos standards que estarão sofrendo a mudança de ordenação, sendo a maioria do tipo 'seção'.

A Maioria da estrutura standard está componentizada em diferentes escopos de renderização, por esse motivo na implementação standard o wrapper deverá ser informado ao componente que faz referência ao escopo de execução do elemento ordenado no buider.


Exemplo conforme a imagem acima: o MainInformation contem a lógica de renderização da seção de 'Informações principais', por esse elemento ser o item que está no mesmo escopo da árvore de renderização do BTB, ele sofrerá a mudança na ordem de exebição.

O wrapper terá uma estrutura básica contendo apenas o id do elemento standard, com isso será possível no momento da renderização do ymir ser mergeado a ordem de cada metaElement de acordo com o elemento standard que possui referência, possibilitando assim o sort com base na ordem dos elementos.


Dentre os formulários que serão trabalhados inicialmente(Customer, Contact e leads), apenas o formulário de contact sofrerá ajuste de código para ficar compatível com a aplicação do wrapper do BTB. Ele possui uma seção que possui um campo de Avatar dentro do mesmo contexto, porém no builder o Avatar é de escopo externo a seção e terá como impacto a mudança desse item.

Implementações necessárias:
- Adição do wrapper do btb)(Documentação e testes);
- Mudança no escopo de execução, criando um array de componentes standards para posterior execução no ymir;
- Aplicação do wrapper no formulário de Customer, Contact e Leads;
- Ajuste no código standard do formulário de Contact;

### 3.4 AppBuilderFormRenderPlugin

A função de modifyChildren que se refere a funcionalidade de obrigatoriedade de campos standards no AppBuilderFormRenderPlugin agora é chamada no método render do plugin, é preciso ser manipulado os elementos standards antes de passar os componentes para o EmbeddedRenderer. Todos os elementos standards de formulário não são mais renderizados no escopo do midgard, nessa mudança de fluxo e execução o Ymir passará a atender renderizações de elementos standards e personalizados;

Implementações necessárias:
- Mudança de execução da função que manipula os elementos standards para a funcionalidade de obrigatoriedade;

### 3.6 Ymir
- [x] Criar/Alterar o renderizador específico para o componente

Não vai ser efetuado uma mudança no renderizador de cada elemento, porém será necessário ajustar o método que antes retornava os elementos personalizados apenas, o mesmo passa a manipular os elementos standards de acordo com sua ordem, mergeando os componentes standards junto aos personalizados e retornando apenas um array de elementos ordenados devidamente para renderização.

Implementações necessárias:
- Dar suporte aos componentes standards por propriedade no embeddedRenderer e ContentRenderer;
- Implementação de um hook para manipulação dos dados standards e sort(docs e testes);
- Implementação do merge da ordem dos meta elementos para os componentes standards;
- Concatenação das listas de componentes;
- Implementação do sort na lista unificada de elementos e retorno para o render;
- Documentação e testes;

Fluxo geral na visão standard/custom e midgard/ymir:


## 4. Mobile
### 4.1 Back-mobile\
Validar com um Dev mobile os impactos;

### 4.2 Front-mobile
Validar com um Dev mobile os impactos;