- Ya
- 4 Septemba 2026, 04:53 UTC
- Mwandishi
- Kamo
- Ahadi ya
- cab5e26
member_id on hr_job_application becomes NULLABLE, which is the whole of apply-first: five steps stood between pressing Apply and answering the first question, and the two steepest — create an account, verify an email — came before we had learned anything at all. An application can now exist before its author does, with a claim token that attaches an account later. Every query joining that column must be a LEFT join. An inner one drops exactly the rows this adds, hiding public applications from the Applicants tab while failing nowhere; findForOrgWithPostingAndMember is fixed and says why. Two org columns: careers_site_enabled (an org that wants no public board should not answer on that host at all) and careers_network_opt_in, default FALSE — publishing your roles beside every other tenant's is a decision, not a default. Three counters on a posting — impressions, detail views, apply clicks — reset with listedAt like the applicant count, incremented with UPDATE ... SET c = c+n so concurrent pods do not lose each other's writes. And jobBenefits, which has a home in schema.org that body prose does not. Two new entities. JobPostingTranslation carries a fingerprint of the text it was made from, so an edit invalidates twenty-one languages the same second rather than leaving them describing an old salary. CareersTalentAlert carries the whole consent lifecycle — double opt-in, a never-expiring unsubscribe token, and an expiry — because it is a public form that stores a stranger's address. Plus purge_after: applications hold a name, an email and a CV, and keeping them forever is not a neutral default.