IT-Naturschutz/konova
7
1
Fork 0
Code Issues 6 Pull Requests 1 Actions Projects Releases 28 Wiki Activity
Page: technical documentation_de
Pages
EGON Home Home_en api v1 compensation delete_de api v1 compensation get_de api v1 compensation json properties de api v1 compensation post_de api v1 compensation put_de api v1 deduction delete_de api v1 deduction get_de api v1 deduction json properties de api v1 deduction post_de api v1 deduction put_de api v1 ecoaccount delete_de api v1 ecoaccount get_de api v1 ecoaccount json properties de api v1 ecoaccount post_de api v1 ecoaccount put_de api v1 ema delete_de api v1 ema get_de api v1 ema json properties de api v1 ema post_de api v1 ema put_de api v1 intervention check_de api v1 intervention delete_de api v1 intervention get_de api v1 intervention json properties de api v1 intervention post_de api v1 intervention put_de api v1 share get_de api v1 share put_de api_de custom commands features features_de features_en generate_report_de konova codes recalculate_parcels_de technical documentation technical documentation_de
5 technical documentation_de
mpeltriaux edited this page 2024-10-25 16:26:09 +02:00
Table of Contents

Abhängigkeiten

Folgende Voraussetzungen sind für den Betrieb der Anwendung sicherzustellen:

  • Postgresql und initiales Setup
    • Ein postgresql Server bzw. lokaler Dienst muss verfügbar sein (nicht Bestandteil der Applikation)
    • Die in den Einstellungen hinterlegte Datenbank muss angelegt sein (Django Migrationen erzeugen keine neuen Datenbanken)
    • Änderungen an den Tabellen und Modellen dürfen ausschließlich über Django Migrationen vorgenommen werden (python manage.py makemigrations + python manage.py migrate)
    • Das initiale Setup Kommando muss vor der ersten Benutzung ausgeführt werden (python manage.py setup)
  • Python >3.10
    • Konova basiert auf Django in seiner (möglichst) aktuellen Version (derzeit Django 5.x)
    • Aus diesem Grund wird Python >3.10 empfohlen (vgl. jeweils aktuelles Dockerfile)
  • pip
    • Alle Paketabhängigkeiten der requirements.txt müssen mit pip installiert sein (pip install -r requirements.txt)
  • Redis und celery
    • konova verwendet Subprozesse, um zeit- und rechenintensive Arbeiten in den Hintergrund zu verlagern. Diese tasks werden in einer lokalen redis Datenbank abgelegt, aus welcher die Subprozesse diese entnehmen und abarbeiten. Daher ist eine lokale redis Serverinstanz notwendig. Diese wird im Docker Container mitinstalliert.
    • Die Brokerkonfiguration in celery.py muss auf diese redis Instanz verweisen (normalerweise Default Einstellung ausreichend)
    • Subprozesse müssen gestartet werden (celery -A konova worker -l INFO). Wird bei der Ausführung des Docker Containers automatisch gestartet
      • Weitere Informationen zu celery finden sich hier
  • Codelisten
    • Alle in konova verwendeten auswählbaren Codes (Biotope, Behörden, ...) werden von der öffentlichen Codelisten API des Naturschutzes entnommen (bspw. https://codelisten.naturschutz.rlp.de/repository/referenzliste/903)
    • Codes werden durch das entsprechende Kommando aktualisiert (python manage.py update_codelist)
      • Diese Aktualisierung sollte regelmäßig, z.B. mittels cron, durchgeführt werden
  • Flurstücksverschneidung
    • Einträge mit vorhandener Geometrie werden mit amtlichen Flurstücken verschnitten, um die überlagerten Flurstücke zu ermitteln
    • Die Webanwendung schneider bietet eine entsprechende Schnittstelle zur Verschneidung von Geometrien
      • Mehr Infos zu schneider finden sich hier
  • E-Mail Versand

API

Eine Spezifikation zur API des KSP kann hier gefunden werden.

Neuigkeiten (ServerMessages)

Neuigkeiten können zur Startseite des KSP hinzugefügt werden, sodass sie von jedem Nutzer wahrgenommen werden können. Diese Nachricht werden über das DjangoModel ServerMessages realisiert und können im django admin backend angelegt, bearbeitet oder gelöscht werden. Folgende Attribute stellen das Verhalten einer ServerMessage ein:

  • is_active
    • De-/Aktiviert die Sichtbarkeit der Nachricht (False = Nachricht wird grundsätzlich nicht angezeigt; alternative zum Löschen des Eintrags, bspw. um Korrekturen vorzunehmen, bevor wieder aktiviert wird)
  • publish_on
    • Der Zeitstempel ab wann die Nachricht angezeigt werden soll (z.B. zu einem fixen Termin in der Zukunft)
  • unpublish_on (optional)
    • Der Zeitstempel ab wann die Nachricht nicht länger angezeigt werden soll
    • Falls kein Enddatum angegeben ist, wird die Nachricht dauerhaft sichtbar sein
  • importance
    • Entscheidet über das genutzte Farbschema der Nachricht
      • standard --> Normal, kein besonderes Styling
      • info --> Infomeldung, leichtes Blau
      • warning --> Warnung, leichtes Rot

Gelöschte Einträge wiederherstellen

Alle Hauptdatentypen (EIV, KOM, EMA, OEK) können durch einen Administrator wiederhergestellt werden, wenn sie durch einen Nutzer gelöscht worden sind. Wenn ein Nutzer einen Eintrag löscht, wird dieser lediglich als gelöscht markiert und ist somit nicht mehr für den Nutzer zugänglich.

Solche "gelöschten" Einträge können über das django admin backend wiederhergestellt werden:

  1. Datensatz per checkbox markieren
  2. Aus Aktionsliste Restore deleted data auswählen
  3. Aktion ausführen

Fehler

Falls Fehler (z.B. Bugs o.ä.) auf dem deployten System auftreten (und damit bspw. einen Server error 500 auslösen), wird eine Mail an die ADMINS verschickt, welche detaillierte Infos über die Ursache, den Zeitpunkt, den ausführenden Nutzer, usw. enthält. Mehr Infos dazu finden sich hier.

Custom commands

Konova bietet Kommandos, die direkt von der Kommandozeile aus aufgerufen werden und dem Konzept der Django Custom Commands folgen. Die Kommandos werden wie alle Django Kommandos mit

python manage.py [COMMAND] [ATTR1] [ATTR2] ...

aufgerufen. Die COMMANDs sind: