508bf27417
Serves Demo Scene 2 end to end: mc.applicant with the stage pipeline (Applied -> Document Verification -> Interview -> Offered -> Accepted -> Enrolled/Rejected) on mail.thread, a public admission page on the website, and a convert wizard that turns an accepted applicant into a real mc.student + mc.enrollment with zero re-typing. The public form uses Odoo's stock /website/form/<model> mechanism, not a custom controller (CLAUDE.md sec 1.3 - writing a custom version of stock infrastructure is a bug). Verified the real mechanism against core source first rather than assuming: website_hr_recruitment's own data/config_data.xml is the template this follows (ir.model. website_form_access + ir.model.fields.formbuilder_whitelist()). This is the module's actual security boundary, and it's worth being explicit about why it holds. The generic controller creates the record as SUPERUSER - normal ir.model.access rows do not apply to it at all. The only thing stopping a submitter from setting state, student_id, application_no or company_id is that those fields are not in the formbuilder_whitelist() call in data/mc_applicant_website_form_data.xml (every field defaults to website_form_blacklisted=True and stays that way unless explicitly opted in). Confirmed this isn't just theoretical: posted state=enrolled and application_no=HACKED-0001 directly at /website/form/mc.applicant on a live instance, and the resulting record came back with the model's own default state=applied and a server-generated APP20260004 - the injected values were silently dropped, exactly as the whitelist should do. Also exercised a real file upload (birth certificate) and the full convert-to-student path (guardian dedup by email, application_no -> student.application_no, enrollment, attachment reparenting) via odoo shell against the live container, not just read by inspection. mc.student gets a new application_no field (_inherit from this module, not O1 - it only makes sense where admission is installed) so "the application number persists on the student" is a stored fact, not just a claim in the demo script. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
651 B
651 B
| 1 | id | name | model_id:id | group_id:id | perm_read | perm_write | perm_create | perm_unlink |
|---|---|---|---|---|---|---|---|---|
| 2 | access_mc_applicant_administrator | mc.applicant.administrator | model_mc_applicant | mc_education_base.group_school_administrator | 1 | 1 | 1 | 1 |
| 3 | access_mc_applicant_staff | mc.applicant.staff | model_mc_applicant | mc_education_base.group_school_staff | 1 | 1 | 1 | 0 |
| 4 | access_mc_applicant_convert_wizard_administrator | mc.applicant.convert.wizard.administrator | model_mc_applicant_convert_wizard | mc_education_base.group_school_administrator | 1 | 1 | 1 | 1 |
| 5 | access_mc_applicant_convert_wizard_staff | mc.applicant.convert.wizard.staff | model_mc_applicant_convert_wizard | mc_education_base.group_school_staff | 1 | 1 | 1 | 1 |