building-envelope-data · simonwacker · Jun 30, 2026 · Apr 13, 2026 · Mar 27, 2026 · Mar 28, 2026
diff --git a/.env.development.sample b/.env.development.sample
@@ -19,8 +19,14 @@ TESTLAB_SOLAR_FACADES_OPEN_ID_CONNECT_CLIENT_SECRET=secret
 IGSDB_API_TOKEN=secret
 IGSDB_OPEN_ID_CONNECT_CLIENT_SECRET=secret
 
+EPEA_USER_ID=christoph.maurer@ise.fraunhofer.de
+EPEA_API_KEY=secret
+EPEA_OPEN_ID_CONNECT_CLIENT_SECRET=secret
+
 OPEN_TELEMETRY_HOST=host.docker.internal
 OPEN_TELEMETRY_GRPC_PORT=4017
 
+EMAIL_ADDRESS=christoph.maurer@ise.fraunhofer.de
+
 SMTP_HOST=email
 SMTP_PORT=25
diff --git a/.env.production.sample b/.env.production.sample
@@ -18,10 +18,16 @@ TESTLAB_SOLAR_FACADES_OPEN_ID_CONNECT_CLIENT_SECRET=
 IGSDB_API_TOKEN=
 IGSDB_OPEN_ID_CONNECT_CLIENT_SECRET=
 
+EPEA_USER_ID=christoph.maurer@ise.fraunhofer.de
+EPEA_API_KEY=
+EPEA_OPEN_ID_CONNECT_CLIENT_SECRET=
+
 OPEN_TELEMETRY_HOST=host.docker.internal
 OPEN_TELEMETRY_GRPC_PORT=4317
 
-SMTP_HOST=mail-mtaKA26.fraunhofer.de
+EMAIL_ADDRESS=christoph.maurer@ise.fraunhofer.de
+
+SMTP_HOST=mta01.mx.fraunhofer.de
 SMTP_PORT=25
 RELAY_SMTP_HOST=
 RELAY_SMTP_PORT=25

diff --git a/.env.staging.sample b/.env.staging.sample
@@ -18,11 +18,17 @@ TESTLAB_SOLAR_FACADES_OPEN_ID_CONNECT_CLIENT_SECRET=
 IGSDB_API_TOKEN=
 IGSDB_OPEN_ID_CONNECT_CLIENT_SECRET=
 
+EPEA_USER_ID=christoph.maurer@ise.fraunhofer.de
+EPEA_API_KEY=
+EPEA_OPEN_ID_CONNECT_CLIENT_SECRET=
+
 OPEN_TELEMETRY_HOST=host.docker.internal
 OPEN_TELEMETRY_GRPC_PORT=4317
 
+EMAIL_ADDRESS=christoph.maurer@ise.fraunhofer.de
+
 SMTP_HOST=email
 SMTP_PORT=25
-RELAY_SMTP_HOST=mail-mtaKA26.fraunhofer.de
+RELAY_SMTP_HOST=mta01.mx.fraunhofer.de
 RELAY_SMTP_PORT=25
 RELAY_ALLOWED_EMAILS=
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -119,6 +119,12 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 -
 -
 
