- Shipped
- September 5, 2026 at 11:46 PM UTC
- Author
- Kamo
- Commit
- 9f1d8c3
The public careers board's Apply button is now a link into registration, so every application is filed against a session. Two fields carry the candidate from the advert to the form, and four letters tell the people involved. TeamMember gains RECENTLY_APPLIED_FOR_ID and IS_SHOW_APPLIED_FOR_APP. SecurityService writes the first at registration from the uid the careers site parked; DocsService lowers the second once the candidate has answered the prompt one way or the other. The uid is deliberately NOT a foreign key to hr_job_posting: careers lives in DocsService and a posting can be archived between applying and signing in, so a dangling uid must degrade to "no prompt" rather than fail the registration itself. The flag defaults TRUE in the column as well as the field. It only ever SUPPRESSES a prompt, so a row nobody has written yet has to read as "show". Four canonical templates. TWO of them are the applicant's own receipt, not one with a variable in it: the renderer is {{key}} substitution with no conditionals, and an ACTIVE team member applying for another role is asking whether it will be held against them, which is not a clause you can swap into a letter that welcomes a stranger. The third tells the hiring manager, carrying no answer from the application itself — a mailbox is not an authorized surface for someone's cover letter, and mail forwards. The fourth is the welcome sent when employment becomes ACTIVE. HR_CAREERS_APPLICATION_RECEIVED is retained but no longer sent. Every org ever seeded holds a row for it, and dropping the key would strip a template administrators may have customised while leaving the row behind. The DDL is in **************** and has to be applied by hand — InitializerService is not deployed.