Files
SGF/docs/SGF_PURCHASING_USABLE_CONTINUITY.md
2026-11-04 09:37:20 +02:00

6.9 KiB

Continuidade utilizável e isolamento de históricos — 03/11/2026

SGF-PURCHASING-USABLE-CONTINUITY-QA-v1 corrige duas falhas da interface de recepção, completa as ligações recepção → factura → obrigação e fecha uma fuga de eventos entre históricos de etapas do percurso QA.

Correcções funcionais e integração

A linha de recepção criava um elemento select simples, embora o restante formulário tentasse usar activate e selected do selector pesquisável. Foi ligada ao stockChoice já existente. Marcar a linha agora activa a pesquisa por linha, permite escolha expressa do artigo e envia o ID e a impressão da versão na prévia. Alterar/desmarcar a escolha mantém as invalidações existentes.

O primeiro pedido do selector enviava search=. O middleware convertia esse texto vazio em null, que era recusado por sometimes|string. Os catálogos de artigos e fornecedores agora aceitam o filtro vazio/nulo como ausência de pesquisa. Pesquisa literal não vazia, paginação, isolamento, estados do processo e rejeição de arrays/parâmetros desconhecidos mantêm-se. Não se retirou uma regra nativa para tornar o catálogo disponível num processo fechado.

A recepção abre as facturas da mesma ordem. Cada factura abre a obrigação dessa origem, as recepções da ordem e, havendo acesso, o dossiê da requisição. A obrigação volta à factura exacta e à sua ordem física. Os atalhos adicionais só aparecem quando a etapa consta do menu apresentado; isso é uma indicação de interface, não autoridade. Cada API de destino continua a validar o contexto e o acesso actual. A funcionalidade adicional fica desligada por omissão em receipt_qa.continuity_enabled.

Isolamento dos históricos

Os detalhes da requisição e o histórico paginado das propostas consultavam toda a auditoria da requisição. Numa origem com factura/obrigação posteriores, podiam devolver esses eventos e respectivos payloads a um perfil limitado à etapa anterior. A prova antiga do dossiê não cobria esta via alternativa.

ProcessHistory aplica o âmbito na consulta SQL, antes do limite, contagem e paginação. Requisição mostra apenas requisition.*/sgf.request.command; propostas mostram os eventos da requisição, propostas e adjudicação. Facturas conservam o seu endpoint próprio de histórico autorizado. A auditoria original não foi apagada, alterada ou reclassificada. O dossiê continua a fazer a consulta transversal filtrada pelas permissões de cada etapa.

Não foram criados direitos, writers ou endpoints de confirmação. Os blocos preview/confirm dos controladores de requisição, propostas e recepção foram comparados com8078 e são iguais; os controladores de factura/obrigação e os manifestos nativos também se mantêm.

Provas afectadas

Consolidação técnica: 55 verificações.

  • 17 de interface simulada com HTTP real: carregar a ordem, activar a linha, pesquisar, escolher o artigo, enviar versão, conferir, invalidar prévia por edição, confirmar e recuperar uma resposta perdida após commit. Resultado real:201/200, uma recepção e um movimento de1000milésimos/1UN, artigo escolhido preservado. Não é uma nova prova de concorrência.
  • 8 de fronteiras dos filtros: pesquisa inicial vazia igual à omitida; espaços tratados como filtro vazio; arrays/tamanho de página/parâmetros inválidos recusados; direito de Compras e fecho por adjudicação respeitados. Mantém uma recepção/movimento e zero facturas, obrigações ou pagamentos.
  • 12 de históricos: o livro canónico anterior contém os eventos financeiros que reproduziam a falha; requerente/Compras/Finanças recebem apenas a história da requisição nesse endpoint; todas as páginas de propostas mantêm os seus eventos únicos e excluem os posteriores. Finanças conserva o histórico da factura e o acesso indevido continua recusado.
  • 9 de ligações na interface: origem exacta, menu limitado, modo desligado, compatibilidade do dossiê e abertura só com GET.
  • 9 da demonstração: estados iniciais, flags nas três áreas e SHA dos quatro módulos estáticos afectados, sem alteração dos dados/auditoria/concessões seleccionados.

A regressão de interface usa a composição nova ce4c9bef1a51, no cluster isolado55439. A ordem de100MZN foi preparada pelos workflows efectivos necessários. Uma requisição adicional aberta de1MZN é fixture delimitada para ensaiar o selector de fornecedores antes da adjudicação: reserva própria100unidades menores no mesmo livro, sem segunda ordem/dívida. Não é repetição da suite financeira anterior.

Os históricos reutilizam o livro já concluído b4093c6f6707, através da aplicação de leitura nova purchasing-continuity-read-e266c0e778c2: 142 tabelas e sequências intactas, sem repetir comandos. As provas válidas de catálogo/paginação/concorrência/dossiê anteriores foram preservadas.

Verificação final: sintaxe de11 ficheiros PHP e12 JavaScript aprovada; git diff --check sem erros de espaços. Matriz/inventário actualizados: seis módulos,13 etapas,85 fontes, zero ciclos obrigatórios e134 critérios documentais conferidos. Os números do inventário não são testes operacionais adicionais ou validação dos módulos completos.

O primeiro ensaio de interface parou antes da confirmação, o que revelou a validação de pesquisa vazia. Os diagnósticos privados foram conservados; após a correcção, o percurso real terminou com as17 verificações. Não se declara esse ensaio inicial como aprovado ou uma revisão no navegador.

Demonstração e limites

Nova demonstração 8079: Solicitante, Compras, Armazém, Finanças. Composição 2d2d938a3bec, sem operações principais/recepções/facturas/obrigações iniciais, com fornecedores e orçamento QA preparados. Conserva as funcionalidades de dossiê, cartografia e anexos já entregues.

8078 e anteriores, seis registos protegidos, cache bloqueada, provas e trabalho alheio preservados. Sem migração/concessão real, activação de Compras, publicação, aceitação ou checkpoint.

Os testes usam DOM simulado; a ligação HTTP real comprova o contrato funcional, não renderização, acessibilidade ou aceitação visual. A revisão visual continua separada, sem repetir a via bloqueada de navegador. Os atalhos não aprovam, determinam prontidão ou executam a etapa seguinte. A requisição conserva os últimos25 eventos próprios no detalhe; propostas continuam paginadas e o dossiê mantém evidência transversal filtrada. Não foram alterados React/CSS/dependências do build Vite: preserva-se a prova válida anterior, verificando sintaxe e bytes servidos dos módulos ES estáticos afectados. Carga sustentada, instalação e capacidade de implantação exigem provas próprias.