Sven/proxmox-selfservice
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update

Browse Source
This commit is contained in:
Sven Steinert
2026-05-04 19:20:22 +02:00
parent fce31ebcd7
commit ec97e1097c
1254 changed files with 421 additions and 174285 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
obyte-qa-tool/README.md
View File

@@ -7,30 +7,30 @@ WordPress plugin version of the legacy `qa-tool` app.
- Frontend shortcode: `[obyte_qa_tool]`
- WordPress backend settings for GitLab and DocBee configuration
- GitLab template loading through a WordPress REST proxy
- GitLab template writeback through WordPress REST, using the backend token
- GitLab template writeback through WordPress REST, using only the token saved in the backend
- Local YAML/JSON template loading
- Full YAML parsing through `js-yaml` with a small built-in fallback parser
- Editable QA steps and groups with drag and drop
- Required-step validation
- Run save/load as JSON
- Markdown, CSV, printable PDF, and YAML template export
- Combined export: DocBee post, WordPress database storage, and Media Library PDF upload
- Combined export: DocBee post, WordPress database storage, and protected PDF storage
- DocBee ticket posting through a server-side REST endpoint with optional ticket-status restoration
## Setup
1. Copy or keep the `obyte-qa-tool` folder in `wp-content/plugins/`.
2. Activate **o-Byte QA Tool** in WordPress.
3. Open **Settings > o-Byte QA Tool**.
3. Open **QA Tool > Settings**.
4. Enter GitLab and DocBee settings. Secrets are stored as WordPress options and are not exposed to frontend JavaScript.
5. Add `[obyte_qa_tool]` to the page where the QA runner should appear.
6. Saved exports can be reviewed under **Tools > o-Byte QA Reports**.
6. Saved exports can be reviewed under **QA Tool > Reports**.
## Notes
- The legacy standalone OIDC login is replaced by WordPress login and capability checks.
- The REST endpoints require the configured WordPress capability.
- GitLab and DocBee credentials from the old PHP files are intentionally not hardcoded into the plugin.
- Access control is expected to be handled by the site/OAuth tag layer before the shortcode is shown.
- The REST endpoints require a logged-in WordPress session, but no plugin-owned capability setting.
- GitLab and DocBee credentials are never hardcoded; secrets must be entered and stored through the backend settings.
- Reports are stored in WordPress-owned custom tables: `wp_obyte_qa_reports` and `wp_obyte_qa_steps` using the active site prefix.
- Exported PDFs are stored as normal Media Library attachments when enabled.
- Exported PDFs are stored in protected plugin storage when enabled. Backend report links are short-lived one-time links.
- Client-side PDF generation uses jsPDF/AutoTable CDNs, matching the standalone tool's browser-based export model.