fix: remove API-facing frontend changes

Author: Ph4ntomic

README.md

@@ -101,7 +101,7 @@ Um Anfragen zu autorisieren, muss jeder Request einen gültigen CSRF-Token entha
 | `get_dashboard_stats` | Liefert aggregierte Daten (Bürger, Städte, Fahrzeuge, Energie). | - |
 | `get_active_vehicles_count` | Gibt die Anzahl der aktuell aktiven Fahrzeuge zurück. | - |
 | `get_citizens_count` | Gibt die Gesamtzahl der Bürger zurück. | - |
-| `get_sql_result` | Führt eine spezifische SQL-Datei aus `sql/queries/` aus. Die Abfragen sind nach `bp1/`, `bp2/`, `shared/` und `general/` gegliedert. | `file` (Dateipfad, z.B. `bp1/getRessourcesAtRisk.sql` oder `sql/queries/bp1/getRessourcesAtRisk.sql`) |
+| `get_sql_result` | Führt eine spezifische SQL-Datei nach bestehender API-Logik aus. | `file` (Dateiname, z.B. `getCitizensCount.sql`) |
 | `get_all_tables` | Gibt alle SQL-Abfrageergebnisse inkl. des SQL-Quellcodes zurück. | - |
 | `get_sql_files` | Listet den Inhalt aller verfügbaren SQL-Dateien auf. | - |
 

documentation/README.md

@@ -94,10 +94,10 @@ Generiert einen neuen CSRF-Token.
 ```
 
 #### 2. get_sql_result
-Führt eine spezifische SQL-Datei aus `sql/queries/` aus und gibt das Ergebnis zurück.
+Führt eine spezifische SQL-Datei nach bestehender API-Logik aus und gibt das Ergebnis zurück.
 
 **Parameter:**
-- `file`: SQL-Dateipfad, z.B. `general/getCitizensCount.sql`, `bp1/getRessourcesAtRisk.sql` oder `sql/queries/bp1/getRessourcesAtRisk.sql`
+- `file`: Dateiname der SQL-Datei, z.B. `getCitizensCount.sql`
 
 **Antwort:**
 ```json
@@ -106,7 +106,7 @@ Führt eine spezifische SQL-Datei aus `sql/queries/` aus und gibt das Ergebnis z
 }
 ```
 
-**Beispiel:** `/api/restApi.php?action=get_sql_result&csrf={token}&file=bp1/getRessourcesAtRisk.sql`
+**Beispiel:** `/api/restApi.php?action=get_sql_result&csrf={token}&file=getCitizensCount.sql`
 
 #### 3. get_active_vehicles_count
 Gibt die Anzahl aktiver Fahrzeuge zurück.

documentation/datenbankabfragen-v2.md

@@ -31,7 +31,7 @@ Für die Präsentation und weitere Dokumentation sollen deshalb nur die Abfragen
 
 ## 2. Relevante Abfragen nach Businessprozess
 
-Die normalen, direkt über die API ausführbaren SELECT-Abfragen liegen unter `sql/queries/`. Dort trennt die Ordnerstruktur zwischen `bp1/`, `bp2/`, `shared/` und `general/`. Die Stored-Procedure-Versionen liegen getrennt davon unter `sql/storedProcedure/` mit derselben fachlichen Gliederung. Dadurch bleibt klar erkennbar, welche Dateien Prozesslogik für BP1, Prozesslogik für BP2, gemeinsame Ressourcenlogik oder allgemeine WebApp-Abfragen enthalten.
+Die normalen SELECT-Abfragen liegen unter `sql/queries/`. Dort trennt die Ordnerstruktur zwischen `bp1/`, `bp2/`, `shared/` und `general/`. Die Stored-Procedure-Versionen liegen getrennt davon unter `sql/storedProcedure/` mit derselben fachlichen Gliederung. Dadurch bleibt klar erkennbar, welche Dateien Prozesslogik für BP1, Prozesslogik für BP2, gemeinsame Ressourcenlogik oder allgemeine WebApp-Abfragen enthalten.
 
 | Businessprozess | Relevante Abfragen / Tabellen | Zweck |
 |---|---|---|
@@ -42,7 +42,7 @@ Die normalen, direkt über die API ausführbaren SELECT-Abfragen liegen unter `s
 
 ## 3. Abfragen für Prozess 1
 
