diff --git a/FEATURE_REQUEST/open_workshop_feature_plan.md b/FEATURE_REQUEST/open_workshop_feature_plan.md index 17a12c5..6c08bb8 100644 --- a/FEATURE_REQUEST/open_workshop_feature_plan.md +++ b/FEATURE_REQUEST/open_workshop_feature_plan.md @@ -1,221 +1,355 @@ -# Open Workshop – FEATURE_PLAN (Implementation Roadmap) +# 0. Migration: open_workshop → open_workshop_base (Pflichtschritt) -## Purpose -This document describes **the full implementation plan** for restructuring the Open Workshop project into modular components and adding a **public website module** that displays machine information from the Odoo Maintenance module. -It is written so that a **technical AI agent** understands exactly what must be done, in which order, and in which module. -No source code is included. Only tasks, structure, and logic. +Dieser Schritt muss **vor allen anderen** durchgeführt werden, damit die neue Modulstruktur korrekt funktioniert. + +## 0.1 Ordner umbenennen + +``` +mv open_workshop open_workshop_base +``` + +## 0.2 Manifest-Datei anpassen (`__manifest__.py`) + +``` +'name': 'Open Workshop Base', +``` + +Alle Pfade von: + +``` +open_workshop/... +``` + +ändern zu: + +``` +open_workshop_base/... +``` + +## 0.3 Referenzen im Code ersetzen + +In **allen Dateien**: + +- `open_workshop.` → `open_workshop_base.` +- `/open_workshop/static/...` → `/open_workshop_base/static/...` + +## 0.4 Modul in Odoo aktualisieren + +``` +odoo -u open_workshop_base -d +``` + +Falls das alte Modul noch existiert: + +``` +odoo -u open_workshop_base -d --load=base +``` + +## 0.5 Datenbank prüfen + +``` +SELECT name FROM ir_module_module WHERE name LIKE 'open_workshop%'; +``` + +Falls `open_workshop` noch existiert: + +``` +DELETE FROM ir_module_module WHERE name = 'open_workshop'; +``` + +## 0.6 Wichtige Hinweise + +- Modellnamen wie `_name = 'ows.machine'` **bleiben unverändert** +- Tabellennamen ändern sich **nicht** +- Keine Datenmigration erforderlich --- -# 1. Project Structure (Target Architecture) +# Open Workshop – FEATURE PLAN +## Vollständige Modularisierung + WordPress REST API Integration (API = Pflicht) -The repository already contains: +Dieses Dokument ist die **finale, vollständig korrigierte Version** des Feature-Plans. +Es kombiniert alle Inhalte der vorherigen Dokumente, **konsolidiert, bereinigt und vereinheitlicht**, +und stellt klar: + +# ⭐ Die API ist ein **Pflichtbestandteil** der finalen Architektur. + +Das Dokument ist **eigenständig** und enthält alles, was ein Entwickler oder KI-Agent benötigt, +um das gesamte Open-Workshop-System korrekt modularisiert aufzubauen. + +--- + +# 1. Gesamtziel + +Das Projekt *Open Workshop* soll in eine moderne, klare und skalierbare Architektur überführt werden: + +- **Odoo (intern)** als Verwaltungs-Backend für Maschinen, Einweisungen, POS, Maintenance, Events. +- **WordPress (extern)** als öffentliche Website mit hoher Performance und SEO. +- **REST API (Pflicht!)** als Kommunikationsschicht zwischen beiden Systemen. + +Damit entsteht: + +``` +WordPress (öffentlich) + ↑ + | REST API (nur lesend) + ↓ +Odoo (intern, geschützt) +``` + +Diese Architektur vermeidet: + +- Performance-Probleme durch DSL-Uplink +- Sicherheitsrisiken von Odoo im Internet +- Hohe Kosten für Odoo.sh Benutzerlizenzen + +--- + +# 2. Zielarchitektur Odoo-Module + +Das Repository wird wie folgt strukturiert: ``` open_workshop/ -└── open_workshop/ +├── open_workshop_base/ # Pflicht – Backendmodelle & Logik +├── open_workshop_pos/ # POS-Funktionen (JS, XML, UI) +├── open_workshop_maintenance/ # Integration mit maintenance.equipment +├── open_workshop_api/ # PFLICHT – REST API für WordPress +└── open_workshop_website/ # OPTIONAL – interne Website in Odoo ``` -The following modules must be created and implemented: +Die API ist **nicht optional**, sobald WordPress als Frontend genutzt wird. -``` -open_workshop/ -├── open_workshop_base/ # Backend models, logic, security -├── open_workshop_pos/ # POS integration (JS, XML, POS logic) -├── open_workshop_maintenance/ # Bridge to maintenance.equipment -└── open_workshop_website/ # Public website + QR Code views +--- + +# 3. Modul: open_workshop_base (Pflicht) + +Enthält: + +- `ows.machine` (Maschinen) +- `ows.machine.area` (Bereiche) +- Einweisungslogik (Fähigkeiten, Freigaben) +- Beziehungen zu Produkten (Einweisungsprodukte) +- Sicherheitsregeln (ir.model.access) +- Backend-UI: Form, Tree, Kanban + +Nicht erlaubt: + +- POS-Code +- Website-Code +- API-Controller + +Es ist das Fundament des Systems. + +--- + +# 4. Modul: open_workshop_pos (Pflicht für POS-Nutzung) + +Auslagerung aller POS-relevanten Komponenten: + +### JS-Module: +- Sidebar +- Customer Widgets +- Machine Access Widgets +- Template Patches + +### XML: +- QWeb Templates für POS (Frontend) +- Stylesheets für POS + +### Assets: +```json +'point_of_sale.assets': [ + 'open_workshop_pos/static/src/...' +] ``` -Each module is independent and follows Odoo 18 best practices. +Dieses Modul muss **physisch getrennt** vom Base-Modul sein. --- -# 2. Implementation Roadmap (High-Level Tasks) -## 2.0 Rename Existing Module open_workshop to open_workshop_base -### Objective -Rename the existing `open_workshop` module to `open_workshop_base` to reflect its role as the core backend module. -### Required Actions -- Rename folder: open_workshop/ → open_workshop_base/ -- Update manifest file: - ``` - { - "name": "Open Workshop Base", - "depends": [...], - ... - } - ``` -- Update all internal references from `open_workshop.*` to `open_workshop_base.*` -- Ensure module loads without errors or warnings -- existing open_workshop module in database must be updated to reflect new name -- Test all existing functionality to ensure no regressions +# 5. Modul: open_workshop_maintenance (optional, aber empfohlen) +Ziele: -## 2.1 Extract POS Features into open_workshop_pos +- Maschinenmodelle mit Odoo Maintenance verbinden +- `maintenance.equipment` ↔ `ows.machine` +- Bedienungsanleitungen, Wartungsstatus +- Bilder und technische Parameter synchronisieren -### Objective -Move all POS functionality out of `open_workshop_base` into a new module `open_workshop_pos`. +Erlaubt: -### Required Actions -- Identify all POS-related files: - - JavaScript extensions for POS - - QWeb XML templates for POS screens - - Modifications to POS widgets or layouts - - POS asset definitions -- Create new module folder `open_workshop_pos` -- Move all POS frontend files into: - ``` - open_workshop_pos/static/src/js/ - open_workshop_pos/static/src/xml/ - ``` -- Update asset references: - - Ensure all JS and XML assets load under `point_of_sale.assets` -- Update internal module names: - - From `"open_workshop.*"` → `"open_workshop_pos.*"` -- Remove all POS-related code from `open_workshop_base` -- Ensure no dependency from `open_workshop_base` to POS exists -- Add dependency in `open_workshop_pos`: - ``` - depends = ["point_of_sale", "open_workshop_base"] - ``` +- Erweiterung bestehender Modelle +- Neue Views im Backend + +Verboten: + +- POS-/Website-/API-Code --- -## 2.2 Implement open_workshop_maintenance +# 6. Modul: open_workshop_website (optional) -### Objective -Connect `open_workshop_base` models with `maintenance.equipment` to centralize machine data management in the Odoo Maintenance module. +Nur nötig, wenn Odoo-intern eine Maschinenübersicht gewünscht ist. +Für WordPress ist dieses Modul **nicht erforderlich**. -### Required Actions -- Create new module folder `open_workshop_maintenance` -- Add dependency: - ``` - depends = ["maintenance", "open_workshop_base"] - ``` -- Extend `maintenance.equipment` with a Many2one to `ows.machine` -- Extend `ows.machine` with a Many2one to `maintenance.equipment` -- Add relevant fields: - - operating state - - instructions reference - - maintenance attributes -- Provide backend views to link Open Workshop machines with Maintenance equipment -- Ensure attachments (PDF manuals) are managed within Maintenance +Funktionen: + +- Odoo-Website-Routen (HTML) +- Öffentliche Maschinenliste (Odoo-Seite) +- QR-Code-Seiten + +Dieses Modul ist im finalen Setup **optional**, da WordPress das Frontend übernimmt. --- -## 2.3 Implement open_workshop_website +# 7. Modul: open_workshop_api (Pflichtmodul!) -### Objective -Create a **public-facing website module** to display machine status, manuals, images, and QR code access. +Dieses Modul stellt die **REST API** bereit, über die WordPress öffentlich verfügbare Daten abholt. -### Required Actions -- Create new module folder `open_workshop_website` -- Add dependency: - ``` - depends = ["website", "open_workshop_base", "open_workshop_maintenance"] - ``` -- Add public routes (auth="public"): - - `/workshop/machines` → list of all machines - - `/workshop/machine/` → detail view -- Implement public templates: - - List view - - Detail view (machine image, manual, status) -- Add PDF manual download handling -- Add QR code URL generator for each machine (no JS logic yet) -- Ensure only appropriate fields are publicly exposed -- Integrate optional “User has safety training” hint (read-only) +## 7.1 Ziele ---- +- Minimaler externer Zugriff (nur API-Endpunkte) +- JSON-Ausgabe für WordPress +- Keine Odoo-Website erforderlich +- Odoo selbst bleibt **nicht öffentlich erreichbar** -# 3. Cross‑Module Responsibilities +## 7.2 API-Endpunkte -## 3.1 open_workshop_base (Backend Core) -Contains: -- Data models: - - `ows.machine` - - `ows.machine.area` - - `ows.machine.access` -- Business logic -- Backend views -- Security rules -- Helper functions used by POS and website - -No POS or Website code is allowed here. - ---- - -## 3.2 open_workshop_pos (Frontend POS Layer) -Contains: -- All JavaScript logic for POS -- All POS XML templates -- POS-related model extensions -- POS-specific user interactions -- Logic for showing training/permissions in POS - -This module depends on `open_workshop_base`. - ---- - -## 3.3 open_workshop_maintenance (Maintenance Bridge) -Contains: -- Extensions to Maintenance models -- Attachments and instructions logic -- Unified equipment management -- Backend UI for linking machines to Maintenance equipment - -No Website or POS logic is allowed. - ---- - -## 3.4 open_workshop_website (Public Website) -Contains: -- Public machine directory -- Public machine detail pages -- PDF/manual access page -- QR code entry point -- Styling and templates - -It must never contain backend business logic. - ---- - -# 4. Final Deliverables (Expected Outputs) - -Once all tasks are completed, the repository must contain four fully independent but interoperable modules: - -### ✔ open_workshop_base -Backend data models + machine structure - -### ✔ open_workshop_pos -POS logic + UI - -### ✔ open_workshop_maintenance -Maintenance integration + machine data bridge - -### ✔ open_workshop_website -Public website for viewing machines + QR codes - -All modules must pass Odoo module validation and load without warnings. - ---- - -# 5. Future Expansion (Optional) - -The following modules can later be added if needed: +Pflicht: ``` -open_workshop_portal/ -open_workshop_inventory/ -open_workshop_training/ -open_workshop_api/ -open_workshop_reporting/ +GET /api/v1/machines +GET /api/v1/machine/ ``` -Each future module must depend only on the minimal set of required layers. +Empfohlen: + +``` +GET /api/v1/areas +GET /api/v1/files/ +GET /api/v1/events (später für Kurse) +``` + +## 7.3 JSON Beispiel + +```json +{ + "id": 12, + "name": "Formatkreissäge", + "status": "available", + "area": "Holzwerkstatt", + "image_url": "https://odoo.example.org/api/v1/file/29", + "manual_url": "https://odoo.example.org/api/v1/file/55", + "training_required": true +} +``` + +## 7.4 Sicherheitsmechanismen + +- CORS nur für WordPress-Domain erlauben +- Optionaler Token im Header (`Authorization: Bearer `) +- Kein Zugriff auf `/web`, `/api/web`, `/pos` +- Rate Limiting via Reverse Proxy --- -# 6. Summary +# 8. WordPress Integration (Pflicht, da Frontend) -This Feature Plan defines the **modularization**, **responsibility split**, and **implementation order** needed to transform the Open Workshop project into a professional, scalable Odoo subsystem. -It provides a clear roadmap for an AI agent or developer to follow without ambiguity. +WordPress bleibt die öffentliche Website. + +## 8.1 Warum? + +- Sehr hohe Performance (CDN, Caching) +- SEO-optimiert +- Keine Belastung deiner Internetleitung +- Keine Sicherheitsrisiken im internen Odoo +- Keine Lizenzkosten + +## 8.2 WordPress Plugin (bereitgestellt) + +Das Plugin: + +- Ruft Odoo-API ab +- Rendert Maschinenliste via Shortcode +- Konsumiert JSON-Daten +- Unterstützt Token-Auth + +Beispiel: + +``` +[openworkshop_machines] +``` + +--- + +# 9. Finaler Architektur-Plan + +``` + Internet + | + WordPress (Frontend, CDN) + | + fetch JSON via REST API + | + ---------------------------- + | API Gateway (open_workshop_api) + | Exposed only: /api/v1/* + ---------------------------- + | + Odoo Backend (LAN/VPN) + Maschinen, POS, Benutzer, Einweisungen +``` + +**Kein direkter Zugriff auf Odoo-Weboberfläche!** + +--- + +# 10. Sicherheit + +- Reverse Proxy (Traefik/Nginx) muss alle Odoo-Backoffice-URLS sperren +- Nur `/api/v1/*` darf öffentlich sein +- HTTPS erzwingen +- Rate-Limit + Firewall-Regeln +- Token-Authentifizierung optional zusätzlich einsetzbar + +--- + +# 11. Vorteile dieser Architektur + +## ✔ WordPress bleibt ultraschnell (1000 Besucher/Tag problemlos) +## ✔ Odoo bleibt sicher hinter Firewall +## ✔ Keine Benutzerkosten → alle Ehrenamtlichen können intern mitarbeiten +## ✔ Modular, wartbar, zukunftssicher +## ✔ API erlaubt feine Steuerung, welche Daten öffentlich sind +## ✔ Keine Last auf DSL-Leitung (WordPress hostet extern) + +--- + +# 12. Implementierungsreihenfolge (Pflicht) + +1. **open_workshop_base** erstellen und stabilisieren +2. **open_workshop_pos** extrahieren +3. **open_workshop_maintenance** hinzufügen +4. **open_workshop_api** implementieren (**Pflicht!**) +5. WordPress-Plugin konfigurieren +6. API testen +7. WordPress-Frontend aufbauen + +--- + +# 13. Endfazit + +Diese finale Architektur ist: + +- technisch korrekt +- performant +- sicher +- kostenoptimiert +- langfristig erweiterbar +- perfekt für ein FabLab wie den HobbyHimmel + +Die API ist **zentrales und unverzichtbares Modul** dieser Struktur. + +**Dieses Dokument ist vollständig und benötigt keine externen Verweise.** diff --git a/FEATURE_REQUEST/open_workshop_feature_plan_full.md b/FEATURE_REQUEST/open_workshop_feature_plan_full.md deleted file mode 100644 index 6c08bb8..0000000 --- a/FEATURE_REQUEST/open_workshop_feature_plan_full.md +++ /dev/null @@ -1,355 +0,0 @@ -# 0. Migration: open_workshop → open_workshop_base (Pflichtschritt) - -Dieser Schritt muss **vor allen anderen** durchgeführt werden, damit die neue Modulstruktur korrekt funktioniert. - -## 0.1 Ordner umbenennen - -``` -mv open_workshop open_workshop_base -``` - -## 0.2 Manifest-Datei anpassen (`__manifest__.py`) - -``` -'name': 'Open Workshop Base', -``` - -Alle Pfade von: - -``` -open_workshop/... -``` - -ändern zu: - -``` -open_workshop_base/... -``` - -## 0.3 Referenzen im Code ersetzen - -In **allen Dateien**: - -- `open_workshop.` → `open_workshop_base.` -- `/open_workshop/static/...` → `/open_workshop_base/static/...` - -## 0.4 Modul in Odoo aktualisieren - -``` -odoo -u open_workshop_base -d -``` - -Falls das alte Modul noch existiert: - -``` -odoo -u open_workshop_base -d --load=base -``` - -## 0.5 Datenbank prüfen - -``` -SELECT name FROM ir_module_module WHERE name LIKE 'open_workshop%'; -``` - -Falls `open_workshop` noch existiert: - -``` -DELETE FROM ir_module_module WHERE name = 'open_workshop'; -``` - -## 0.6 Wichtige Hinweise - -- Modellnamen wie `_name = 'ows.machine'` **bleiben unverändert** -- Tabellennamen ändern sich **nicht** -- Keine Datenmigration erforderlich - ---- - -# Open Workshop – FEATURE PLAN -## Vollständige Modularisierung + WordPress REST API Integration (API = Pflicht) - -Dieses Dokument ist die **finale, vollständig korrigierte Version** des Feature-Plans. -Es kombiniert alle Inhalte der vorherigen Dokumente, **konsolidiert, bereinigt und vereinheitlicht**, -und stellt klar: - -# ⭐ Die API ist ein **Pflichtbestandteil** der finalen Architektur. - -Das Dokument ist **eigenständig** und enthält alles, was ein Entwickler oder KI-Agent benötigt, -um das gesamte Open-Workshop-System korrekt modularisiert aufzubauen. - ---- - -# 1. Gesamtziel - -Das Projekt *Open Workshop* soll in eine moderne, klare und skalierbare Architektur überführt werden: - -- **Odoo (intern)** als Verwaltungs-Backend für Maschinen, Einweisungen, POS, Maintenance, Events. -- **WordPress (extern)** als öffentliche Website mit hoher Performance und SEO. -- **REST API (Pflicht!)** als Kommunikationsschicht zwischen beiden Systemen. - -Damit entsteht: - -``` -WordPress (öffentlich) - ↑ - | REST API (nur lesend) - ↓ -Odoo (intern, geschützt) -``` - -Diese Architektur vermeidet: - -- Performance-Probleme durch DSL-Uplink -- Sicherheitsrisiken von Odoo im Internet -- Hohe Kosten für Odoo.sh Benutzerlizenzen - ---- - -# 2. Zielarchitektur Odoo-Module - -Das Repository wird wie folgt strukturiert: - -``` -open_workshop/ -├── open_workshop_base/ # Pflicht – Backendmodelle & Logik -├── open_workshop_pos/ # POS-Funktionen (JS, XML, UI) -├── open_workshop_maintenance/ # Integration mit maintenance.equipment -├── open_workshop_api/ # PFLICHT – REST API für WordPress -└── open_workshop_website/ # OPTIONAL – interne Website in Odoo -``` - -Die API ist **nicht optional**, sobald WordPress als Frontend genutzt wird. - ---- - -# 3. Modul: open_workshop_base (Pflicht) - -Enthält: - -- `ows.machine` (Maschinen) -- `ows.machine.area` (Bereiche) -- Einweisungslogik (Fähigkeiten, Freigaben) -- Beziehungen zu Produkten (Einweisungsprodukte) -- Sicherheitsregeln (ir.model.access) -- Backend-UI: Form, Tree, Kanban - -Nicht erlaubt: - -- POS-Code -- Website-Code -- API-Controller - -Es ist das Fundament des Systems. - ---- - -# 4. Modul: open_workshop_pos (Pflicht für POS-Nutzung) - -Auslagerung aller POS-relevanten Komponenten: - -### JS-Module: -- Sidebar -- Customer Widgets -- Machine Access Widgets -- Template Patches - -### XML: -- QWeb Templates für POS (Frontend) -- Stylesheets für POS - -### Assets: -```json -'point_of_sale.assets': [ - 'open_workshop_pos/static/src/...' -] -``` - -Dieses Modul muss **physisch getrennt** vom Base-Modul sein. - ---- - -# 5. Modul: open_workshop_maintenance (optional, aber empfohlen) - -Ziele: - -- Maschinenmodelle mit Odoo Maintenance verbinden -- `maintenance.equipment` ↔ `ows.machine` -- Bedienungsanleitungen, Wartungsstatus -- Bilder und technische Parameter synchronisieren - -Erlaubt: - -- Erweiterung bestehender Modelle -- Neue Views im Backend - -Verboten: - -- POS-/Website-/API-Code - ---- - -# 6. Modul: open_workshop_website (optional) - -Nur nötig, wenn Odoo-intern eine Maschinenübersicht gewünscht ist. -Für WordPress ist dieses Modul **nicht erforderlich**. - -Funktionen: - -- Odoo-Website-Routen (HTML) -- Öffentliche Maschinenliste (Odoo-Seite) -- QR-Code-Seiten - -Dieses Modul ist im finalen Setup **optional**, da WordPress das Frontend übernimmt. - ---- - -# 7. Modul: open_workshop_api (Pflichtmodul!) - -Dieses Modul stellt die **REST API** bereit, über die WordPress öffentlich verfügbare Daten abholt. - -## 7.1 Ziele - -- Minimaler externer Zugriff (nur API-Endpunkte) -- JSON-Ausgabe für WordPress -- Keine Odoo-Website erforderlich -- Odoo selbst bleibt **nicht öffentlich erreichbar** - -## 7.2 API-Endpunkte - -Pflicht: - -``` -GET /api/v1/machines -GET /api/v1/machine/ -``` - -Empfohlen: - -``` -GET /api/v1/areas -GET /api/v1/files/ -GET /api/v1/events (später für Kurse) -``` - -## 7.3 JSON Beispiel - -```json -{ - "id": 12, - "name": "Formatkreissäge", - "status": "available", - "area": "Holzwerkstatt", - "image_url": "https://odoo.example.org/api/v1/file/29", - "manual_url": "https://odoo.example.org/api/v1/file/55", - "training_required": true -} -``` - -## 7.4 Sicherheitsmechanismen - -- CORS nur für WordPress-Domain erlauben -- Optionaler Token im Header (`Authorization: Bearer `) -- Kein Zugriff auf `/web`, `/api/web`, `/pos` -- Rate Limiting via Reverse Proxy - ---- - -# 8. WordPress Integration (Pflicht, da Frontend) - -WordPress bleibt die öffentliche Website. - -## 8.1 Warum? - -- Sehr hohe Performance (CDN, Caching) -- SEO-optimiert -- Keine Belastung deiner Internetleitung -- Keine Sicherheitsrisiken im internen Odoo -- Keine Lizenzkosten - -## 8.2 WordPress Plugin (bereitgestellt) - -Das Plugin: - -- Ruft Odoo-API ab -- Rendert Maschinenliste via Shortcode -- Konsumiert JSON-Daten -- Unterstützt Token-Auth - -Beispiel: - -``` -[openworkshop_machines] -``` - ---- - -# 9. Finaler Architektur-Plan - -``` - Internet - | - WordPress (Frontend, CDN) - | - fetch JSON via REST API - | - ---------------------------- - | API Gateway (open_workshop_api) - | Exposed only: /api/v1/* - ---------------------------- - | - Odoo Backend (LAN/VPN) - Maschinen, POS, Benutzer, Einweisungen -``` - -**Kein direkter Zugriff auf Odoo-Weboberfläche!** - ---- - -# 10. Sicherheit - -- Reverse Proxy (Traefik/Nginx) muss alle Odoo-Backoffice-URLS sperren -- Nur `/api/v1/*` darf öffentlich sein -- HTTPS erzwingen -- Rate-Limit + Firewall-Regeln -- Token-Authentifizierung optional zusätzlich einsetzbar - ---- - -# 11. Vorteile dieser Architektur - -## ✔ WordPress bleibt ultraschnell (1000 Besucher/Tag problemlos) -## ✔ Odoo bleibt sicher hinter Firewall -## ✔ Keine Benutzerkosten → alle Ehrenamtlichen können intern mitarbeiten -## ✔ Modular, wartbar, zukunftssicher -## ✔ API erlaubt feine Steuerung, welche Daten öffentlich sind -## ✔ Keine Last auf DSL-Leitung (WordPress hostet extern) - ---- - -# 12. Implementierungsreihenfolge (Pflicht) - -1. **open_workshop_base** erstellen und stabilisieren -2. **open_workshop_pos** extrahieren -3. **open_workshop_maintenance** hinzufügen -4. **open_workshop_api** implementieren (**Pflicht!**) -5. WordPress-Plugin konfigurieren -6. API testen -7. WordPress-Frontend aufbauen - ---- - -# 13. Endfazit - -Diese finale Architektur ist: - -- technisch korrekt -- performant -- sicher -- kostenoptimiert -- langfristig erweiterbar -- perfekt für ein FabLab wie den HobbyHimmel - -Die API ist **zentrales und unverzichtbares Modul** dieser Struktur. - -**Dieses Dokument ist vollständig und benötigt keine externen Verweise.** - diff --git a/FEATURE_REQUEST/open_workshop_feature_plan_wp_api.md b/FEATURE_REQUEST/open_workshop_feature_plan_wp_api.md deleted file mode 100644 index 43f34d2..0000000 --- a/FEATURE_REQUEST/open_workshop_feature_plan_wp_api.md +++ /dev/null @@ -1,245 +0,0 @@ -# Open Workshop – FEATURE_PLAN (Updated for WordPress + Odoo API Integration) -*Updated to include Option 1: **WordPress ↔ Odoo REST/JSONRPC API integration*** - - ---- - -# 0. Purpose -This updated plan describes: - -- the modularization of the **Open Workshop** Odoo project, -- **AND** the integration of an external **WordPress** website via REST/JSONRPC API, -- providing a fully decoupled, secure, scalable architecture. - -It is written so that a **technical AI agent** can implement it step‑by‑step. - ---- - -# 1. Target Architecture Overview - -Your repository will contain these Odoo modules: - -``` -open_workshop/ -├── open_workshop_base/ # Backend models, logic, security -├── open_workshop_pos/ # POS integration (JS, XML, POS logic) -├── open_workshop_maintenance/ # Bridge to maintenance.equipment -├── open_workshop_website/ # Optional: internal Odoo website (not needed for WP) -└── open_workshop_api/ # NEW: REST/JSONRPC API interface for WordPress -``` - -Additionally: - -``` -WordPress Website (External Hosting) - ↑ - | REST / JSONRPC - | -Odoo API Gateway (open_workshop_api) -``` - ---- - -# 2. Implementation Roadmap (High-Level Tasks) -## 2.0 Rename Existing Module open_workshop to open_workshop_base -### Objective -Rename the existing `open_workshop` module to `open_workshop_base` to reflect its role as the core backend module. -### Required Actions -- Rename folder: open_workshop/ → open_workshop_base/ -- Update manifest file: - ``` - { - "name": "Open Workshop Base", - "depends": [...], - ... - } - ``` -- Update all internal references from `open_workshop.*` to `open_workshop_base.*` -- Ensure module loads without errors or warnings -- existing open_workshop module in database must be updated to reflect new name -- Test all existing functionality to ensure no regressions - -## 2.1 Create open_workshop_base (Core Module) -Keep the original `open_workshop` functionality here: - -- machine models (`ows.machine`) -- machine areas -- machine access control -- backend views -- core logic -- security - -No POS or website logic allowed. - ---- - -## 2.2 Extract POS Features into open_workshop_pos -(As in the original plan) - -### Goals: -- all POS JS -- all POS XML templates -- all assets under `point_of_sale.assets` -- no dependency loops - ---- - -## 2.3 Implement open_workshop_maintenance -(As in the original plan) - -### Goals: -- sync Odoo Maintenance module with machines -- attachments (manuals) -- maintenance state -- equipment mapping - ---- - -## 2.4 Implement open_workshop_api (NEW – Based on Option 1: WordPress as frontend) -This is the most important new component. - -### Objective -Expose selected Open Workshop machine data to WordPress via: - -✔ REST -✔ JSONRPC -✔ public or token-authenticated routes -✔ CORS-enabled responses - -WordPress then renders the machine pages externally. - -### Required Actions - -#### 1. Create Module Structure -``` -open_workshop_api/ -├── controllers/ -│ └── api.py -├── __init__.py -├── __manifest__.py -└── security/ - └── ir.model.access.csv -``` - -#### 2. Implement REST API Routes -Example endpoints: - -``` -GET /api/v1/machines -GET /api/v1/machine/ -GET /api/v1/areas -GET /api/v1/files/ -``` - -Output format: JSON - -#### 3. API Features -- Pagination support -- Public OR token-based access -- CORS headers for WordPress domain -- Filter machines by area/status -- Provide URLs to documents and images -- Provide “training required” and “has training?” status -- Provide QR-friendly endpoints for mobile devices - -#### 4. JSON Structure Example - -```json -{ - "id": 12, - "name": "Formatkreissäge", - "status": "available", - "area": "Holzwerkstatt", - "image_url": "https://odoo.example.de/api/v1/file/29", - "manual_url": "https://odoo.example.de/api/v1/file/55", - "training_required": true -} -``` - ---- - -# 3. WordPress Integration (External Website) - -## 3.1 WordPress fetches data from Odoo API -Recommended methods: - -✔ WPCode plugin -✔ Custom WordPress plugin -✔ Shortcodes -✔ Server-side rendering via PHP -✔ Client-side rendering (JavaScript fetch) - -Example WordPress shortcode: - -``` -[openworkshop_machines] -``` - -### WordPress responsibilities: -- Machine listing -- Machine detail page -- Styling, responsive layout -- Optional: caching of API responses -- Embedding QR codes from Odoo API - ---- - -# 4. Cross‑Module Responsibilities - -## 4.1 open_workshop_base -- Machine models -- Machine area models -- Machine access management -- Internal logic - -## 4.2 open_workshop_pos -- POS-specific UI -- POS logic -- POS assets - -## 4.3 open_workshop_maintenance -- Synchronization with maintenance.equipment -- Manual attachments - -## 4.4 open_workshop_api -- Public API -- REST/JSONRPC -- Data serialization -- Security + CORS -- No views, no UI - -## 4.5 open_workshop_website (optional) -Only needed if you want internal Odoo-rendered pages. -Not required for WordPress integration. - ---- - -# 5. Final Deliverables - -After implementation, you will have: - -### ✔ Fully modularized Odoo backend -### ✔ A secure Odoo REST API -### ✔ WordPress as external frontend -### ✔ No dependency on Odoo Website Builder -### ✔ Clean separation of internal (POS, maintenance) and external (public WP site) - ---- - -# 6. Future Expansion - -``` -open_workshop_portal/ -open_workshop_training/ -open_workshop_inventory/ -open_workshop_reporting/ -``` - ---- - -# 7. Summary - -This updated Feature Plan integrates the **Odoo backend** with a **WordPress public website** using a dedicated REST API module `open_workshop_api`. -The architecture is scalable, secure, and avoids exposing Odoo’s website builder publicly. -All modules remain cleanly separated and maintainable. -