final feature request

This commit is contained in:
Matthias Lotz 2025-12-07 14:46:09 +01:00
parent 58c7e8f258
commit 977aa2d1b3
5 changed files with 1012 additions and 1 deletions

View File

@ -0,0 +1,178 @@
# Odoo vs WordPress vs Odoo.sh Architektur- & Strategie-Empfehlung
*Für HobbyHimmel / FabLab Traffic: ~1000 Besucher, 2000 Views pro Tag*
---
# 🚀 Zusammenfassung (TL;DR)
| Bereich | Empfehlung |
|--------|------------|
| Öffentliche Website | **WordPress behalten** |
| Odoo als öffentliche Website | **Nicht geeignet** (Performance + Security) |
| Odoo.sh | **Nicht geeignet** (Benutzerkosten, Einschränkungen) |
| Odoo self-hosted | **Optimal für interne Prozesse** |
| Integration | **WordPress ↔ Odoo via REST API** |
| Zielarchitektur | **WP Frontend + Odoo Backend** |
---
# 1. Zielsetzung
HobbyHimmel benötigt:
- Eine öffentliche Website (ca. 1000 Besucher / 2000 Views täglich)
- Interne Verwaltungsprozesse (Maschinen, Einweisungen, Kurse, POS)
- Möglichkeit, ausgewählte Daten (Maschinenstatus, Kurstermine…) öffentlich darzustellen
- Möglichst geringe Kosten
- Hohe Sicherheit (keine offene interne Datenbank)
---
# 2. Analyse der drei Optionen
## 2.1 WordPress (beste Lösung für öffentliche Webseite)
**Stärken:**
- Sehr schneller Seitenaufbau, Caching, CDN
- Perfekt für hohe Besucherzahlen
- Themes, SEO, Plug-ins
- Komplett getrennt vom internen FabLab-System
**Schwächen:**
- Kein direkter Zugriff auf Odoo-Daten (muss über API geschehen)
**Fazit:**
⭐⭐⭐⭐⭐ **Beste Lösung für alle öffentlichen Besucher.**
---
## 2.2 Odoo (self-hosted, intern)
**Stärken:**
- Ideal für Maschinenverwaltung, POS, Maintenance, Events
- Volle Freiheit, beliebige Module zu installieren
- Keine Lizenzkosten für Ehrenamtliche, solange sie keinen Login benötigen
- Perfekt für interne Daten & Prozesse
**Schwächen:**
- Als öffentliche Website ungeeignet (Performance, kein CDN)
- DSL-Upload wäre Flaschenhals
**Fazit:**
⭐⭐⭐⭐⭐ **Beste Lösung für interne Prozesse.
Nicht geeignet als öffentliche Website.**
---
## 2.3 Odoo.sh
**Vorteile:**
- Kein DSL-Problem
- Hosting, Deployment & Backups werden automatisiert
**ABER:**
- **sehr hohe Kosten** bei >10 Ehrenamtlichen (pro Benutzer Lizenzpflicht)
- **stark eingeschränkt** bei Custom-Code, Addons, APIs
- Performance besser, aber **immer noch weit unter WordPress**
- Website-Teil ist **nicht auf hohen Traffic optimiert**
**Fazit:**
⭐⭐ **Für HobbyHimmel ungeeignet.**
Zu teuer, zu eingeschränkt, keine Website-Performance wie WP.
---
# 3. Performance-Bewertung
| System | Performance für 1000 Besucher/Tag |
|--------|-----------------------------------|
| WordPress (mit CDN) | ⭐⭐⭐⭐⭐ |
| Odoo.sh Website | ⭐⭐ |
| Odoo self-hosted Website über DSL | ⭐ (Upload-Limit!) |
WordPress ist **um Größenordnungen** besser für Public Traffic.
---
# 4. Sicherheitsbewertung
| System | Risiko bei Public Exposure |
|--------|----------------------------|
| WordPress | gering (gefiltert, gehärtet, cached) |
| Odoo Website | hoch (direkter Zugriff auf Business-Daten) |
| Odoo API | gering (nur ausgewählte Daten, stark begrenzt) |
Odoo sollte **nicht** öffentlich zugänglich sein, außer über **stark eingeschränkte REST API**.
---
# 5. Kostenbewertung
| Option | Monatliche Kosten | Skalierbarkeit |
|--------|-------------------|----------------|
| WordPress gehostet | 520 € | sehr gut |
| Odoo self-hosted | ~020 € | sehr gut |
| **Odoo.sh** | **ab ~40 € pro Benutzer** | schlecht bei vielen Ehrenamtlichen |
**Odoo.sh wäre ruinös teuer für ein FabLab.**
---
# 6. Empfohlene Zielarchitektur
```
Internet
|
| 1000 Besucher/Tag
v
WordPress Website (öffentlich)
|
| REST-API (lesend!)
v
Odoo API Gateway (open_workshop_api)
|
| internal-only
v
Odoo Backend (POS, Maintenance, Trainings, Events)
```
**Vorteile:**
- Odoo bleibt geschützt im LAN oder VPN
- Kein DSL-Upload-Limit problematisch → API ist sehr leichtgewichtig
- WordPress ist ultraschnell & SEO-stark
- Odoo liefert Daten dynamisch an WP (z.B. Maschinenliste, Kurse)
- Keine Benutzerkosten für Ehrenamtliche
---
# 7. Fazit
Die beste Lösung für HobbyHimmel besteht aus einer Kombination:
# 🟩 **WordPress für öffentliche Website**
# 🟩 **Odoo (self-hosted) für Verwaltung & Prozesse**
# 🟩 **API-Modul für WordPress-Anbindung**
# 🟥 **Keine Odoo Website für Öffentlichkeit**
# 🟥 **Kein Odoo.sh wegen hoher Lizenzkosten**
Diese Architektur ist:
- Sicher
- Schnell
- Zukunftssicher
- Kosteneffizient
- Flexibel
- Perfekt für ein FabLab mit vielen Ehrenamtlichen
---
# 8. Nächste Schritte
Wenn gewünscht, kann ich liefern:
### ✔ Architekturdiagramm (grafisch)
### ✔ open_workshop_api Modul als Odoo-Modul-Skeleton
### ✔ WordPress-Shortcodes oder Plugin
### ✔ Sicherheitsempfehlungen (CORS, Token, Firewalls)
### ✔ Optimierungskonzept für den späteren Betrieb

