- Shipped
- September 5, 2026 at 11:47 PM UTC
- Author
- Kamo
- Commit
- fc3629f
The public board's Apply button is now a link into registration, so this drops the endpoints behind the old form: /{orgRef}/apply/{uid} in both content types, /{orgRef}/resume-scan, the claim endpoint, PublicApplyService and ResumeScanService. Worth stating plainly, because the removal is not an obvious win and a future reader will wonder: apply-first measurably converted better. What it could not do is know who applied. A row keyed on a typed email address cannot be tracked or withdrawn by the person who sent it except through a token in an inbox, every hire has to be reconciled to an account by hand, and each of those rows is a duplicate waiting to happen. Filing against a session makes the application belong to a member from the first moment. That is the trade. JobApplication's claim columns are left in the table. Dropping columns is destructive and the rows are still records of real applications. ApplicationSubmissionNotifier sends the hiring manager's notice and the applicant's own receipt. Everything it needs is copied out of the entities BEFORE the transaction ends and the sends are deferred to afterCommit: applying stores the résumé inside the same transaction and a REQUIRED one that fails to store rolls the whole thing back, so an inline send would tell a candidate their application is in when it is not. TWO applicant templates, chosen not composed. The renderer has no conditionals, and an ACTIVE team member applying for another role is asking whether it will be held against them — not a clause you can swap into a letter that welcomes a stranger. Both go to the USER account address; a candidate who registered yesterday has no work mailbox. The manager's letter carries no answer from the application itself. A mailbox is not an authorized surface for someone's cover letter or salary expectation, and mail forwards — it carries what is needed to decide whether to open it, and the link does the rest behind a session. CareersAccess.requireView also admits a team member whose employment is not yet ACTIVE. Not a loosening so much as the gate catching up with where the product now sends people: a candidate who registered from a job advert holds no rights at all, because rights arrive with a role and a role arrives with the job. It admits them to the board and to their OWN applications — no endpoint on that surface takes a member id — and never to requireManage.