Generate a spec-scoped PDF extract and post its link on linked issues #29

New issue

Closed

opened 2026-10-31 21:13:24 +00:00 by Gilles · 0 comments

Gilles commented

2026-10-31 21:13:24 +00:00

Owner

Third and last slice of the Forgejo issue <-> spec link feature (see thierryade/backend#26/#28 for the first two, and the plan discussed in chat).

Scope (PR 3 of 3):

PdfExportJob.spec (FK, nullable, exclusive with project_version): a third export target alongside "this validated version" and "the project's current state" -- "this one spec's live subtree" (rooted at the spec's place, same shape as every other export, just lower in the tree). apps.exports.snapshot.build_current_context() takes an optional root_place to render it.
Reuses the existing PdfExportJobViewSet/Celery task -- no new endpoint, just POST /api/pdf-export-jobs/ {"spec": id}.
Once a spec-scoped export finishes, every SpecVersionIssueLink on that spec gets it as its pdf_export_job and its confirmation comment (apps.specs.tasks.sync_confirmation_comment) is re-synced to fold in a "📄 Extrait PDF" download link -- edited into the same comment the spec-link PR already posts, never a separate one.
No auto-regeneration on every validation (manual trigger only, per the plan) -- a later slice if usage shows it's needed.

Test plan

manage.py test -- 204/204 passing (7 new)
pylint apps config -- 10.00/10
autopep8 --diff clean
bandit -r apps config -- 0 issues
Migrations apply cleanly on a fresh database (two new ones, exports and specs, each depending on the other's prior state -- no cycle, Django ordered them fine)

Third and last slice of the Forgejo issue <-> spec link feature (see thierryade/backend#26/#28 for the first two, and the plan discussed in chat). Scope (PR 3 of 3): - `PdfExportJob.spec` (FK, nullable, exclusive with `project_version`): a third export target alongside "this validated version" and "the project's current state" -- "this one spec's live subtree" (rooted at the spec's place, same shape as every other export, just lower in the tree). `apps.exports.snapshot.build_current_context()` takes an optional `root_place` to render it. - Reuses the existing `PdfExportJobViewSet`/Celery task -- no new endpoint, just `POST /api/pdf-export-jobs/ {"spec": id}`. - Once a spec-scoped export finishes, every `SpecVersionIssueLink` on that spec gets it as its `pdf_export_job` and its confirmation comment (`apps.specs.tasks.sync_confirmation_comment`) is re-synced to fold in a "📄 Extrait PDF" download link -- edited into the *same* comment the spec-link PR already posts, never a separate one. - No auto-regeneration on every validation (manual trigger only, per the plan) -- a later slice if usage shows it's needed. ## Test plan - [x] `manage.py test` -- 204/204 passing (7 new) - [x] `pylint apps config` -- 10.00/10 - [x] `autopep8 --diff` clean - [x] `bandit -r apps config` -- 0 issues - [x] Migrations apply cleanly on a fresh database (two new ones, `exports` and `specs`, each depending on the other's prior state -- no cycle, Django ordered them fine)

Gilles added the

feature

label

2026-10-31 21:13:27 +00:00

Gilles referenced this issue from a commit

2026-10-31 21:13:44 +00:00

feature: generate a spec-scoped PDF extract and post its link on linked issues

Gilles referenced this issue from a pull request that will close it,

2026-10-31 21:13:54 +00:00

feature: generate a spec-scoped PDF extract and post its link on linked issues #30

Gilles closed this issue

2026-10-31 21:37:24 +00:00