ebau
1.0.0
スイスカントンの電子ビルディング許可申請。
このリポジトリには、Berne、Grisons、Schwyz、Solothurn、URIのスイスカントンでの電子ビルディングの許可と同等のプロセスを処理するために使用されるWebアプリケーションのソースコードが含まれています。
次の画像は、アーキテクチャの高レベルの概要を示しています。
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
進行中の近代化作業により、一部のフロントエンドモジュールはまだember-ebauに統合されていませんが、代わりにember-camac-ngの一部です。このリポジトリの一部ではないフロントエンドモジュールはほとんどありません。次の表には、アプリケーションの「内部」部分とそれぞれの完全性 /統合状態（ demo構成）の最も重要なモジュールを示します。
| モジュール | 説明 | バックエンド | フロントエンド | Ember-Ebauの一部 |
|---|---|---|---|---|
| メインナビット（リソース） | ||||
| 関係書類リスト | 関係書類のリストを表示します | ✔✔️ | ✔✔️ | ✔✔️ |
| タスクリスト | タスクのリストを表示します | ✔✔️ | ✔✔️ | ✔✔️ |
| テンプレート | ドキュメントテンプレートを管理する（docx） | ✔✔️ | ✔✔️ | ✔✔️ |
| 組織 /許可 | 独自の組織と権限を管理します | ✔✔️ | ✔✔️ | ✔✔️ |
| 静的コンテンツ | 静的コンテンツ、マークダウンエディター | ✔✔️ | ✔✔️ | ✔✔️ |
| テキストコンポーネント | テキストフィールドで使用するためにスニペットを管理します | ✔✔️ | ⏳ | ⏳ |
| subnav（インスタンスリソース） | ||||
| タスク | タスクを表示および管理します | ✔✔️ | ✔✔️ | ✔✔️ |
| 形状 | メインフォームを表示および編集します | ✔✔️ | ✔✔️ | ✔✔️ |
| 分布 | 他の組織からフィードバックを取得します | ✔✔️ | ✔✔️ | ✔✔️ |
| アレクサンドリア | ドキュメント管理 | ✔✔️ | ✔✔️ | ✔✔️ |
| テンプレート | テンプレートからドキュメントを生成します | ✔✔️ | ✔✔️ | ✔✔️ |
| ジャーナル | 共同ノートブック | ✔✔️ | ✔✔️ | ✔✔️ |
| 歴史 | マイルストーンと履歴データを示します | ✔✔️ | ✔✔️ | ✔✔️ |
| 出版 | 新聞で出版を管理します | ✔✔️ | ✔✔️ | ✔✔️ |
| 異議 | 異議を管理します | ✔✔️ | ✔✔️ | ✔✔️ |
| 責任者 | 責任あるユーザーを割り当てます | ✔✔️ | ✔✔️ | ✔✔️ |
| クレーム | 追加情報については、申請者にお問い合わせください | ✔✔️ | ✔✔️ | ✔✔️ |
| 拒絶 | インスタンスを拒否します | ✔✔️ | ✔✔️ | ✔✔️ |
| 請求する | 請求エントリを管理します | ✔✔️ | ✔✔️ | ✔✔️ |
| 監査 | 構造化された監査を実行します | ✔✔️ | ✔✔️ | ⏳ |
| 監査ログ | フォームの変更を表示します | ✔✔️ | ⏳ | ⏳ |
好ましい開発環境は、Dockerに基づいています。
ローカル開発のため：
Python：
エンバー：
Dockerは、EBAUを迅速に稼働させるために使用できます。次のスクリプトは、セットアッププロセスをガイドします。他のカントンは、このリポジトリの一部ではない内部エリアのレガシーコンポーネントに依存しているため、今のところkt_grまたはkt_so構成を使用することをお勧めします。
make start-dev-env次のドメインを手動で変更する必要がある場合は、127.0.0.1（localhost）を指す必要があります。
ebau-portal.local ebau.local ebau-keycloak.local ember-ebau.local ebau-rest-portal.local
コミット中の自動チェック（フォーマット、糸くず）の場合、次のコマンドでGitフックをセットアップできます。
pip install pre-commit
pre-commit installその後、次のサービスに使用できるはずです。
次の管理者アカウントは、それぞれkeycloakまたはDBに存在します。
| 応用 | 役割 | ユーザー名 | パスワード | メモ |
|---|---|---|---|---|
| デモ | 管理者 | ユーザー | ユーザー | |
| kt_schwyz | 管理者 | 管理者 | 管理者 | |
| 公開 | Adsy | Adsy | ||
| kt_uri | 管理者 | 管理者 | 管理者 | |
| Portaluser | ポータル | ポータル | ||
| kt_bern | 管理者 | ユーザー | ユーザー | |
| KT_GR | 管理者 | 管理者 | 管理者 | |
| 申請者 | エディタ | エディタ | 申請者の編集者の役割 | |
| 申請者 | 読みます | 読みます | 申請者は読み取られます | |
| KT_SO | 管理者 | 管理者 | 管理者 | |
| 申請者 | エディタ | エディタ | 申請者の編集者の役割 | |
| 申請者 | 読みます | 読みます | 申請者は読み取られます |
make debug-djangoDocker Composeを使用すると、実行中のコンテナ（基本的には-dフラグなしでdocker compose upに相当）に取り付けて、STDINを介して対話できます。
docker compose attach djangoこれにより、
a。コンテナに信号を送信します
b。アプリケーションがbreakpointに実行されたときにPDBシェルにドロップします
DEV構成はファイルの変更でリロードするDjango Development-Serverを実行するため、これらのブレークポイントを挿入すると、ファイルを保存した直後に有効になります。
CTRL-p + CTRL-q押します
注：デフォルトでは、 attachプロセスはコンテナに信号を転送するため、そのシーケンスを押す必要があります（これは--detach-keysのデフォルト設定であり、オーバーライドできます）。ただし、 CTRL-c押すと、TTYを殺すだけでなく、Sigintをコンテナに送信して停止します。
ドキュメント：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 これは多くのファイルを備えた大規模なプロジェクトであるため、Emberのデフォルトのセットアップは、これらすべてのファイルを視聴できないため、適切に再構築できない可能性があります。
それを修正するには、Watchmanをファイルウォッチャーとしてインストールし、 inotify設定を調整します。
echo fs.inotify.max_user_watches=1000000 | sudo tee -a /etc/sysctl.conf # adjust settings
sudo sysctl -p # re-read config後者のコマンドが1つの値のみを返すことを確認してください。そうしないと、設定が複製されており、クリーンアップする必要があります。
ただし、Apps ember-caluma-portal 、 ember-camac-ng 、 ember-ebau 、およびAddon ember-ebau-core PNPMワークスペースを通じて同じノードモジュールツリーを共有していることに注意してください。
一般的なPNPMワークスペースを使用すると、このレポの一部であるアプリ間でコード（アドオンなど）を共有できます（NPMでリリースを公開する典型的なアプローチに従うのではなく）。これもそれを意味します
node_modulesディレクトリの避けられた重複のために、いくつかのディスクスペースを保存しますember-caluma-portalおよびember-camac-ngを同期させる必要がありますプロファイリングにdjango-silk有効にするには、 DJANGO_ENABLE_SILK=True django/.envファイルにtrueを追加するだけです。次に、djangoコンテナを再起動し、http：//ebau.local/api/silk/を参照します。
demo構成からkt_bernに切り替えるには、FrontEndアプリが適切な環境変数を取り上げることを確認する必要があります。
pnpm start-proxyで開始されたFrontEndサーバーを停止しますmake kt_bern実行しますdocker-compose up -d && make loadconfig実行しますdocker-compose downしますmake kt_bern実行しますdocker-compose buildを実行しますdocker-compose up -dを実行しますVSコードのリモートデバッガー設定は、リポジトリにコミットされます。
.vscode/launch.jsonにあります。Djangoコンテナでデバッグを有効にするには、PTVSDサーバーを開始する必要があります。このデバッグサーバーは他のセットアップ（Pycharm、Pydev）と衝突するため、Env var ENABLE_PTVSD_DEBUGGERがdjango/.envでTrueに設定されている場合にのみ開始されます。
/graphqlエンドポイントに認証を使用して通信するために、GraphQLツール（郵便配達員と同様）をインストールできます。ここで検討するツール：
GWRモジュールは、2つの別々のリポジトリで開発されています。
GWRモジュールを使用する場合、GWRバックエンドのドキュメントに従ってフェルネットキーを生成する必要があります。
各環境/サーバーにこのキーをenvファイルに設定する必要があります。 GWRユーザーパスワードの保存 /読み取りに使用されるため、各環境に個別のキーを生成します。
APIは、EBAUプロジェクトで使用できるようにする方法で設計する必要があります。必要なカスタマイズには、次のルールが適用されます。
さまざまな機能フラグと権限については、settings.pyのAPPLICATIONSを参照してください。
開発モードでは、アプリケーションはすべての電子メールをMailPitインスタンスに送信するように構成されているため、他の何かを指定しない限り、開発環境から電子メールは送信されません。
http：//ebau.local/mailpit/からMailPitにアクセスできます。送信されたメールはすべてすぐに表示されます。
モジュールとカントンに関する情報を収集するセクション。このセクションは、ノウハウの転送、休暇の拳銃、デバッグサポートケースを促進することを目的としています。
KTで使用されるモジュール。 SZとKT。決定後の建設プロセスに伴うUR（SOON-ISH）。自治体（これまでの場合、主要な当局が自治体である場合にのみケースがカバーされています）と申請者は、文書の一連の作業を通じて対話します。
動的に選択可能な構造ステップで構成される構造段階（ "Bauetappen"）があります。建設手順は一連の作業項目であり、通常、申請者に宛てられた作業項目から始まるパターンに従い、その後、自治体に宛てられた1つ以上の作業項目が続きます。申請者は、彼らが定義された規制を順守していることを確認し、局所性はそれを検証します。最終作業項目により、ムンシパリティは、プロセスを継続するか、建設ステップの開始まで繰り返すかを決定できます。
モジュールは、構成されたワークフローによって大きく定義されています。どの構築ステップ、したがって、どの作業項目が実行されるかは、動的タスクを介して処理されます。建設ステップ構成（どのタスクがどの建設ステップに属しているかなど）は、建設ステップに属するタスクのメタで構成されています。建設手順は基本的にタスクのグループ化であり、それらを表すモデルはありません。
建設段階は、子育てを備えた複数のインスタンスワークアイテムです。保育ケースには、構築ステップの作業項目が含まれています。最初の建設段階は、建設監視プロセスを初期化するときに作成されます。その後、新しい建設段階は、既存の作業項目上の作成項目変異を作成することで初期化できます（ステータス対応）。注意してください：建設監視プロセスが完了しない限り、新しい建設段階を常に作成できるようにするために、建設段階の子どものケースはすでに完了している間、建設段階の作業項目の準備が整い続けています。
コアロジックは、主に建設監視ワークフローと、カントンの形式構成、建設監視のためのCalumaイベント、モジュール設定、カスタムの可視性、許可ロジックの形式に含まれています。
Solothurnのカントンでは、EBAUポータルにカスタム認証メカニズムを使用しています。 EBAUポータルは、eGoVポータルソフトウェアのmy.so.chからのログインでのみ使用できます。彼らはOIDC認証を提供していないため、Keycloakのトークン交換と直接の裸のなりすまし機能を使用してカスタムソリューションを実装する必要がありました。
承認は、暗号化され、署名されたJWTトークンを再生するように設計されており、その後、Keycloakによって通常のOIDC JWTトークンに変換されます。
Sequendediagram
Autonumber
EBAUポータルとしての参加者f
EGOVポータルとしての参加者M
EBAU APIとしての参加者B
Keycloakとしての参加者K
f- >>+m：Prestationにリダイレクトします
メモM：ユーザーデータを使用して暗号化および署名JWTトークン
M- >> - F：EGOVトークンでログインするためにリダイレクトします
f- >>+b：トークンを送信します（/api/v1/auth/token-exchangeに投稿）
b- >> b：egovトークンを復号化して検証し、トークンからユーザーデータを抽出します
b- >>+k：ユーザーを作成または更新します
K- >> B：ユーザーを返します
B- >> K：直接の裸のなりすましとのトークン交換
K- >> - B：ユーザーのトークンを返します
b- >> - f：トークンを返します
機能を有効にするには、次の構成を実行する必要があります。
デフォルトでは、KeyCloakは既にこの承認メカニズムをサポートするように適切に構成されています。別の環境を構成するために、ドキュメントを参照してください
# .env
ENABLE_TOKEN_EXCHANGE =trueこれにより、NginxプロキシでホストされているダミーEGOVポータルを使用して機能が可能になります。 EGOVポータルテスト環境でテストするには、さらにいくつかの環境変数を設定する必要があります（検閲された値はVaultにあります）。
# .env
EGOV_PORTAL_URL =****
EGOV_PRESTATION_PATH =**** # django/.env
TOKEN_EXCHANGE_JWT_ISSUER =****
TOKEN_EXCHANGE_JWT_SECRET =****
TOKEN_EXCHANGE_JWE_SECRET =****このプロジェクトは、EUPL-1.2-OR-Laterの下でライセンスされています。詳細については、ライセンスを参照してください。
