Let the browser extension show a capture before sending it, and send corrections with it #171

New issue

Closed

opened 2026-09-10 14:03:44 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-09-10 14:03:44 +00:00

Owner

What

The browser extension should show what Postulo read from a page before it is sent, so
the person can correct it in the popup. It still lands in the review queue afterwards, with
their corrections filled in: nothing about what a captures token may do changes.

Today the extension can only send the page and hope. POST /captures parses and stores in
one go, so the first time anybody sees what the parser made of the page is on the review
screen, one tab and one sign-in away.

The API

POST /captures/preview, scope captures: the same body as POST /captures (url,
optionally html), the same refusals (422 when nothing resembling a posting is there),
and it answers with what the parser read and which source read it. It creates nothing
and notifies nobody.
POST /captures takes an optional data: the fields a person corrected. The page is
still parsed, so the capture's source stays the parser that read it; each field given
replaces what was read, and the whole is validated through JobPostingData exactly as a
plugin's output is. An unknown field or an empty title is a 422. The capture is pending as
before, and the review screen opens with the corrected values.

The extension (postulo-chromium, its own repo)

Capture → the popup shows the posting's fields, filled in from the preview → Send for
review sends the page with the fields that were changed. Against a Postulo without the
preview endpoint it sends straight away, as it does now.

Done when

Both are in the OpenAPI description and the wiki's API page.
Tests: preview creates nothing and answers the parse; preview needs captures; corrections
replace fields and nothing else; an unknown field and an empty title are refused; a
capture without data is stored exactly as before.

## What The browser extension should show what Postulo read from a page **before** it is sent, so the person can correct it in the popup. It still lands in the review queue afterwards, with their corrections filled in: nothing about what a `captures` token may do changes. Today the extension can only send the page and hope. `POST /captures` parses and stores in one go, so the first time anybody sees what the parser made of the page is on the review screen, one tab and one sign-in away. ## The API - **`POST /captures/preview`**, scope `captures`: the same body as `POST /captures` (`url`, optionally `html`), the same refusals (422 when nothing resembling a posting is there), and it answers with what the parser read and which source read it. **It creates nothing** and notifies nobody. - **`POST /captures` takes an optional `data`**: the fields a person corrected. The page is still parsed, so the capture's source stays the parser that read it; each field given replaces what was read, and the whole is validated through `JobPostingData` exactly as a plugin's output is. An unknown field or an empty title is a 422. The capture is pending as before, and the review screen opens with the corrected values. ## The extension (postulo-chromium, its own repo) Capture → the popup shows the posting's fields, filled in from the preview → *Send for review* sends the page with the fields that were changed. Against a Postulo without the preview endpoint it sends straight away, as it does now. ## Done when - Both are in the OpenAPI description and the wiki's API page. - Tests: preview creates nothing and answers the parse; preview needs `captures`; corrections replace fields and nothing else; an unknown field and an empty title are refused; a capture without `data` is stored exactly as before.

tiagoagueda added this to the 0.3.0 milestone

2026-09-10 14:03:44 +00:00

tiagoagueda added the

enhancement

tier

labels

2026-09-10 14:03:44 +00:00

tiagoagueda referenced this issue from a commit

2026-09-10 14:14:21 +00:00

Let a capture be seen before it is sent, and corrected on the way

tiagoagueda closed this issue

2026-09-10 14:14:22 +00:00