119 lines
4.7 KiB
Markdown
119 lines
4.7 KiB
Markdown
# Workdock
|
|
|
|
Workdock is the dockerized business operations platform that powers internal company apps such as onboarding, offboarding, requests, integrations, backups, and future modular workplace tools.
|
|
|
|
## Services
|
|
- `web`: Django app (`http://localhost:8000`)
|
|
- `worker`: Celery async tasks
|
|
- `db`: PostgreSQL
|
|
- `redis`: task broker
|
|
- `mailhog`: local email inbox (`http://localhost:8025`)
|
|
|
|
## Quick start
|
|
1. Copy env file:
|
|
- `cp .env.example .env`
|
|
2. Fill `.env` values (reuse your current credentials privately).
|
|
3. Start services:
|
|
- `docker compose up --build`
|
|
4. Open app:
|
|
- `http://localhost:8000/onboarding/new/`
|
|
5. Open test mailbox:
|
|
- `http://localhost:8025`
|
|
|
|
## Translations
|
|
This project now uses Django's standard i18n workflow for long-term maintainability.
|
|
|
|
- Extract/update message catalogs:
|
|
- `docker compose exec -T web django-admin makemessages -l en`
|
|
- Compile translations:
|
|
- `docker compose exec -T web django-admin compilemessages`
|
|
- Add more languages the same way:
|
|
- `docker compose exec -T web django-admin makemessages -l de`
|
|
- Convenience targets:
|
|
- `make i18n-update-en`
|
|
- `make i18n-update-de`
|
|
- `make i18n-compile`
|
|
|
|
Notes:
|
|
- `gettext` is installed in the Docker image, so `compilemessages` works inside the container.
|
|
- Translation files live under `backend/locale/`.
|
|
- Core fixed UI is bilingual now.
|
|
- Dynamic builder-driven content is now bilingual for:
|
|
- Form Builder option labels
|
|
- Form Builder field label/help-text overrides
|
|
- Intro Builder checklist item labels
|
|
- Admin-configured email templates are now bilingual for:
|
|
- notification template subjects and bodies in DE/EN
|
|
- notification rule custom subjects and bodies in DE/EN
|
|
- welcome email subject and body in DE/EN
|
|
- request language capture on onboarding/offboarding to choose the correct email language
|
|
- Language stability hardening is in place:
|
|
- onboarding/offboarding request records normalize `preferred_language` at model-save time
|
|
- both request tables now have a database default of `de`
|
|
- Generated PDF fixed text is now bilingual for:
|
|
- onboarding PDF
|
|
- offboarding PDF
|
|
- intro PDF
|
|
- live introduction protocol PDF
|
|
- Remaining bilingual gap is mostly long-form handbook/wiki copy and a few secondary admin/help texts.
|
|
- CI now validates that translation catalogs compile successfully on push and pull request.
|
|
- Automated bilingual smoke coverage now verifies DE/EN request language capture plus English email-template selection for onboarding and welcome flows.
|
|
- Dependency stability hardening pins `chardet==5.2.0` so `requests` runs without compatibility warnings in the Docker stack.
|
|
|
|
## Current implemented scope
|
|
- Onboarding form with labels mapped from your CSV schema.
|
|
- Stores requests in PostgreSQL.
|
|
- Generates a personalized PDF (simple first version).
|
|
- Sends notification email via Celery.
|
|
- Optional Nextcloud upload hook (toggle with `NEXTCLOUD_ENABLED=1`).
|
|
|
|
## Staging E2E verification
|
|
Run a real workflow verification (onboarding + offboarding), including PDF checks and optional email/Nextcloud evidence:
|
|
|
|
- Default (auto MailHog detection, Nextcloud check enabled if configured):
|
|
- `docker compose exec -T web python manage.py run_staging_e2e_check`
|
|
- With cleanup (removes generated E2E DB rows/PDFs after run):
|
|
- `docker compose exec -T web python manage.py run_staging_e2e_check --cleanup`
|
|
- Force MailHog verification mode:
|
|
- `docker compose exec -T web python manage.py run_staging_e2e_check --email-check mailhog --mailhog-api-url http://mailhog:8025/api/v2/messages`
|
|
- Skip Nextcloud existence checks:
|
|
- `docker compose exec -T web python manage.py run_staging_e2e_check --skip-nextcloud`
|
|
|
|
## Backup and restore
|
|
Use the repo-level scripts so database and media backups stay consistent.
|
|
|
|
- Create a backup bundle:
|
|
- `make backup-create`
|
|
- Verify a backup non-destructively:
|
|
- `make backup-verify BACKUP_DIR=backend/backups/backup_YYYYmmdd_HHMMSS`
|
|
- Real restore:
|
|
- `./scripts/backup_restore.sh --yes-restore backend/backups/backup_YYYYmmdd_HHMMSS`
|
|
|
|
What is included:
|
|
- PostgreSQL custom-format dump: `db.dump`
|
|
- media archive: `media.tar.gz`
|
|
- metadata file and SHA256 checksums
|
|
- default storage path: `backend/backups/`
|
|
|
|
Verification behavior:
|
|
- restores the dump into a temporary verification database
|
|
- extracts media into a temporary directory
|
|
- checks that the restored DB and media structure are readable
|
|
|
|
## Release validation
|
|
Use one local gate before shipping larger changes:
|
|
|
|
- `make release-validate`
|
|
|
|
What it runs:
|
|
- Django system checks
|
|
- full workflow test suite
|
|
- translation compile
|
|
- collectstatic
|
|
- latest-backup verification
|
|
- production-like onboarding/offboarding smoke check
|
|
|
|
CI mirrors this split in two layers:
|
|
- fast Python validation
|
|
- Docker-based release gate with backup verification and smoke workflow checks
|