Serves Demo Scene 3: a fee structure (category x amount lines) with a
term-wise installment schedule generates a correct account.move for a
given enrollment + term, a concession recalculates it correctly, and
the invoice is billed to the primary guardian's partner so stock
portal invoice visibility (partner_id-based) works with no new record
rule. Invoices are plain account.move (_inherit adds mc_student_id/
mc_enrollment_id only) - no invoice model was built, per CLAUDE.md
sec 1.3.
Fixed a real modeling mistake before it shipped: the schedule's
"percentages must total 100%" rule was originally a blocking
@api.constrains on every line write, which breaks the normal workflow
of adding one term at a time (every intermediate state before the
last line is, correctly, under 100%) - and would have broken this
module's own demo data loading, since each schedule line is a
separate XML record. Moved the check to where it actually matters:
the invoice-generation wizard now raises a clear UserError if the
resolved schedule doesn't total 100% at the point of use, while a
live constraint still blocks the one thing that's unambiguously wrong
at any point - allocating more than 100%.
Also found, by testing money arithmetic against a live odoo:19.0
container rather than trusting the arithmetic by inspection: every
generated invoice total came back at exactly 1.15x the expected
amount, because the standing "School Fee" product picked up the demo
company's default sales tax. Fixed by explicitly clearing taxes_id on
the product - school fees are correctly untaxed (education services
are GST-exempt in India), not just conveniently untaxed for the test.
Testing this module's access rules surfaced two real bugs in the
security model, not just test bugs, fixed here:
- group_school_staff (from O1) never implied base.group_user, so
any real user holding only this app's custom groups lacked
ordinary internal-user access to core models like res.company -
caught directly via a test user unable to even create an
mc.fee.structure (whose company_id defaults through
self.env.company).
- mc.fee.concession reveals sensitive per-student financial data
(e.g. a need-based hardship discount and its reason). Staff had
read access, and since group_teacher implies group_school_staff,
teachers inherited it too - exposing family financial
circumstances to a role with no legitimate need for it. Removed
the staff access row; only Administrator/Accountant keep it now.
Fee *structure* (per-program pricing, not sensitive) correctly
stays staff/teacher-readable.
CLAUDE.md gets one more Odoo 19 API correction:
res.users.groups_id -> group_ids.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Coding standards said "No APIs deprecated in 17 or 18" as if that
were sufficient - it isn't, because it's phrased as a non-regression
check against an assumed-correct baseline, and the baseline itself
(an 18-era mental model of _sql_constraints and res.groups) was
already wrong for 19. Verified against a real odoo:19.0 container
while building mc_education_base: _sql_constraints is replaced by
per-attribute models.Constraint(sql, message), and res.groups lost
category_id in favor of a new res.groups.privilege record referenced
via privilege_id.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
docker-compose.yml (postgres 16 + odoo:19.0), odoo.conf, env template,
and setup/backup/update/demo-data scripts. update.sh always backs up
and records the previous image before upgrading modules, per the
lesson paid for on the Frappe track. .gitattributes pins LF on shell
scripts so they don't break under the container's bash on checkout
from Windows.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
