ebau
1.0.0
Pedido de licença de construção eletrônica para cantões suíços.
Este repositório contém o código -fonte dos aplicativos da Web usados para lidar com licenças de construção eletrônica e processos comparáveis nos cantões suíços de Berne, Grisons, Schwyz, Solothurn e URI.
A imagem a seguir mostra uma visão geral de alto nível da arquitetura:
ember-ebau-core . ├── compose # docker-compose files
├── db # database Dockerfile and utils
├── django # backend code, containing both API and Caluma
├── document-merge-service # document generation templates and config
├── ember-caluma-portal # Caluma-based portal
├── ember-camac-ng # Ember.js app optimized for embedding in other applications
├── ember-ebau # Ember.js based application for internal area
├── ember-ebau-core # Ember.js addon for code sharing between multiple Ember.js apps
├── keycloak # Keycloak configuration for local development
├── proxy # Nginx configuration for local development
└── tools # miscellaneous utilities
Devido ao trabalho de modernização em andamento, alguns módulos de front-end ainda não estão integrados em ember-ebau , mas ainda fazem parte do ember-camac-ng . Poucos módulos de front -end não fazem parte deste repositório ainda. A tabela a seguir lista os módulos mais importantes na parte "interna" do aplicativo e seu respectivo estado de integridade / integração (na configuração demo ).
| Módulo | Descrição | Back -end | Front-end | Parte de Ember-ebau |
|---|---|---|---|---|
| Nav principal (recurso) | ||||
| Lista de Dossier | Mostre uma lista de dossiers | ✔️ | ✔️ | ✔️ |
| Lista de tarefas | Mostrar uma lista de tarefas | ✔️ | ✔️ | ✔️ |
| Modelos | Gerenciar modelos de documentos (DOCX) | ✔️ | ✔️ | ✔️ |
| Organização / permissões | Gerenciar organização e permissões próprias | ✔️ | ✔️ | ✔️ |
| Conteúdo estático | Conteúdo estático, editor de Markdown | ✔️ | ✔️ | ✔️ |
| Componentes de texto | Gerenciar trechos para uso em campos de texto | ✔️ | ⏳ | ⏳ |
| Subnav (recurso da instância) | ||||
| Tarefas | Ver e gerenciar tarefas | ✔️ | ✔️ | ✔️ |
| Forma | Ver e editar o formulário principal | ✔️ | ✔️ | ✔️ |
| Distribuição | Obtenha feedback de outras organizações | ✔️ | ✔️ | ✔️ |
| Alexandria | Gerenciamento de documentos | ✔️ | ✔️ | ✔️ |
| Modelo | Gerar documento do modelo | ✔️ | ✔️ | ✔️ |
| Jornal | Caderno colaborativo | ✔️ | ✔️ | ✔️ |
| História | Mostra marcos e dados históricos | ✔️ | ✔️ | ✔️ |
| Publicação | Gerenciar publicação em jornal | ✔️ | ✔️ | ✔️ |
| Objeções | Gerenciar objeções | ✔️ | ✔️ | ✔️ |
| Responsável | Atribuir usuários responsáveis | ✔️ | ✔️ | ✔️ |
| Reivindicações | Peça ao candidato informações adicionais | ✔️ | ✔️ | ✔️ |
| Rejeição | Rejeitar a instância | ✔️ | ✔️ | ✔️ |
| Cobrança | Gerenciar entradas de cobrança | ✔️ | ✔️ | ✔️ |
| Auditoria | Execute auditoria estruturada | ✔️ | ✔️ | ⏳ |
| Log de auditoria | Mostra alterações de formulário | ✔️ | ⏳ | ⏳ |
O ambiente de desenvolvimento preferido é baseado no Docker.
Para desenvolvimento local:
Python:
Brasa:
O Docker pode ser usado para colocar Ebau em funcionamento rapidamente. O script a seguir o guia através do processo de configuração. Recomendamos o uso da configuração kt_gr ou kt_so por enquanto, já que outros cantões ainda dependem de componentes herdados para a área interna que não fazem parte deste repositório.
make start-dev-envCaso você queira modificar manualmente /etc /hosts a seguir, os domínios precisam apontar para 127.0.0.1 (localhost):
ebau-portal.local ebau.local ebau-keycloak.local ember-ebau.local ebau-rest-portal.local
Para verificações automáticas durante o comprometimento (formatação, linha), você pode configurar um gancho Git com os seguintes comandos:
pip install pre-commit
pre-commit installDepois, você poderá usar os seguintes serviços:
As seguintes contas de administrador estão presentes no keycloak ou no banco de dados, respectivamente:
| Aplicativo | Papel | Nome de usuário | Senha | Notas |
|---|---|---|---|---|
| demonstração | Admin | usuário | usuário | |
| kt_schwyz | Admin | admin | admin | |
| Publique | adsy | adsy | ||
| kt_uri | Admin | admin | admin | |
| Portaluser | portal | portal | ||
| kt_bern | Admin | usuário | usuário | |
| kt_gr | Admin | admin | admin | |
| Requerente | editor | editor | Função do editor do candidato | |
| Requerente | Readonly | Readonly | Função de readonly do candidato | |
| kt_so | Admin | admin | admin | |
| Requerente | editor | editor | Função do editor do candidato | |
| Requerente | Readonly | Readonly | Função de readonly do candidato |
make debug-django Com o Docker Compose, você pode anexar a um contêiner em execução (basicamente equivalente ao docker compose up sem o sinalizador -d ) e interagir via stdin.
docker compose attach djangoIsso permitirá que você
um. Enviar sinais para o contêiner
b. caia para um shell PDB quando o aplicativo for executado em um breakpoint
Como a configuração do Dev executa o servidor de desenvolvimento do Django que recarrega as alterações do arquivo, a inserção desses pontos de interrupção é efetiva imediatamente após salvar o arquivo.
Pressione CTRL-p + CTRL-q
Nota: Como por padrão, o processo attach encaminhará os sinais para o contêiner, você precisará sair da pressão da referida sequência (que é a configuração padrão para --detach-keys e pode ser substituída). Pressionar CTRL-c , no entanto, não apenas matará o TTY, mas também enviará o sigint para o contêiner e o interrompe.
Docs: https://docs.docker.com/reference/cli/docker/container/attach/
docker-compose up -d --build db django
cd {ember | ember-camac-ng | ember-caluma-portal | ember-ebau} # Enter ember from the top level of the repo
pnpm install # Install dependencies
pnpm test # Run tests
pnpm start-proxy # Run dev server with proxy to django api Como este é um grande projeto com muitos arquivos, a configuração padrão da Ember possivelmente falha em reconstruir corretamente, pois não pode assistir a todos esses arquivos.
Para corrigir isso, instale o Watchman como observador de arquivos e ajuste as configurações inotify :
echo fs.inotify.max_user_watches=1000000 | sudo tee -a /etc/sysctl.conf # adjust settings
sudo sysctl -p # re-read configCertifique -se de que o último comando retorne apenas um valor, caso contrário, as configurações são duplicadas e precisam ser limpas.
Observe, no entanto, que os aplicativos ember-caluma-portal , ember-camac-ng , ember-ebau e Addon ember-ebau-core compartilham a mesma árvore de módulos de nó através de uma área de trabalho do PNPM.
O espaço de trabalho comum do PNPM nos permite compartilhar código (por exemplo, addons) entre os aplicativos que fazem parte deste repositório (em vez de seguir a abordagem típica de publicar lançamentos no NPM). Isso também significa que
node_modulesember-caluma-portal e ember-camac-ng precisam ser mantidas em sincronia Para ativar django-silk para perfil, basta adicionar DJANGO_ENABLE_SILK=True ao seu arquivo django/.env . Em seguida, reinicie o contêiner django e navegue para http: //ebau.local/api/silk/.
Para mudar da configuração demo para kt_bern , é preciso garantir que os aplicativos de front -end ocupem as variáveis de ambiente certo.
pnpm start-proxymake kt_berndocker-compose up -d && make loadconfigdocker-compose downmake kt_berndocker-compose builddocker-compose up -dAs configurações de depurador remoto para o código VS estão comprometidas com o repositório.
.vscode/launch.json . Para ativar a depuração no contêiner Django, o servidor PTVSD deve ser iniciado. Como este servidor de depuração colide com outras configurações (pycharm, pydev), ele só será iniciado se o Env var ENABLE_PTVSD_DEBUGGER estiver definido como True em django/.env .
Para conversar com o endpoint /graphql com autenticação, você pode instalar uma ferramenta grafql (como o Postman). Ferramentas que você pode considerar aqui:
O módulo GWR é desenvolvido em dois repositórios separados:
Se você usar o módulo GWR, precisará gerar uma chave de samnet de acordo com a documentação do back -end do GWR.
Você precisa definir essa chave em cada ambiente/servidor no seu arquivo Env. Gere uma chave separada para cada ambiente, pois é usado para armazenar / ler as senhas de usuário da GWR.
A API deve ser projetada de uma maneira, que permite que ela seja usada por qualquer projeto EBAU. Para a personalização necessária, as seguintes regras se aplicam:
Para diferentes sinalizadores e permissões de recursos, consulte APPLICATIONS no Settings.py.
No modo de desenvolvimento, o aplicativo está configurado para enviar todo o email para uma instância de correio, portanto, a menos que você especifique outra coisa, nenhum email será enviado do ambiente de desenvolvimento.
Você pode acessar o Mailpit via http: //ebau.local/mailpit/. Qualquer e -mail enviado será instantaneamente visível lá.
Seção para coletar informações sobre módulos e cantões. Esta seção pretende facilitar a transferência de know-how, as transferências de férias e os casos de suporte de depuração.
Módulo usado em kt. SZ e KT. Ur (em breve), que acompanha o processo de construção após a decisão. O município (até agora apenas os casos são cobertos onde a autoridade principal é o município) e o candidato interage através de uma série de itens de trabalho com documentos.
Existem estágios de construção ("Bauetappen"), que consistem em etapas de construção dinamicamente selecionáveis. As etapas de construção são uma série de itens de trabalho, que geralmente seguem o padrão de começar com um item de trabalho endereçado ao candidato, seguido por um ou mais itens de trabalho endereçados ao município. O requerente confirma que eles aderiram aos regulamentos definidos, e o munncipality o verifica. O item de trabalho final permite que o Muncipality decida se deve continuar o processo ou reiterar no início da etapa de construção.
O módulo é fortemente definido pelo fluxo de trabalho configurado. Quais etapas de construção e, portanto, quais itens de trabalho são executados são tratados através de tarefas dinâmicas. A configuração da etapa de construção (como qual tarefa pertence a qual etapa de construção) é configurada na meta de tarefas pertencentes a uma etapa de construção. As etapas de construção são essencialmente um agrupamento de tarefas, não há modelo representando -as.
Os estágios de construção são um item de trabalho de múltiplas instâncias com um casal infantil. O casal infantil contém os itens de trabalho da etapa de construção. O primeiro estágio de construção é criado ao inicializar o processo de monitoramento da construção. Depois disso, uma nova fase de construção pode ser inicializada por uma mutação do Create Work-Item no item de trabalho existente (no status pronto). Cuidado: para garantir que um novo estágio de construção sempre possa ser criado desde que o processo de monitoramento da construção não esteja concluído, os itens de trabalho do estágio de construção permanecem prontos, enquanto o estojo infantil em estágio de construção já foi concluído.
A lógica do núcleo está contida principalmente no fluxo de trabalho de monitoramento da construção e na configuração de formulário do cantão, os eventos da Caluma para o monitoramento da construção, as configurações do módulo, alguma lógica de visibilidade e permissão personalizada.
No cantão de Solothurn, usamos um mecanismo de autorização personalizado para o portal Ebau. O portal Ebau só pode ser usado com um login do meu.so.ch, o software do portal Egov. Como eles não oferecem autorização do OIDC, tivemos que implementar uma solução personalizada usando os recursos de troca de token da KeyCLoak e diretos de representação nua.
A autorização foi projetada para recuperar um token JWT criptografado e assinado, que é então convertido em um token JWT OIDC regular por keycloak:
Sequenciadoiagram
AutoNumber
Participante F como portal EBAU
Participante M como portal Egov
Participante B como API EBAU
Participante K como keycloak
F->>+m: redirecionar para a prestação
Nota Direito de M: Token JWT criptografado e assinado com dados do usuário
M->>-f: redirecionar para fazer login com token Egov
F->>+B: Enviar token (poste para/api/v1/auth/token-trhange)
B->> b: descriptografar e verificar o token Egov, extraia dados do usuário do token
B->>+k: Crie ou atualize o usuário
K->> B: Retorne usuário
B->> K: troca de token com representação direta nua
K->>-b: retornar o token para o usuário
B->>-F: Retornar o token
Para ativar o recurso, a seguinte configuração deve ser feita:
Por padrão, o keycloak já está configurado corretamente para apoiar esse mecanismo de autorização. Para configurar outro ambiente, consulte a documentação
# .env
ENABLE_TOKEN_EXCHANGE =trueIsso permitirá o recurso com um portal EGOV dummy hospedado em nosso proxy nginx. Para testar com o ambiente de teste do portal EGOV, precisamos definir mais algumas variáveis de ambiente (os valores censurados podem ser encontrados no cofre):
# .env
EGOV_PORTAL_URL =****
EGOV_PRESTATION_PATH =**** # django/.env
TOKEN_EXCHANGE_JWT_ISSUER =****
TOKEN_EXCHANGE_JWT_SECRET =****
TOKEN_EXCHANGE_JWE_SECRET =****Este projeto é licenciado sob o eupl-1.2-ou-later. Consulte a licença para obter detalhes.
