Offers: record what was offered, and compare offers side by side #237

New issue

Closed

opened 2026-09-15 21:23:32 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-09-15 21:23:32 +00:00

Owner

The moment a job search has the most at stake is the one Postulo records least. Found in the 2026-09-15 code audit.

Today

Offer is only a status (applications/models.py:46) plus an "Offer received" timeline kind (:344).
There is nowhere to record:
- the amount, currency and period;
- bonus or equity;
- benefits, remote days and holidays;
- the start date;
- the date to answer by.
The only salary fields are the posting's advertised range, which is often not what gets offered.

Proposal

An Offer model hanging off Application, owner-scoped like everything else. One offer or more per application, since offers get revised, with each revision recorded on the timeline through record_event.
Fields:
- base amount, currency and period;
- variable pay and equity as text;
- benefits;
- location or remote arrangement;
- start date;
- answer-by date;
- notes.
  Currency validated as ISO 4217, reusing the salary work from the Insights/salaries issue (#224).
Answer-by date: shown on the calendar, and creating a reminder by default.
Comparison page: every application currently at Offer side by side, with amounts annualised within a currency and each field on its own row. No scoring and no recommendation; the person decides.
API and export: offers in the API (read scope) and in the account export.
Accessibility: the comparison is a real table with row and column headers, readable at phone width (stacked, not scrolled sideways).

The moment a job search has the most at stake is the one Postulo records least. Found in the 2026-09-15 code audit. ## Today - *Offer* is only a status (`applications/models.py:46`) plus an "Offer received" timeline kind (`:344`). - There is nowhere to record: - the amount, currency and period; - bonus or equity; - benefits, remote days and holidays; - the start date; - the date to answer by. - The only salary fields are the posting's advertised range, which is often not what gets offered. ## Proposal - **An `Offer` model hanging off `Application`**, owner-scoped like everything else. One offer or more per application, since offers get revised, with each revision recorded on the timeline through `record_event`. - **Fields:** - base amount, currency and period; - variable pay and equity as text; - benefits; - location or remote arrangement; - start date; - answer-by date; - notes. Currency validated as ISO 4217, reusing the salary work from the Insights/salaries issue (#224). - **Answer-by date:** shown on the calendar, and creating a reminder by default. - **Comparison page:** every application currently at *Offer* side by side, with amounts annualised within a currency and each field on its own row. No scoring and no recommendation; the person decides. - **API and export:** offers in the API (read scope) and in the account export. - **Accessibility:** the comparison is a real table with row and column headers, readable at phone width (stacked, not scrolled sideways).

tiagoagueda added the

enhancement

label

2026-09-15 21:23:32 +00:00

tiagoagueda referenced this issue

2026-09-15 21:24:50 +00:00

Outbound events: a signed webhook notifier and more events than three #240

tiagoagueda added this to the 0.5.0 milestone

2026-09-15 21:33:31 +00:00

tiagoagueda referenced this issue from a commit

2026-09-22 13:51:18 +00:00

Record what was offered, and put offers side by side