ebau
1.0.0
Application de permis de construction électronique pour les cantons suisses.
Ce référentiel contient le code source des applications Web utilisées pour gérer les permis de construction électronique et les processus comparables dans les cantons suisses de Berne, Grisons, Schwyz, Solothurn et URI.
L'image suivante montre un aperçu de haut niveau de l'architecture:
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
En raison des travaux de modernisation en cours, certains modules de frontend ne sont pas encore intégrés dans ember-ebau , mais font toujours partie de ember-camac-ng . Peu de modules de frontend ne font pas encore partie de ce référentiel. Le tableau suivant répertorie les modules les plus importants de la partie "interne" de l'application et leur état d'exhaustivité / intégration respectif (dans la configuration demo ).
| Module | Description | Backend | L'extrémité avant | Partie d'Ember-Ebau |
|---|---|---|---|---|
| Nav principale (ressource) | ||||
| Liste de dossiers | Afficher une liste de dossiers | ✔️ | ✔️ | ✔️ |
| Liste de tâches | Afficher une liste de tâches | ✔️ | ✔️ | ✔️ |
| Modèles | Gérer les modèles de documents (DOCX) | ✔️ | ✔️ | ✔️ |
| Organisation / autorisation | Gérer la propre organisation et les autorisations | ✔️ | ✔️ | ✔️ |
| Contenu statique | Contenu statique, éditeur Markdown | ✔️ | ✔️ | ✔️ |
| Composants texte | Gérer les extraits pour l'utilisation dans les champs de texte | ✔️ | ⏳ | ⏳ |
| Subnav (ressource d'instance) | ||||
| Tâches | Afficher et gérer les tâches | ✔️ | ✔️ | ✔️ |
| Formulaire | Afficher et modifier la forme principale | ✔️ | ✔️ | ✔️ |
| Distribution | Obtenez des commentaires d'autres organisations | ✔️ | ✔️ | ✔️ |
| Alexandrie | Gestion des documents | ✔️ | ✔️ | ✔️ |
| Modèle | Générer un document à partir du modèle | ✔️ | ✔️ | ✔️ |
| Journal | Cahier collaboratif | ✔️ | ✔️ | ✔️ |
| Histoire | Montre des jalons et des données historiques | ✔️ | ✔️ | ✔️ |
| Publication | Gérer la publication dans le journal | ✔️ | ✔️ | ✔️ |
| Objections | Gérer les objections | ✔️ | ✔️ | ✔️ |
| Responsable | Affecter les utilisateurs responsables | ✔️ | ✔️ | ✔️ |
| Réclamations | Demandez au demandeur des informations supplémentaires | ✔️ | ✔️ | ✔️ |
| Rejet | Rejeter l'instance | ✔️ | ✔️ | ✔️ |
| Facturation | Gérer les entrées de facturation | ✔️ | ✔️ | ✔️ |
| Audit | Effectuer un audit structuré | ✔️ | ✔️ | ⏳ |
| Audit-logiciel | Montre les changements de forme | ✔️ | ⏳ | ⏳ |
L'environnement de développement préféré est basé sur Docker.
Pour le développement local:
Python:
Ember:
Docker peut être utilisé pour faire fonctionner Ebau rapidement. Le script suivant vous guide à travers le processus de configuration. Nous vous recommandons d'utiliser la configuration kt_gr ou kt_so pour l'instant, car d'autres cantons s'appuient toujours sur des composants hérités pour la zone interne qui ne font pas partie de ce référentiel.
make start-dev-envDans le cas où vous souhaitez modifier manuellement / etc / hôtes les domaines suivants, vous devez pointer à 127.0.0.1 (localhost):
ebau-portal.local ebau.local ebau-keycloak.local ember-ebau.local ebau-rest-portal.local
Pour les vérifications automatiques lors de la validation (formatage, libellé), vous pouvez configurer un crochet git avec les commandes suivantes:
pip install pre-commit
pre-commit installAprès, vous devriez pouvoir utiliser les services suivants:
Les comptes d'administrateur suivants sont présents dans Keyycloak ou dans la DB, respectivement:
| Application | Rôle | Nom d'utilisateur | Mot de passe | Notes |
|---|---|---|---|---|
| démo | Administrer | utilisateur | utilisateur | |
| kt_schwyz | Administrer | administrer | administrer | |
| Publication | adSy | adSy | ||
| kt_uri | Administrer | administrer | administrer | |
| Portalus | portail | portail | ||
| kt_bern | Administrer | utilisateur | utilisateur | |
| kt_gr | Administrer | administrer | administrer | |
| Demandeur | éditeur | éditeur | Rôle de l'éditeur du candidat | |
| Demandeur | lire en lecture | lire en lecture | Rôle du candidat en lecture | |
| kt_so | Administrer | administrer | administrer | |
| Demandeur | éditeur | éditeur | Rôle de l'éditeur du candidat | |
| Demandeur | lire en lecture | lire en lecture | Rôle du candidat en lecture |
make debug-django Avec Docker Compose, vous pouvez vous attacher à un conteneur en cours d'exécution (essentiellement équivalent à docker compose up sans l'indicateur -d ) et interagir via STDIN.
docker compose attach djangoCela vous permettra de
un. Envoyer des signaux au conteneur
né Passez à un shell PDB lorsque l'application se heurte à un breakpoint
Étant donné que la configuration Dev exécute le serveur de développement Django qui recharge sur les modifications du fichier, l'insertion de ces points d'arrêt est en vigueur immédiatement après l'enregistrement du fichier.
Appuyez sur CTRL-p + CTRL-q
Remarque: Étant donné que par défaut, le processus attach transmettra des signaux au conteneur, vous devrez sortir en appuyant sur ladite séquence (qui est le paramètre par défaut pour --detach-keys et peut être remplacé). La pressage de CTRL-c tuera non seulement le TTY, mais enverra également le Sigint dans le conteneur et l'arrête.
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 Comme il s'agit d'un grand projet avec beaucoup de fichiers, la configuration par défaut de Ember ne parviendra peut-être pas à reconstruire correctement car elle ne peut pas regarder tous ces fichiers.
Afin de résoudre ce problème, installez Watchman en tant que gardien de fichier et ajustez les paramètres inotify :
echo fs.inotify.max_user_watches=1000000 | sudo tee -a /etc/sysctl.conf # adjust settings
sudo sysctl -p # re-read configAssurez-vous que cette dernière commande ne renvoie qu'une seule valeur, sinon les paramètres sont dupliqués et doivent être nettoyés.
Notez cependant que les applications ember-caluma-portal , ember-camac-ng , ember-ebau et l'Addon ember-ebau-core partagent le même arbre de modules de nœud via un espace de travail PNPM.
L'espace de travail PNPM commun nous permet de partager du code (par exemple des addons) entre les applications qui font partie de ce repo (au lieu de suivre l'approche typique de la publication des versions sur NPM). Cela signifie aussi que
node_modulesember-camac-ng ) Les versions ember-caluma-portal Pour activer django-silk pour le profilage, ajoutez simplement DJANGO_ENABLE_SILK=True à votre fichier django/.env . Redémarrez ensuite le conteneur Django et parcourez http: //ebau.local/api/silk/.
Pour passer de la configuration demo à kt_bern , il faut s'assurer que les applications Frontend occupent les bonnes variables d'environnement.
pnpm start-proxymake kt_berndocker-compose up -d && make loadconfigdocker-compose downmake kt_berndocker-compose builddocker-compose up -dLes paramètres de débogueur distant pour le code vs sont attachés au référentiel.
.vscode/launch.json . Pour activer le débogage dans le conteneur Django, le serveur PTVSD doit être démarré. Étant donné que ce serveur de débogage entre en collision avec d'autres configurations (pycharm, pydev), il ne sera démarré que si le var ENABLE_PTVSD_DEBUGGER ne sera défini sur True dans django/.env .
Afin de parler au point de terminaison /graphql avec l'authentification, vous pouvez installer un outil GraphQL (un peu comme Postman). Outils que vous pourriez considérer ici:
Le module GWR est développé dans deux référentiels distincts:
Si vous utilisez le module GWR, vous devez générer une clé Fernet en fonction de la documentation du backend GWR.
Vous devez définir cette clé dans chaque environnement / serveur dans votre fichier env. Générez une clé distincte pour chaque environnement, car celle-ci est utilisée pour stocker / lire les mots de passe utilisateur GWR.
L'API doit être conçue d'une manière, ce qui lui permet d'être utilisé par n'importe quel projet Ebau. Pour la personnalisation nécessaire, les règles suivantes s'appliquent:
Pour différents indicateurs de fonctionnalité et autorisations, consultez APPLICATIONS dans Settings.py.
En mode développement, l'application est configurée pour envoyer tous les e-mails à une instance Mailpit, donc à moins que vous ne spécifiez autre chose, aucun e-mail ne sera envoyé depuis l'environnement de développement.
Vous pouvez accéder au Mailpit via http: //ebau.local/mailpit/. Tout e-mail envoyé sera instantanément visible là-bas.
Section pour collecter des informations sur les modules et les cantons. Cette section est destinée à faciliter le transfert de savoir-faire, les transactions de vacances et les cas de support de débogage.
Module utilisé dans Kt. SZ et KT. Ur (bientôt-ish), qui accompagne le processus de construction après la décision. La municipalité (jusqu'à présent, seuls les cas sont couverts lorsque l'autorité principale est la municipalité) et que le demandeur interagit par une série de documents de travail avec des documents.
Il existe des étapes de construction ("Bauetappen"), qui se composent d'étapes de construction dynamiquement sélectionnables. Les étapes de construction sont une série d'ateliers de travail, qui suivent généralement le modèle de démarrage par un élément de travail adressé au demandeur, suivi d'un ou plusieurs éléments de travail adressés à la municipalité. Le demandeur confirme qu'ils ont respecté les réglementations définies et la muncipalité la vérifie. L'élément de travail final permet à la muncipalité de décider de poursuivre le processus ou de réitérer au début de l'étape de construction.
Le module est fortement défini par le flux de travail configuré. Quelles étapes de construction et par conséquent quels éléments de travail sont effectués est géré par des tâches dynamiques. La configuration de l'étape de construction (telle que la tâche appartient à quelle étape de construction) est configurée dans la méta-tâches appartenant à une étape de construction. Les étapes de construction sont essentiellement un regroupement de tâches, aucun modèle ne les représente.
Les étapes de construction sont un élément de travail multiple par exemple avec un enfant-enfant. L'éclat contient les éléments de travail des étapes de construction. La première étape de construction est créée lors de l'initialisation du processus de surveillance de la construction. Après cela, une nouvelle étape de construction peut être initialisée par une mutation de création de travail sur le travail de travail existant (dans le statut prêt). Attention: pour vous assurer qu'une nouvelle étape de construction peut toujours être créée tant que le processus de surveillance de la construction n'est pas terminé, les articles de travail de la phase de construction restent prêts, tandis que le boîtier des enfants de la scène de construction a déjà été achevé.
La logique de base est contenue principalement dans le flux de travail de surveillance de la construction et la configuration du formulaire du canton, les événements Caluma pour la surveillance de la construction, les paramètres du module, une certaine visibilité et logique d'autorisation personnalisées.
Dans le canton de Solothurn, nous utilisons un mécanisme d'autorisation personnalisé pour le portail Ebau. Le portail Ebau ne peut être utilisé qu'avec une connexion de My.so.ch, leur logiciel de portail Egov. Puisqu'ils n'offrent pas d'autorisation OIDC, nous avons dû implémenter une solution personnalisée en utilisant l'échange de jetons de KeyCloak et les fonctionnalités d'identité Naked Direct Naked.
L'autorisation est conçue pour retarder un jeton JWT crypté et signé qui est ensuite converti en un jeton JWT OIDC ordinaire par Keycloak:
séquenchestre
nombre automatique
Participant F en tant que portail eBau
participant m comme portail egov
Participant B en API Ebau
Participant K comme Keycloak
F - >> + M: Rediriger vers la pré-pré-prédiction
Remarque Droit de M: Token JWT crypté et signé avec des données utilisateur
M - >> - F: Rediriger vers la connexion avec le jeton EGOV
F - >> + B: Envoyer un jeton (publication sur / api / v1 / auth / token-échange)
B - >> b: décrypter et vérifier le jeton EGOV, extraire les données utilisateur de jeton
B - >> + k: créer ou mettre à jour l'utilisateur
K - >> b: retourner l'utilisateur
B - >> k: échange de jetons avec une imitation directe nue
K - >> - B: Retour token pour l'utilisateur
B - >> - F: Token de retour
Pour activer la fonctionnalité, la configuration suivante doit être effectuée:
Par défaut, KeyCloak est déjà correctement configuré pour prendre en charge ce mécanisme d'autorisation. Afin de configurer un autre environnement, veuillez vous référer à la documentation
# .env
ENABLE_TOKEN_EXCHANGE =trueCela permettra la fonctionnalité avec un portail Egov factice hébergé sur notre proxy Nginx. Afin de tester avec l'environnement de test du portail EGOV, nous devons définir d'autres variables d'environnement (les valeurs censurées peuvent être trouvées dans Vault):
# .env
EGOV_PORTAL_URL =****
EGOV_PRESTATION_PATH =**** # django/.env
TOKEN_EXCHANGE_JWT_ISSUER =****
TOKEN_EXCHANGE_JWT_SECRET =****
TOKEN_EXCHANGE_JWE_SECRET =****Ce projet est concédé sous licence en vertu de l'EUPL-1.2-ou-later. Voir la licence pour plus de détails.
