fix(n8n): repair school intake upload flow

This commit is contained in:
Fizzlepoof
2026-05-14 01:56:07 +00:00
parent 31223c875d
commit a650c1a56b
5 changed files with 441 additions and 36 deletions

View File

@@ -1,8 +1,8 @@
# School Paperless Intake Workflow
Current workflow versions:
- `n8n-workflows/18-school-paperless-intake-v1.1.json`
- `n8n-workflows/19-paperless-school-metadata-enrichment-v1.0.json`
- `n8n-workflows/18-school-paperless-intake-v1.2.json`
- `n8n-workflows/19-paperless-school-metadata-enrichment-v1.1.json`
This workflow set is meant for a Telegram chat-driven upload pipeline that sends schoolwork into Paperless-NGX while recording intake metadata in shared Postgres.
@@ -15,7 +15,7 @@ When these workflow artifacts change, the version must change too:
## What it does
### Workflow 18 — v1.1
### Workflow 18 — v1.2
1. Accepts a multipart upload at `POST /webhook/school/intake/upload`
2. Requires form fields:
@@ -38,11 +38,9 @@ When these workflow artifacts change, the version must change too:
## Shared Postgres expectations
- Use the shared Postgres network/credentials pattern already used by the automation stack.
- The workflow expects an n8n Postgres credential named `Shared Postgres`.
- Preferred target database: dedicated `school_intake`
- Current fast-path/live bootstrap also works against the existing `n8n` database, provided the schema tables are created there.
- If you are using the current PD bootstrap path, point the n8n credential at database `n8n` with the existing Postgres account.
- Tracked schema: `docs/reference/SCHOOL_INTAKE_POSTGRES_SCHEMA.sql`
- Earlier drafts used shared Postgres tracking, but the current live-tested v1.2/v1.1 path works without Postgres dependency in the webhook chain.
- Deterministic filename/title are now the source of correlation between upload and enrichment.
- Tracked schema: `docs/reference/SCHOOL_INTAKE_POSTGRES_SCHEMA.sql` (kept for future DB-backed intake tracking if reinstated)
## Required environment variables
@@ -86,6 +84,7 @@ Notes:
- `PAPERLESS_TAG_CLASS_MAP_JSON`, `PAPERLESS_TAG_SUBMISSION_KIND_MAP_JSON`, `PAPERLESS_DOCUMENT_TYPE_PAPER_KIND_MAP_JSON`, and `PAPERLESS_CORRESPONDENT_CLASS_MAP_JSON` are optional JSON maps used by workflow 19.
- Leave optional Paperless IDs and JSON maps blank/default if you prefer to start with deterministic title + generic tags only.
- Workflow 18 v1.1 no longer requires `crypto`, so `NODE_FUNCTION_ALLOW_BUILTIN=crypto` is optional instead of required.
- Workflow 18 v1.2 fixes the Paperless multipart upload by using `inputDataFieldName` for the binary form field.
- `N8N_BLOCK_ENV_ACCESS_IN_NODE` must remain `false`.
## Paperless metadata behavior
@@ -100,7 +99,7 @@ Workflow 18 deliberately keeps the Paperless upload minimal and safe:
The deterministic filename/title preserve the `intake_id` for later correlation.
### Workflow 19 — v1.0
### Workflow 19 — v1.1
Workflow 19 handles the follow-up metadata pass after Paperless finishes processing:
- fetch Paperless document by webhook document id
@@ -118,12 +117,10 @@ Use the example curl request in:
Minimum test checklist:
1. Import the workflow into n8n.
2. Attach the `Shared Postgres` credential.
3. Confirm the target DB/table exists in either `school_intake` or `n8n`, depending on which credential/database you are using.
4. Send the sample multipart request.
5. Verify a row appears in `school_paperless_intake` with `status=uploaded`.
6. Verify the uploaded Paperless document title and stored filename both include the deterministic intake ID.
7. Trigger workflow 19 with the Paperless document id and verify the row moves to `status=enriched`.
8. Re-submit the same file and metadata to confirm the same `intake_id` is reused and the Postgres row is upserted.
3. Send the sample multipart request.
4. Verify the uploaded Paperless document title and stored filename both include the deterministic intake ID.
5. Trigger workflow 19 with the Paperless document id and verify title/tags enrichment succeeds.
6. Re-submit the same file and metadata to confirm the same deterministic `intake_id` pattern is reused.
## Known assumptions / caveats