From 12d5902e3c3ae2a899c21b861ed66e30e673c073 Mon Sep 17 00:00:00 2001 From: "matthias.lotz" Date: Sun, 7 Dec 2025 14:50:36 +0100 Subject: [PATCH] final feature request 1 --- .../open_workshop_feature_plan_full.md | 620 ++++++------------ 1 file changed, 211 insertions(+), 409 deletions(-) diff --git a/FEATURE_REQUEST/open_workshop_feature_plan_full.md b/FEATURE_REQUEST/open_workshop_feature_plan_full.md index 39cdd46..f486262 100644 --- a/FEATURE_REQUEST/open_workshop_feature_plan_full.md +++ b/FEATURE_REQUEST/open_workshop_feature_plan_full.md @@ -1,389 +1,170 @@ -# Open Workshop – Vollständiger FEATURE_PLAN -## Modularisierung + WordPress REST API Integration +# Open Workshop – FEATURE PLAN +## Vollständige Modularisierung + WordPress REST API Integration (API = Pflicht) -Dieses Dokument kombiniert **alle Inhalte beider vorherigen Dateien** zu einem einzigen vollständigen technischen Plan. -Es ist vollständig eigenständig und enthält sämtliche Anweisungen zur Odoo‑Modularisierung und zur Integration mit WordPress. +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: -Enthaltene Themen: -- Odoo‑Modulstruktur -- POS‑Auslagerung -- Maintenance‑Integration -- Public Website Modul -- API‑Modul für WordPress -- Architekturplan für externe Anbindung +# ⭐ 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. --- -# Open Workshop – FEATURE_PLAN (Implementation Roadmap) +# 1. Gesamtziel -## 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. +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 --- -# 1. Project Structure (Target Architecture) +# 2. Zielarchitektur Odoo-Module -The repository already contains: +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: - -``` -open_workshop_portal/ -open_workshop_inventory/ -open_workshop_training/ -open_workshop_api/ -open_workshop_reporting/ -``` - -Each future module must depend only on the minimal set of required layers. - ---- - -# 6. Summary - -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. - - - ---- - -# 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: +Pflicht: ``` GET /api/v1/machines GET /api/v1/machine/ -GET /api/v1/areas -GET /api/v1/files/ ``` -Output format: JSON +Empfohlen: -#### 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 +``` +GET /api/v1/areas +GET /api/v1/files/ +GET /api/v1/events (später für Kurse) +``` -#### 4. JSON Structure Example +## 7.3 JSON Beispiel ```json { @@ -391,96 +172,117 @@ Output format: JSON "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", + "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 + --- -# 3. WordPress Integration (External Website) +# 8. WordPress Integration (Pflicht, da Frontend) -## 3.1 WordPress fetches data from Odoo API -Recommended methods: +WordPress bleibt die öffentliche Website. -✔ WPCode plugin -✔ Custom WordPress plugin -✔ Shortcodes -✔ Server-side rendering via PHP -✔ Client-side rendering (JavaScript fetch) +## 8.1 Warum? -Example WordPress shortcode: +- 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] ``` -### 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 +# 9. Finaler Architektur-Plan ``` -open_workshop_portal/ -open_workshop_training/ -open_workshop_inventory/ -open_workshop_reporting/ + 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!** + --- -# 7. Summary +# 10. Sicherheit -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. +- 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.**