Open Workshop Multi Module Refactoring

This commit is contained in:
Matthias Lotz 2025-12-07 14:03:32 +01:00
parent 7cd458b72f
commit 58c7e8f258
30 changed files with 451 additions and 1 deletions

View File

@ -0,0 +1,221 @@
# 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.

View File

@ -0,0 +1,228 @@
# Open Workshop FEATURE_PLAN (Updated for WordPress + Odoo API Integration)
*Updated to include Option 1: **WordPress ↔ Odoo REST/JSONRPC API integration***
fileciteturn0file0
---
# 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.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,11 +1,12 @@
{
'name': 'POS Open Workshop',
'license': 'AGPL-3',
'version': '18.0.1.0.1',
'version': '18.0.1.0.2',
'summary': 'Erstellt Maschinenfreigaben basierend auf POS-Einweisungsprodukten',
'depends': ['base', 'account', 'hr','product','sale','contacts','point_of_sale'],
'author': 'matthias.lotz',
'category': 'Point of Sale',
'data': [
'security/ir.model.access.csv',
'views/machine_product_training_views.xml',