removed unused files
This commit is contained in:
parent
bf605539fa
commit
bb3d1bf7c9
|
|
@ -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 <dbname>
|
||||
```
|
||||
|
||||
Falls das alte Modul noch existiert:
|
||||
|
||||
```
|
||||
odoo -u open_workshop_base -d <dbname> --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/<id>` → 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/<id>
|
||||
```
|
||||
|
||||
Each future module must depend only on the minimal set of required layers.
|
||||
Empfohlen:
|
||||
|
||||
```
|
||||
GET /api/v1/areas
|
||||
GET /api/v1/files/<attachment_id>
|
||||
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 <token>`)
|
||||
- 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.**
|
||||
|
||||
|
|
|
|||
|
|
@ -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 <dbname>
|
||||
```
|
||||
|
||||
Falls das alte Modul noch existiert:
|
||||
|
||||
```
|
||||
odoo -u open_workshop_base -d <dbname> --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/<id>
|
||||
```
|
||||
|
||||
Empfohlen:
|
||||
|
||||
```
|
||||
GET /api/v1/areas
|
||||
GET /api/v1/files/<attachment_id>
|
||||
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 <token>`)
|
||||
- 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.**
|
||||
|
||||
|
|
@ -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/<id>
|
||||
GET /api/v1/areas
|
||||
GET /api/v1/files/<attachment_id>
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user