-Für Prozess 1 liegen die wichtigsten Abfragen zusätzlich als Stored Procedures im Ordner `sql/storedProcedure/bp1/` vor. Die gleichnamigen Dateien im Ordner `sql/queries/bp1/` bleiben als API-kompatible SELECT-Spiegel für die bestehende Web-App erhalten. Prozessübergreifende Ressourcenübersichten liegen in `sql/queries/shared/` und `sql/storedProcedure/shared/`. Damit passt die Datenbanklogik zum Feedback aus dem Projektproposal: Die Anwendung soll fachliche Datenbankfunktionen kontrolliert über Procedures nutzen, statt Prozesslogik frei in der Oberfläche zu verteilen.
+Für Prozess 1 liegen die wichtigsten Abfragen zusätzlich als Stored Procedures im Ordner `sql/storedProcedure/bp1/` vor. Die gleichnamigen Dateien im Ordner `sql/queries/bp1/` bleiben als SELECT-Spiegel für die fachliche Dokumentation und spätere Einbindung erhalten. Prozessübergreifende Ressourcenübersichten liegen in `sql/queries/shared/` und `sql/storedProcedure/shared/`. Damit passt die Datenbanklogik zum Feedback aus dem Projektproposal: Die Anwendung soll fachliche Datenbankfunktionen kontrolliert über Procedures nutzen, statt Prozesslogik frei in der Oberfläche zu verteilen.
 
 ### 3.1 `sql/queries/bp1/getRessourcesBelowMin.sql`
 
@@ -203,7 +203,7 @@ Diese Tabellen sind keine vollständige Abrechnungslösung. Sie dienen dazu, Üb
 
 ## 5. Abfragen für Prozess 2
 
-Für Prozess 2 liegen die wichtigsten Abfragen ebenfalls als Stored Procedures im Ordner `sql/storedProcedure/bp2/` vor. Die gleichnamigen Dateien im Ordner `sql/queries/bp2/` bleiben als API-kompatible SELECT-Spiegel für die bestehende Web-App erhalten.
+Für Prozess 2 liegen die wichtigsten Abfragen ebenfalls als Stored Procedures im Ordner `sql/storedProcedure/bp2/` vor. Die gleichnamigen Dateien im Ordner `sql/queries/bp2/` bleiben als SELECT-Spiegel für die fachliche Dokumentation und spätere Einbindung erhalten.
 
 ### 5.1 `sql/queries/bp2/getRessourcenUeberschuss.sql`
 

sql/sqlOverview.txt

@@ -2,7 +2,7 @@ SQL-Ordnerstruktur
 ==================
 
 sql/queries/
-Normale SELECT-Abfragen, die von der API ausgefuehrt werden koennen.
+Normale SELECT-Abfragen fuer fachliche Auswertungen.
 
 sql/queries/bp1/
 Abfragen fuer den Businessprozess "Kritische Ressourcen ueberwachen und Nachschub ausloesen".
@@ -73,6 +73,6 @@ Alte bzw. semesterbezogene Zusatznotizen.
 API-Hinweis
 ===========
 
-Die API liest normale Abfragen aus sql/queries/. Fuer get_sql_result koennen
-kurze Pfade wie bp1/getRessourcesAtRisk.sql oder physische Pfade wie
-sql/queries/bp1/getRessourcesAtRisk.sql verwendet werden.
+API-Routing und Prisma-Anbindung werden separat gepflegt. Diese SQL-Struktur
+beschreibt nur Ablage und fachliche Zuordnung der Dateien. Sie aendert keine
+restApi-Pfadlogik.

src/pages/Ressources.tsx

@@ -8,7 +8,7 @@ const Ressources = () => {
 
     useEffect(() => {
         if (tableContainerRef.current) {
-            const ressourceAtRiskTable = new TableRenderer('table-app-id', 'bp1/getRessourcesAtRisk.sql');
+            const ressourceAtRiskTable = new TableRenderer('table-app-id', 'getRessourcesAtRisk.sql');
             ressourceAtRiskTable.init();
         }
 
@@ -18,7 +18,7 @@ const Ressources = () => {
         }
 
         if (ressourcenTableContainerRef.current) {
-            const ressourcenTable = new TableRenderer('table-app-id-ressourcen', 'shared/getRessourcenWithLager.sql');
+            const ressourcenTable = new TableRenderer('table-app-id-ressourcen', 'getRessourcenWithLager.sql');
             ressourcenTable.init();
         }
     }, []);
@@ -108,4 +108,4 @@ const Ressources = () => {
     );
 };
 
-export default Ressources;
+export default Ressources;

src/utils/TableRenderer.ts

@@ -51,7 +51,7 @@ class TableRenderer {
     }
 
     private async apiFetchFileAsTable(endpoint: string): Promise<{ result: TableRow[] }> {
-        return apiFetch<{ result: TableRow[] }>(`get_sql_result&file=${encodeURIComponent(endpoint)}`);
+        return apiFetch<{ result: TableRow[] }>(`get_sql_result&file=${endpoint}`);
     }
 
     private async apiFetchAsTable(endpoint: string): Promise<{ result: TableRow[] }> {
@@ -104,4 +104,4 @@ class TableRenderer {
         return div.innerHTML;
     }
 }
-export default TableRenderer;
+export default TableRenderer;

src/utils/restApi.ts

@@ -71,5 +71,5 @@ export async function apiFetch<T>(endpoint: string): Promise<T> {
 }
 
 export async function apiFetchFile(endpoint: string) : Promise<string> {
-  return apiFetch<string>(`get_sql_result&file=${encodeURIComponent(endpoint)}`);
-}
+  return apiFetch<string>(`get_sql_result&file=${endpoint}`);
+}