+## [v1.2.0] - 2026-06-30
+
+### Changed
+
+- **BREAKING**: Use `String` for cursors and `Int` for `first` and `last` parameters to conform to the Relay connection specification, simplify GraphQL filter input type names, and correct plural names ending before in `ys` and now in `ies` [#274](https://github.com/building-envelope-data/metabase/pull/274)
+
 ## [v1.1.1] - 2026-04-13
 
 ### Added
@@ -154,10 +160,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [v1.0.0] - 2022-02-28
 
-[Unreleased]: https://github.com/building-envelope-data/metabase/compare/v1.1.1...HEAD
-
+[Unreleased]: https://github.com/building-envelope-data/metabase/compare/v1.2.0...HEAD
+[v1.2.0]: https://github.com/building-envelope-data/metabase/compare/v1.1.1...v1.2.0
 [v1.1.1]: https://github.com/building-envelope-data/metabase/compare/v1.1.0...v1.1.1
-
 [v1.1.0]: https://github.com/building-envelope-data/metabase/compare/v1.0.0...v1.1.0
-
 [v1.0.0]: https://github.com/building-envelope-data/metabase/compare/5e4c6579bc7b596502c0bc9318cf24435bed2c80...v1.0.0
diff --git a/README.md b/README.md
@@ -85,7 +85,7 @@ When doing so, please adhere to our
    - OpenAPI reference at `https://www.local.buildingenvelopedata.org:${HTTPS_PORT}/openapi/docs/`,
    - dummy email server at `https://www.local.buildingenvelopedata.org:${HTTPS_PORT}/email/`
      (to view for example the confirmation email sent during registration),
-   - OpenId Connect configuration at
+   - OpenID Connect configuration at
      `https://www.local.buildingenvelopedata.org:${HTTPS_PORT}/.well-known/openid-configuration`,
    - telemetry web frontend at `https://telemetry.local.buildingenvelopedata.org:${HTTPS_PORT}`,
    - staging web frontend at `https://staging.local.buildingenvelopedata.org:${HTTPS_PORT}`,
@@ -275,17 +275,23 @@ and the pages following it.
       some information on what the variables mean
       - `NAME` is the name Docker project name, in particular, it is the prefix
         of the Docker container names listed by `docker ps --all`;
+      - `ENVIRONMENT` is either `staging` or `production`;
+      - `TARGET` is the deployed tag or commit. It is set later by running
+        `./deploy.mk do TARGET=${TAG}`. The corresponding Docker images named
+        `${NAME}-backend:${TARGET}` and `${NAME}-frontend:${TARGET}` are built
+        on a build or development machine and pushed to the server later with
+        GNU Make targets from `./forge.mk`;
       - `HOST` is the domain name with sub-domain of the deployment, in
-        particular, it is used by the OpenId Connect provider and to make
+        particular, it is used by the OpenID Connect provider and to make
         URLs absolute in emails sent for example when a user registers;
       - `HTTP_PORT` is the HTTP port on which the reverse proxy NGINX listens
         for requests;
       - `BOOTSTRAP_USER_PASSWORD` is the password used by the database seeder
         for the administrator account if there is none yet;
-      - `OPEN_ID_CONNECT_CLIENT_SECRET` is the OpenId Connect client secret of
+      - `OPEN_ID_CONNECT_CLIENT_SECRET` is the OpenID Connect client secret of
         the metabase as a client of itself as identity provider;
       - `TESTLAB_SOLAR_FACADES_HOST` is the host with sub-domain of the TestLab
-        Solar Façades used by the database seeder to add it as an OpenId
+        Solar Façades used by the database seeder to add it as an OpenID
         Connect client;
       - `TESTLAB_SOLAR_FACADES_OPEN_ID_CONNECT_CLIENT_SECRET` is the
         corresponding client secret;
@@ -302,7 +308,17 @@ and the pages following it.
       - `ln --symbolic ./docker.mk ./Makefile` and
       - `ln --symbolic ./docker-compose.production.yaml ./docker-compose.yaml`.
 
-   1. Create the PostgreSQL database by running `./database.mk create`.
+   1. Switch to the Git branch, tag, or commit you want to deploy by either running
+      `git switch ${BRANCH}`,
+      `git switch release/${TAG}`, or
+      `git switch --detach ${COMMIT_HASH}`,
+      where, for example, `${BRANCH}` is `develop` or `${TAG}` is `v1.0.0` or
+      `${COMMIT_HASH}` is `5e14d7d0858f26c00c82ab9c248cd750606a24b6`.
+
+   1. Create the PostgreSQL database and schema by running
+      `./database.mk create migrate`.
+
+   1. Build and start all services by running `make build up`.
 
 ### Creating a release
 
@@ -318,7 +334,7 @@ and the pages following it.
    a new release" on
    [Releases](https://github.com/building-envelope-data/metabase/releases).
 1. Fetch the release branch by running `git fetch` and switch to it by running
-   `git switch --detach release/v*.*.*`, where `*.*.*` is the version.
+   `git switch release/v*.*.*`, where `*.*.*` is the version.
 1. If the databases have not diverged, then apply pending migrations with
    `./database.mk migrate`. Otherwise, recreate the database by running
    `./database.mk drop create migrate`.
@@ -330,11 +346,11 @@ and the pages following it.
 ### Deploying a release
 
 1. Fetch the release branch by running `git fetch` and switch to it by running
-   `git switch --detach release/${TAG}`, where `${TAG}` is the release tag to
+   `git switch release/${TAG}`, where `${TAG}` is the release tag to
    be deployed, for example, `v1.0.0`.
 1. Build and push the Docker images for the services `frontend` and `backend`
-   services by running `./forge.mk all USER=cloud HOST=${IP}`, where `${IP}` is
-   the server's IP address.
+   by running `./forge.mk all USER=cloud HOST=${IP}`, where `${IP}` is the
+   server's IP address.
 1. Enter a shell on the production machine using `ssh`.
 1. Navigate into `/app/production` by running `cd /app/production`.
 1. Back up the production database by running
@@ -347,34 +363,57 @@ and the pages following it.
 1. Deploy the new release in the staging environment by running
    `./deploy.mk do TARGET=${TAG}`, where `${TAG}` is
    the release tag to be deployed, for example, `v1.0.0`.
-1. If it fails _after_ the database backup was made, rollback to the previous
-   state by running
-   `./deploy.mk rollback`,
-   figure out what went wrong, apply the necessary fixes to the codebase,
-   create a new release, and try to deploy that release instead.
+1. If it fails rollback to the previous state by running
+   `./deploy.mk rollback`, figure out what went wrong, apply the necessary
+   fixes to the codebase, create a new release, and try to deploy that release
+   instead.
 1. If it succeeds, deploy the new reverse proxy that handles sub-domains by
    running `cd /app/machine && ./deploy.mk do` and test whether everything works
-   as expected and if that is the case, continue. Note that in the
-   staging environment sent emails can be viewed in the web browser under
-   `https://staging.buildingenvelopedata.org/email/` and emails to addresses in
-   the variable `RELAY_ALLOWED_EMAILS` in `./.env` are delivered to the
-   respective inboxes (the variable's value is a comma separated list of email
-   addresses). Note that in order for OpenId Connect to work as expected in
-   staging, make sure that the redirect URIs use the sub-domain `staging`
-   (instead of `www`) by entering `psql` with `./database.mk psql`, examining
-   the output of the SQL statement
-   `select * from metabase."OpenIddictApplications";`
-   and if necessary executing SQL statements along the lines
-   `update metabase."OpenIddictApplications" set "RedirectUris"='["https://staging.buildingenvelopedata.org/connect/callback/login/metabase"]', "PostLogoutRedirectUris"='["https://staging.buildingenvelopedata.org/connect/callback/logout/metabase"]' where "ClientId"='metabase';`
-   and
-   `update metabase."OpenIddictApplications" set "RedirectUris"='["https://staging.solarbuildingenvelopes.com/connect/callback/login/metabase"]', "PostLogoutRedirectUris"='["https://staging.solarbuildingenvelopes.com/connect/callback/logout/metabase"]' where "ClientId"='testlab-solar-facades';`
-   And if you want the staging environment to forward queries to the staging
-   environments of product-data databases, then examine the output of the SQL
-   statement `select * from metabase.database;` and if necessary execute SQL
-   statements along the lines
-   `update metabase.database set "Locator"='https://staging.solarbuildingenvelopes.com/graphql/' where "Locator"='https://www.solarbuildingenvelopes.com/graphql/';`
-   and
-   `update metabase.database set "Locator"='https://igsdb-v2-staging.herokuapp.com/graphql/' where "Locator"='https://igsdb-v2.herokuapp.com/graphql/';`
+   as expected and if that is the case, continue.
+   - In the staging environment sent emails can be viewed in the web browser
+     under `https://staging.buildingenvelopedata.org/email/` and emails to
+     addresses in the variable `RELAY_ALLOWED_EMAILS` in `./.env` are delivered
+     to the respective inboxes (the variable's value is a comma separated list of
+     email addresses).
+
+   - If you want the staging environment to forward queries to the staging
+     environments of product-data databases, then examine the output of the SQL
+     statement `select * from metabase.database;` and if necessary execute SQL
+     statements along the lines
+
+     ```
+     update metabase.database set "Locator" = 'https://staging.solarbuildingenvelopes.com/graphql/' where "Locator" = 'https://www.solarbuildingenvelopes.com/graphql/';
+     update metabase.database set "Locator" = 'https://igsdb-v2-staging.herokuapp.com/graphql/' where "Locator" = 'https://igsdb-v2.herokuapp.com/graphql/';
+     ```
+
+   - In order for OpenID Connect to work in staging,
+     - replace `OPEN_ID_CONNECT_CLIENT_SECRET` in `/app/staging/.env` by the
+       respective value in `/app/production/.env` and run `make up` to recreate
+       Docker compose services which depend on that value. If you have a
+       staging deployment of a
+       [product-data database](https://github.com/building-envelope-data/database)
+       that communicates with the staging deployment of the metabase, then
+       replace `OPEN_ID_CONNECT_CLIENT_SECRET` there also. Both changes are
+       necessary to make the OpenID Connect clients in metabase and product-data
+       database use the client secret whose hash value is stored in the metabase;
+
+     - make sure that the redirect URIs and resource permissions use the
+       sub-domain `staging` (instead of `www`) by entering `psql` with
+       `./database.mk psql`, examining the output of the SQL statement
+       `select * from metabase."OpenIddictApplications";`
+       and, if necessary, executing SQL statements along the lines
+
+       ```
+       update metabase."OpenIddictApplications" set "RedirectUris" = '["https://staging.buildingenvelopedata.org/connect/callback/login/metabase"]', "PostLogoutRedirectUris" = '["https://staging.buildingenvelopedata.org/connect/callback/logout/metabase"]' where "ClientId" = 'metabase';
+       update metabase."OpenIddictApplications" set "RedirectUris" = '["https://staging.solarbuildingenvelopes.com/connect/callback/login/metabase"]', "PostLogoutRedirectUris" = '["https://staging.solarbuildingenvelopes.com/connect/callback/logout/metabase"]' where "ClientId" = 'testlab-solar-facades';
+       ```
+
+       and
+
+       ```
+       update metabase."OpenIddictApplications" set "Permissions" = ("Permissions"::jsonb - 'rsrc:https://www.buildingenvelopedata.org/graphql/' || '"rsrc:https://staging.buildingenvelopedata.org/graphql/"'::jsonb)::text where "ClientId" = 'metabase';
+       ```
+
 1. Change to the production environment by running `cd /app/production`.
 1. Adapt the environment file `./.env` if necessary by comparing it with the
    `./.env.production.sample` file of the release to be deployed.
@@ -489,7 +528,7 @@ calculations.
 The access right management of the product data network is based on the
 framework [OpenID Connect](https://openid.net/developers/how-connect-works/).
 The general idea is that users and applications can authenticate at the
-metabase (OpenId Connect Provider) and receive an access token (security
+metabase (OpenID Connect Provider) and receive an access token (security
 credentials). When an application sends queries and mutations to product data
 servers, it can attach the token. The product data server receives the token
 and determines the access rights accordingly (authorization) using information
@@ -540,11 +579,11 @@ data server, please
    to your institution. For `${UUID_OF_YOUR_INSTITUTION}` please use the UUID
    which your institution has received when it was created.
 
-1. equip your product data server with an OpenId Connect Client partly configuring
+1. equip your product data server with an OpenID Connect Client partly configuring
    it via OpenID Connect Discovery using the [Well-Known Configuration
    Endpoint](https://www.buildingenvelopedata.org/.well-known/openid-configuration).
 
-When adding an OpenId Connect Application, you need to make various decisions:
+When adding an OpenID Connect Application, you need to make various decisions:
 [Which OAuth 2.0 Flow Should
 I Use?](https://auth0.com/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use)
 We support the [Authorization Code Flow with Pushed Authorization Requests

diff --git a/backend/Directory.Build.props b/backend/Directory.Build.props
@@ -13,6 +13,8 @@
     <RunAnalyzersDuringLiveAnalysis>true</RunAnalyzersDuringLiveAnalysis>
     <AnalysisLevel>latest-Recommended</AnalysisLevel>
     <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
+    <!-- files are emitted to ./backend/src/obj/Debug/netX.X/generated -->
+    <EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles>
   </PropertyGroup>
 
 </Project>
diff --git a/backend/Dockerfile.development b/backend/Dockerfile.development
@@ -1,4 +1,4 @@
-# syntax=docker/dockerfile:1.21
+# syntax=docker/dockerfile:1.23
 # check=error=true;skip=SecretsUsedInArgOrEnv
 # Available versions are listed on https://hub.docker.com/r/docker/dockerfile
 
@@ -144,6 +144,28 @@ RUN \
   --force \
   /var/lib/apt/lists/*
 
+# for available versions see the tags on https://github.com/stripe/pg-schema-diff
+ENV PG_SCHEMA_DIFF_VERSION=v1.0.5
+RUN \
+  apt-get update && \
+  apt-get install \
+  --assume-yes \
+  --no-install-recommends \
+  golang-go && \
+  go install \
+  github.com/stripe/pg-schema-diff/cmd/pg-schema-diff@${PG_SCHEMA_DIFF_VERSION} && \
+  cp /root/go/bin/pg-schema-diff /usr/local/bin/ && \
+  rm --recursive --force \
+  /root/go \
+  /root/.cache && \
+  apt-get purge \
+  --assume-yes \
+  golang-go && \
+  rm \
+  --recursive \
+  --force \
+  /var/lib/apt/lists/*
+
 ENV HOME=/home/me
 RUN mkdir --parents ${HOME}/app \
   && chown \

diff --git a/backend/Dockerfile.production b/backend/Dockerfile.production
@@ -1,4 +1,4 @@
-# syntax=docker/dockerfile:1.21
+# syntax=docker/dockerfile:1.23
 # check=error=true
 # Available versions are listed on https://hub.docker.com/r/docker/dockerfile
 

diff --git a/backend/Makefile b/backend/Makefile
@@ -7,7 +7,7 @@ MAKEFLAGS += --warn-undefined-variables
 
 # Taken from https://www.client9.com/self-documenting-makefiles/
 help : ## Print this help
-	@awk -F ':|##' '/^[^\t].+?:.*?##/ {\
+	@awk -F ':.*?## ' '/^[^\t].+?:.*?##/ {\
 		printf "\033[36m%-30s\033[0m %s\n", $$1, $$NF \
 	}' $(MAKEFILE_LIST)
 .PHONY : help
@@ -22,7 +22,7 @@ help : ## Print this help
 
 # See https://learn.microsoft.com/en-us/dotnet/core/testing/microsoft-testing-platform-run-and-debug?tabs=dotnetcli
 list : ARGS =
-list : ## List tests, for example, `make list-tests ARGS='--filter "FullyQualifiedName~LoggedInUser_CreatesComponent"'`
+list : ## List tests, for example, `make list ARGS='--filter "FullyQualifiedName~LoggedInUser_CreatesComponent"'`
 	dotnet run \
 		--project ./test/*.Tests.csproj \
 		--list-tests \
@@ -88,7 +88,7 @@ analyze : ## Analyze with Roslynator
 
 # https://www.jetbrains.com/help/resharper/ReSharper_Command_Line_Tools.html#install-and-use-resharper-command-line-tools-as-net-core-tools
 inspect : ## Inspect with ReSharper, for example, `make inspect OUTPUT=./inspection.xml`
-	dotnet tool run jb inspectcode --build ./*.sln -o ${OUTPUT}
+	dotnet tool run jb inspectcode --build --output "${OUTPUT}" ./*.sln
 .PHONY : inspect
 
 editorconfig : ## Debug editorconfig
@@ -171,13 +171,9 @@ dedup : ## Dedeuplicate code lines matching the pattern `${PATTERN}`, for exampl
 					}"
 .PHONY : dedup
 
-# See https://github.com/hasura/graphqurl#export-schema
-schema : ## Fetch GraphQL schema using `hasura/graphqurl`
-	gq \
-		http://backend:8080/graphql/ \
-		--introspect \
-		> ./schema.graphql
-.PHONY : schema
+check-database : ## Check whether there have been any model changes made since the last migration was added and whether the C# domain model matches the PostgreSQL database schema
+	$(MAKE) test ARGS='--filter "FullyQualifiedName~EnsureMigrationsAreUpToDate|FullyQualifiedName~EnsureDomainModelMatchesDatabaseSchema"'
+.PHONY : check-database
 
 has-pending-model-changes : ## Check whether there have been any model changes made since the last migration was added
 	dotnet ef \

diff --git a/backend/dotnet-tools.json b/backend/dotnet-tools.json
@@ -24,14 +24,14 @@
       "rollForward": false
     },
     "dotnet-ef": {
-      "version": "10.0.5",
+      "version": "10.0.9",
       "commands": [
         "dotnet-ef"
       ],
       "rollForward": false
     },
     "dotnet-script": {
-      "version": "2.0.0",
+      "version": "2.0.1",
       "commands": [
         "dotnet-script"
       ],
@@ -66,7 +66,7 @@
       "rollForward": false
     },
     "jetbrains.resharper.globaltools": {
-      "version": "2025.3.3",
+      "version": "2026.1.3",
       "commands": [
         "jb"
       ],
@@ -87,7 +87,7 @@
       "rollForward": false
     },
     "dotnet-outdated-tool": {
-      "version": "4.7.1",
+      "version": "4.8.1",
       "commands": [
         "dotnet-outdated"
       ],