View File

@ -0,0 +1,486 @@
# Open Workshop Vollständiger FEATURE_PLAN
## Modularisierung + WordPress REST API Integration
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 OdooModularisierung und zur Integration mit WordPress.
Enthaltene Themen:
- OdooModulstruktur
- POSAuslagerung
- MaintenanceIntegration
- Public Website Modul
- APIModul für WordPress
- Architekturplan für externe Anbindung
---
# Open Workshop FEATURE_PLAN (Implementation Roadmap)
## 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.
---
# 1. Project Structure (Target Architecture)
The repository already contains:
```
open_workshop/
└── open_workshop/
```
The following modules must be created and implemented:
```
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
```
Each module is independent and follows Odoo 18 best practices.
---
# 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 Extract POS Features into open_workshop_pos
### Objective
Move all POS functionality out of `open_workshop_base` into a new module `open_workshop_pos`.
### 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"]
```
---
## 2.2 Implement open_workshop_maintenance
### Objective
Connect `open_workshop_base` models with `maintenance.equipment` to centralize machine data management in the Odoo Maintenance module.
### 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
---
## 2.3 Implement open_workshop_website
### Objective
Create a **public-facing website module** to display machine status, manuals, images, and QR code access.
### 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)
---
# 3. CrossModule Responsibilities
## 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 stepbystep.
---
# 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. CrossModule 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 Odoos website builder publicly.
All modules remain cleanly separated and maintainable.

View File

@ -1,6 +1,6 @@
# Open Workshop FEATURE_PLAN (Updated for WordPress + Odoo API Integration)
*Updated to include Option 1: **WordPress ↔ Odoo REST/JSONRPC API integration***
fileciteturn0file0
---
@ -41,6 +41,23 @@ 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:

View File

@ -0,0 +1,300 @@
<?php
/**
* Plugin Name: OpenWorkshop Odoo API
* Plugin URI: https://hobbyhimmel.de/
* Description: Bindet Daten aus Odoo (OpenWorkshop) per REST-API in WordPress ein. Stellt u.a. den Shortcode [openworkshop_machines] bereit.
* Version: 0.1.0
* Author: HobbyHimmel / Matthias Lotz
* License: GPLv3
* License URI: https://www.gnu.org/licenses/gpl-3.0.html
* Text Domain: openworkshop-odoo-api
*/
if ( ! defined( 'ABSPATH' ) ) {
exit;
}
class OpenWorkshop_Odoo_API_Plugin {
const OPTION_GROUP = 'openworkshop_odoo_api_options';
const OPTION_NAME = 'openworkshop_odoo_api_settings';
public function __construct() {
add_action( 'admin_menu', array( $this, 'register_settings_page' ) );
add_action( 'admin_init', array( $this, 'register_settings' ) );
add_shortcode( 'openworkshop_machines', array( $this, 'shortcode_machines' ) );
}
/**
* Register settings page under Settings OpenWorkshop Odoo API
*/
public function register_settings_page() {
add_options_page(
__( 'OpenWorkshop Odoo API', 'openworkshop-odoo-api' ),
__( 'OpenWorkshop Odoo API', 'openworkshop-odoo-api' ),
'manage_options',
'openworkshop-odoo-api',
array( $this, 'render_settings_page' )
);
}
/**
* Register settings (base URL + optional token)
*/
public function register_settings() {
register_setting(
self::OPTION_GROUP,
self::OPTION_NAME,
array(
'type' => 'array',
'sanitize_callback' => array( $this, 'sanitize_settings' ),
'default' => array(
'base_url' => '',
'api_token' => '',
'machines_endpoint' => '/api/v1/machines',
),
)
);
add_settings_section(
'openworkshop_odoo_api_main',
__( 'Odoo API Einstellungen', 'openworkshop-odoo-api' ),
'__return_false',
'openworkshop-odoo-api'
);
add_settings_field(
'base_url',
__( 'Odoo Basis-URL', 'openworkshop-odoo-api' ),
array( $this, 'render_field_base_url' ),
'openworkshop-odoo-api',
'openworkshop_odoo_api_main'
);
add_settings_field(
'machines_endpoint',
__( 'Endpoint für Maschinenliste', 'openworkshop-odoo-api' ),
array( $this, 'render_field_machines_endpoint' ),
'openworkshop-odoo-api',
'openworkshop_odoo_api_main'
);
add_settings_field(
'api_token',
__( 'API Token (optional)', 'openworkshop-odoo-api' ),
array( $this, 'render_field_api_token' ),
'openworkshop-odoo-api',
'openworkshop_odoo_api_main'
);
}
public function sanitize_settings( $input ) {
$output = array();
$output['base_url'] = isset( $input['base_url'] )
? esc_url_raw( rtrim( $input['base_url'], '/' ) )
: '';
$output['machines_endpoint'] = isset( $input['machines_endpoint'] )
? sanitize_text_field( $input['machines_endpoint'] )
: '/api/v1/machines';
$output['api_token'] = isset( $input['api_token'] )
? sanitize_text_field( $input['api_token'] )
: '';
return $output;
}
public function get_settings() {
$settings = get_option( self::OPTION_NAME, array() );
$defaults = array(
'base_url' => '',
'api_token' => '',
'machines_endpoint' => '/api/v1/machines',
);
return wp_parse_args( $settings, $defaults );
}
public function render_settings_page() {
if ( ! current_user_can( 'manage_options' ) ) {
return;
}
$settings = $this->get_settings();
?>
<div class="wrap">
<h1><?php esc_html_e( 'OpenWorkshop Odoo API Einstellungen', 'openworkshop-odoo-api' ); ?></h1>
<form method="post" action="options.php">
<?php
settings_fields( self::OPTION_GROUP );
do_settings_sections( 'openworkshop-odoo-api' );
submit_button();
?>
</form>
<h2><?php esc_html_e( 'Shortcodes', 'openworkshop-odoo-api' ); ?></h2>
<p><?php esc_html_e( 'Maschinenliste anzeigen:', 'openworkshop-odoo-api' ); ?></p>
<code>[openworkshop_machines]</code>
<p><?php esc_html_e( 'Optional können Attribute verwendet werden, um z. B. eine andere Anzahl von Maschinen anzuzeigen.', 'openworkshop-odoo-api' ); ?></p>
</div>
<?php
}
public function render_field_base_url() {
$settings = $this->get_settings();
?>
<input type="text"
name="<?php echo esc_attr( self::OPTION_NAME ); ?>[base_url]"
value="<?php echo esc_attr( $settings['base_url'] ); ?>"
class="regular-text"
placeholder="https://odoo.example.org" />
<p class="description">
<?php esc_html_e( 'Basis-URL deiner Odoo-Instanz (ohne Slash am Ende). Die API-Route wird daran angehängt.', 'openworkshop-odoo-api' ); ?>
</p>
<?php
}
public function render_field_machines_endpoint() {
$settings = $this->get_settings();
?>
<input type="text"
name="<?php echo esc_attr( self::OPTION_NAME ); ?>[machines_endpoint]"
value="<?php echo esc_attr( $settings['machines_endpoint'] ); ?>"
class="regular-text"
placeholder="/api/v1/machines" />
<p class="description">
<?php esc_html_e( 'Relativer Pfad zum Maschinen-Endpoint. Standard: /api/v1/machines', 'openworkshop-odoo-api' ); ?>
</p>
<?php
}
public function render_field_api_token() {
$settings = $this->get_settings();
?>
<input type="text"
name="<?php echo esc_attr( self::OPTION_NAME ); ?>[api_token]"
value="<?php echo esc_attr( $settings['api_token'] ); ?>"
class="regular-text" />
<p class="description">
<?php esc_html_e( 'Optionaler API-Token, der im Authorization-Header gesendet wird (Bearer &lt;token&gt;).', 'openworkshop-odoo-api' ); ?>
</p>
<?php
}
/**
* Shortcode: [openworkshop_machines]
* Attributes:
* limit Anzahl der Einträge (optional)
*/
public function shortcode_machines( $atts ) {
$atts = shortcode_atts(
array(
'limit' => 0,
),
$atts,
'openworkshop_machines'
);
$data = $this->fetch_machines();
if ( is_wp_error( $data ) ) {
return '<p>' . esc_html__( 'Fehler beim Laden der Maschinendaten aus Odoo.', 'openworkshop-odoo-api' ) . '</p>';
}
if ( ! is_array( $data ) || empty( $data ) ) {
return '<p>' . esc_html__( 'Keine Maschinen gefunden.', 'openworkshop-odoo-api' ) . '</p>';
}
$limit = intval( $atts['limit'] );
if ( $limit > 0 ) {
$data = array_slice( $data, 0, $limit );
}
ob_start();
?>
<div class="openworkshop-machines">
<table class="openworkshop-machines-table">
<thead>
<tr>
<th><?php esc_html_e( 'Name', 'openworkshop-odoo-api' ); ?></th>
<th><?php esc_html_e( 'Bereich', 'openworkshop-odoo-api' ); ?></th>
<th><?php esc_html_e( 'Status', 'openworkshop-odoo-api' ); ?></th>
</tr>
</thead>
<tbody>
<?php foreach ( $data as $machine ) : ?>
<tr>
<td>
<?php echo isset( $machine['name'] ) ? esc_html( $machine['name'] ) : ''; ?>
</td>
<td>
<?php echo isset( $machine['area'] ) ? esc_html( $machine['area'] ) : ''; ?>
</td>
<td>
<?php echo isset( $machine['status'] ) ? esc_html( $machine['status'] ) : ''; ?>
</td>
</tr>
<?php endforeach; ?>
</tbody>
</table>
</div>
<?php
return ob_get_clean();
}
/**
* Calls the Odoo API and returns decoded JSON or WP_Error.
*/
protected function fetch_machines() {
$settings = $this->get_settings();
if ( empty( $settings['base_url'] ) ) {
return new WP_Error( 'openworkshop_no_base_url', __( 'Keine Odoo Basis-URL konfiguriert.', 'openworkshop-odoo-api' ) );
}
$url = $settings['base_url'] . $settings['machines_endpoint'];
$args = array(
'timeout' => 10,
'headers' => array(
'Accept' => 'application/json',
),
);
if ( ! empty( $settings['api_token'] ) ) {
$args['headers']['Authorization'] = 'Bearer ' . $settings['api_token'];
}
$response = wp_remote_get( $url, $args );
if ( is_wp_error( $response ) ) {
return $response;
}
$code = wp_remote_retrieve_response_code( $response );
$body = wp_remote_retrieve_body( $response );
if ( $code < 200 || $code >= 300 ) {
return new WP_Error( 'openworkshop_bad_status', sprintf( 'HTTP %d', $code ) );
}
$data = json_decode( $body, true );
if ( json_last_error() !== JSON_ERROR_NONE ) {
return new WP_Error( 'openworkshop_json_error', json_last_error_msg() );
}
return $data;
}
}
function openworkshop_odoo_api_bootstrap() {
static $instance = null;
if ( $instance === null ) {
$instance = new OpenWorkshop_Odoo_API_Plugin();
}
return $instance;
}
openworkshop_odoo_api_bootstrap();

View File

@ -0,0 +1,30 @@
=== OpenWorkshop Odoo API ===
Contributors: hobbyhimmel
Tags: odoo, api, openworkshop, integration
Requires at least: 5.8
Tested up to: 6.6
Stable tag: 0.1.0
License: GPLv3
License URI: https://www.gnu.org/licenses/gpl-3.0.html
Dieses Plugin bindet Maschinendaten aus einer Odoo/OpenWorkshop-Installation via REST-API in WordPress ein.
== Beschreibung ==
Das Plugin stellt u.a. den Shortcode [openworkshop_machines] bereit, der eine einfache Maschinenliste
auf Basis eines JSON-Endpunkts in Odoo rendert.
In den Einstellungen kann die Basis-URL der Odoo-Instanz, der Endpoint (z.B. /api/v1/machines) sowie ein
optionaler API-Token hinterlegt werden.
== Installation ==
1. ZIP in WordPress unter Plugins → Installieren → Plugin hochladen hochladen.
2. Aktivieren.
3. Unter Einstellungen → OpenWorkshop Odoo API die Basis-URL und den Endpoint konfigurieren.
4. Den Shortcode [openworkshop_machines] in einer Seite oder einem Beitrag einfügen.
== Changelog ==
= 0.1.0 =
* Erste Version.