ebau
1.0.0
Solicitud de permiso de construcción electrónica para cantones suizos.
Este repositorio contiene el código fuente para las aplicaciones web utilizadas para manejar los permisos de construcción electrónica y procesos comparables en los cantones suizos de Berna, Grisons, Schwyz, Solothurn y URI.
La siguiente imagen muestra una descripción general de alto nivel de la arquitectura:
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
Debido al trabajo de modernización en curso, algunos módulos de frontend aún no están integrados en ember-ebau , pero en su lugar siguen siendo parte de ember-camac-ng . Pocos módulos frontend aún no forman parte de este repositorio. La siguiente tabla enumera los módulos más importantes en la parte "interna" de la aplicación y su respectivo estado de integración / integración (en la configuración demo ).
| Módulo | Descripción | Backend | Interfaz | Parte de Ember-Ebau |
|---|---|---|---|---|
| NAV principal (recurso) | ||||
| Lista de expedientes | Mostrar una lista de expedientes | ✔️ | ✔️ | ✔️ |
| Lista de tareas | Mostrar una lista de tareas | ✔️ | ✔️ | ✔️ |
| Plantillas | Administrar plantillas de documentos (DOCX) | ✔️ | ✔️ | ✔️ |
| Organización / permisos | Gestionar la propia organización y permisos | ✔️ | ✔️ | ✔️ |
| Contenido estático | Contenido estático, editor de Markdown | ✔️ | ✔️ | ✔️ |
| Componentes de texto | Administre fragmentos para su uso en campos de texto | ✔️ | ⏳ | ⏳ |
| Subnav (recurso de instancia) | ||||
| Tareas | Ver y administrar tareas | ✔️ | ✔️ | ✔️ |
| Forma | Ver y editar el formulario principal | ✔️ | ✔️ | ✔️ |
| Distribución | Obtenga comentarios de otras organizaciones | ✔️ | ✔️ | ✔️ |
| Alejandría | Gestión de documentos | ✔️ | ✔️ | ✔️ |
| Plantilla | Generar documento a partir de la plantilla | ✔️ | ✔️ | ✔️ |
| Diario | Cuaderno colaborativo | ✔️ | ✔️ | ✔️ |
| Historia | Muestra hitos y datos históricos | ✔️ | ✔️ | ✔️ |
| Publicación | Gestionar la publicación en periódicos | ✔️ | ✔️ | ✔️ |
| Objeciones | Gestionar las objeciones | ✔️ | ✔️ | ✔️ |
| Responsable | Asignar usuarios responsables | ✔️ | ✔️ | ✔️ |
| Reclamos | Solicitar información adicional al solicitante | ✔️ | ✔️ | ✔️ |
| Rechazo | Rechazar instancia | ✔️ | ✔️ | ✔️ |
| Facturación | Administrar entradas de facturación | ✔️ | ✔️ | ✔️ |
| Auditoría | Realizar auditoría estructurada | ✔️ | ✔️ | ⏳ |
| Registro de auditoría | Muestra cambios de forma | ✔️ | ⏳ | ⏳ |
El entorno de desarrollo preferido se basa en Docker.
Para el desarrollo local:
Pitón:
Ascua:
Docker se puede usar para que EBAU se ejecute rápidamente. El siguiente script lo guía a través del proceso de configuración. Recomendamos usar la configuración kt_gr o kt_so por ahora, ya que otros cantones aún dependen de componentes heredados para el área interna que no forman parte de este repositorio.
make start-dev-envEn caso de que desee modificar manualmente /etc /hosts, los siguientes dominios deben apuntar a 127.0.0.1 (localhost):
ebau-portal.local ebau.local ebau-keycloak.local ember-ebau.local ebau-rest-portal.local
Para verificaciones automáticas durante la confirmación (formateo, pelusa) puede configurar un git de gits con los siguientes comandos:
pip install pre-commit
pre-commit installDespués, debería poder usar los siguientes servicios:
Las siguientes cuentas de administrador están presentes en KeyCloak o en DB, respectivamente:
| Solicitud | Role | Nombre de usuario | Contraseña | Notas |
|---|---|---|---|---|
| manifestación | Administración | usuario | usuario | |
| kt_schwyz | Administración | administración | administración | |
| Edición | adsy | adsy | ||
| kt_uri | Administración | administración | administración | |
| Portaluser | portal | portal | ||
| KT_Bern | Administración | usuario | usuario | |
| KT_GR | Administración | administración | administración | |
| Solicitante | editor | editor | Rol de editor de solicitantes | |
| Solicitante | readonamente | readonamente | Solicitante Readonly | |
| KT_SO | Administración | administración | administración | |
| Solicitante | editor | editor | Rol de editor de solicitantes | |
| Solicitante | readonamente | readonamente | Solicitante Readonly |
make debug-django Con Docker Compose, puede adjuntar a un contenedor en ejecución (básicamente equivalente a docker compose up sin el indicador -d ) e interactuar a través de Stdin.
docker compose attach djangoEsto te permitirá
a. Enviar señales al contenedor
b. Llegue a un shell PDB cuando la aplicación se ejecute en un breakpoint
Dado que la configuración de Dev ejecuta el servidor de desarrollo Django que se vuelve a cargar en los cambios de archivo, insertar esos puntos de interrupción es efectivo inmediatamente después de guardar el archivo.
Presione CTRL-p + CTRL-q
Nota: Dado que, de manera predeterminada, el proceso attach reenviará las señales al contenedor, tendrá que salir presionando dicha secuencia (que es la configuración predeterminada para --detach-keys y se puede anular). Sin embargo, presionar CTRL-c no solo matará al TTY, sino que también enviará el Sigint al contenedor y lo detiene.
Documentos: 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 Dado que este es un proyecto grande con muchos archivos, la configuración predeterminada de Ember posiblemente no se reconstruirá correctamente, ya que no puede ver todos esos archivos.
Para solucionar eso, instale Watchman como observador de archivos y ajuste la configuración inotify :
echo fs.inotify.max_user_watches=1000000 | sudo tee -a /etc/sysctl.conf # adjust settings
sudo sysctl -p # re-read configAsegúrese de que este último comando solo devuelva un valor; de lo contrario, la configuración está duplicada y debe limpiarse.
Sin embargo, tenga en cuenta que las aplicaciones ember-caluma-portal , ember-camac-ng , ember-ebau y Addon ember-ebau-core comparten el mismo árbol de módulos de nodo a través de un espacio de trabajo PNPM.
El espacio de trabajo PNPM común nos permite compartir código (por ejemplo, complementos) entre las aplicaciones que forman parte de este repositorio (en lugar de seguir el enfoque típico de las publicaciones de publicación en NPM). Esto también significa que
node_modulesember-caluma-portal y ember-camac-ng deben mantenerse sincronizadas Para habilitar django-silk para perfilar, simplemente agregue DJANGO_ENABLE_SILK=True a su archivo django/.env . Luego reinicie el contenedor Django y navegue a http: //ebau.local/api/silk/.
Para cambiar de la configuración demo a kt_bern , uno debe asegurarse de que las aplicaciones frontend tomen las variables de entorno correctas.
pnpm start-proxymake kt_berndocker-compose up -d && make loadconfigdocker-compose downmake kt_berndocker-compose builddocker-compose up -dLa configuración remota del depurador para el código VS se compromete al repositorio.
.vscode/launch.json . Para habilitar la depuración en el contenedor Django, se debe iniciar el servidor PTVSD. Dado que este servidor de depuración colide con otras configuraciones (PyCharm, Pydev), solo se iniciará si el Env VAR ENABLE_PTVSD_DEBUGGER se establece en True en django/.env .
Para hablar con el punto final /graphql con autenticación, puede instalar una herramienta GraphQL (al igual que Postman). Herramientas que puede considerar aquí:
El módulo GWR se desarrolla en dos repositorios separados:
Si usa el módulo GWR, debe generar una clave Fernet de acuerdo con la documentación del backend de GWR.
Debe establecer esta clave en cada entorno/servidor en su archivo ENV. Genere una clave separada para cada entorno, ya que esto se utiliza para almacenar / leer las contraseñas de usuario de GWR.
La API debe diseñarse de una manera, que permita que sea utilizado por cualquier proyecto EBAU. Para la personalización necesaria, se aplican las siguientes reglas:
Para diferentes banderas y permisos de características, consulte APPLICATIONS en Settings.py.
En el modo de desarrollo, la aplicación está configurada para enviar todo el correo electrónico a una instancia de MailPit, por lo que, a menos que especifique algo más, no se enviará ningún correo electrónico desde el entorno de desarrollo.
Puede acceder al mailpit a través de http: //ebau.local/mailpit/. Cualquier correo electrónico enviado será visible instantáneamente allí.
Sección para recopilar información sobre módulos y cantones. Esta sección está destinada a facilitar la transferencia de conocimientos, las transferencias de vacaciones y los casos de soporte de depuración.
Módulo utilizado en KT. Sz y Kt. Ur (pronto-ish), que acompaña el proceso de construcción después de la decisión. El municipio (hasta ahora solo los casos están cubiertos donde la autoridad principal es el municipio) y el solicitante interactúa a través de una serie de elementos de trabajo con documentos.
Hay etapas de construcción ("BauetAppen"), que consisten en pasos de construcción dinámicamente seleccionables. Los pasos de construcción son una serie de elementos de trabajo, que generalmente siguen el patrón de comenzar con un ítem de trabajo dirigido al solicitante, seguido de uno o más elementos de trabajo dirigidos al municipio. El solicitante confirma que se han adherido a las regulaciones definidas, y la muncipalidad lo verifica. El elemento laboral final permite que la muncipalidad decida si continuar el proceso o reiterarse al comienzo del paso de construcción.
El módulo está fuertemente definido por el flujo de trabajo configurado. Qué pasos de construcción y, por lo tanto, qué elementos de trabajo se realizan se maneja a través de tareas dinámicas. La configuración del paso de construcción (como qué tarea pertenece a qué paso de construcción) se configura en el meta de tareas que pertenecen a un paso de construcción. Los pasos de construcción son esencialmente una agrupación de tareas, no hay un modelo que los represente.
Las etapas de construcción son un elemento de trabajo de instancia múltiple con un caso infantil. El caso infantil contiene los elementos de trabajo del paso de construcción. La primera etapa de construcción se crea al inicializar el proceso de monitoreo de la construcción. Después de eso, se puede inicializar una nueva etapa de construcción mediante una mutación de trabajo de trabajo en el ítem de trabajo existente (en el estado listo). Tenga cuidado: para asegurarse de que siempre se pueda crear una nueva etapa de construcción siempre que el proceso de monitoreo de la construcción no se complete, los elementos de trabajo de la etapa de construcción permanecen listos, mientras que el caso infantil de la etapa de construcción ya se ha completado.
La lógica central está contenida principalmente en el flujo de trabajo de monitoreo de la construcción y la configuración de formulario del cantón, los eventos Caluma para la monitorización de la construcción, la configuración del módulo, algunas visibilidad personalizada y lógica de permiso.
En el Cantón de Solothurn utilizamos un mecanismo de autorización personalizado para el portal de EBAU. El portal de EBAU solo se puede usar con un inicio de sesión de my.so.ch, su software de portal EGOV. Como no ofrecen autorización OIDC, tuvimos que implementar una solución personalizada utilizando el intercambio de tokens de KeyCloak y las características directas de suplantación desnuda.
La autorización está diseñada para retener un token JWT encriptado y firmado que luego se convierte en un token JWT regular por KeyCloak:
secuencediagram
autónomo
Participante F como portal de eBau
Participante M como Portal EGOV
Participante B como API de eBau
Participante K como KeyCloak
F->>+M: redirigir a la prestación
Nota Derecho de M: Token JWT encriptado y firmado con datos del usuario
M->>-F: redirigir para iniciar sesión con el token EGOV
F->>+B: Enviar Token (Publicar a/API/V1/Auth/Token-Exchange)
B->> B: descifrar y verificar el token EGOV, extraer datos de usuario del token
B->>+K: Crear o actualizar el usuario
K->> B: Return User
B->> K: intercambio de tokens con suplantación desnuda directa
K->>-B: retorno de token para el usuario
B->>-F: Token de retorno
Para habilitar la función, se debe realizar la siguiente configuración:
Por defecto, KeyCloak ya está configurado correctamente para admitir este mecanismo de autorización. Para configurar otro entorno, consulte la documentación
# .env
ENABLE_TOKEN_EXCHANGE =trueEsto habilitará la función con un portal EGOV ficticio alojado en nuestro proxy Nginx. Para probar con el entorno de prueba de portal de EGOV, necesitamos establecer algunas variables de entorno más (los valores censurados se pueden encontrar en bóveda):
# .env
EGOV_PORTAL_URL =****
EGOV_PRESTATION_PATH =**** # django/.env
TOKEN_EXCHANGE_JWT_ISSUER =****
TOKEN_EXCHANGE_JWT_SECRET =****
TOKEN_EXCHANGE_JWE_SECRET =****Este proyecto tiene licencia bajo el EUPL-2-ORA. Vea la licencia para más detalles.
