From bd9b449ded275bbca537224d9017279fa4c3d9f3 Mon Sep 17 00:00:00 2001 From: metatroncubeswdev Date: Fri, 11 Sep 2026 15:06:31 -0400 Subject: [PATCH] fix: create the four backend demo logins the demo script actually needs shared/DEMO_SCRIPT.md's cast table names six logins. Two - the parent and student portal accounts - were created in mc_education_portal. The other four (Principal, Front Office, Teacher, Accountant) were explicitly punted to O9: mc_education_base's demo/mc_teacher_demo.xml says outright "res.users/login creation is O9's job (demo rehearsal), not this base module." That job was never actually done - found only now, while writing a demo handbook that needed to print real, working credentials and I checked them against a live container before printing anything. Concretely this means a from-scratch rehearsal of the demo script would have stalled at Scene 1: there was no way to log in as Rekha Nair, Sunitha R, or David Fernandes at all, and logging in as "Arun Prakash" would have meant either sharing the admin account or creating an unlinked user that fails Scene 4's actual point - a teacher seeing only their own batch, which the attendance record rule resolves through batch_id.class_teacher_id.user_id. Arun's login is now attached to the same hr.employee record mc_education_base's own demo data already made Grade 8-A's class teacher, not a fresh one. Real Odoo behaviour learned fixing this, worth recording since it will bite again: demo data loads with noupdate=True so a school's own edits survive a later module update, and that guard is checked by xmlid, not by which file is doing the writing - a in this module trying to set an existing mc_education_base demo record's field was silently skipped, no error, nothing in the log. calls the ORM directly and is the correct tool, but carries the same guard one level up in Odoo's loader (convert.py's _tag_function skips entirely unless the module is being freshly installed, mode == 'init' - an update on an already-installed database is a no-op). That is exactly the real story this product cares about (a clean machine, installing the whole suite once), so it's the right fix going forward - verified on a from-scratch install of all nine modules together. The one already-running database that had this module installed before this fix existed needed a one-off manual correction outside the codebase, not a workaround inside it. Added a regression test asserting all four logins exist in the right group and that Arun's employee record and Grade 8-A's class_teacher_id actually resolve to the same person - not just "a teacher login exists somewhere." Co-Authored-By: Claude Sonnet 5 --- addons/mc_education_theme/__manifest__.py | 1 + .../demo/mc_cast_users_demo.xml | 82 +++++++++++++++++++ addons/mc_education_theme/tests/test_theme.py | 34 ++++++++ 3 files changed, 117 insertions(+) create mode 100644 addons/mc_education_theme/demo/mc_cast_users_demo.xml diff --git a/addons/mc_education_theme/__manifest__.py b/addons/mc_education_theme/__manifest__.py index 267dd2f..afb766c 100644 --- a/addons/mc_education_theme/__manifest__.py +++ b/addons/mc_education_theme/__manifest__.py @@ -17,6 +17,7 @@ ], "demo": [ "demo/mc_theme_demo.xml", + "demo/mc_cast_users_demo.xml", ], "installable": True, "application": False, diff --git a/addons/mc_education_theme/demo/mc_cast_users_demo.xml b/addons/mc_education_theme/demo/mc_cast_users_demo.xml new file mode 100644 index 0000000..49271f7 --- /dev/null +++ b/addons/mc_education_theme/demo/mc_cast_users_demo.xml @@ -0,0 +1,82 @@ + + + + + Rekha Nair + principal@demo.school + principal@demo.school + demo1234 + + + + + Sunitha R + office@demo.school + office@demo.school + demo1234 + + + + + Arun Prakash + teacher@demo.school + teacher@demo.school + demo1234 + + + + + + + + + + + David Fernandes + accounts@demo.school + accounts@demo.school + demo1234 + + + diff --git a/addons/mc_education_theme/tests/test_theme.py b/addons/mc_education_theme/tests/test_theme.py index f785440..0535b08 100644 --- a/addons/mc_education_theme/tests/test_theme.py +++ b/addons/mc_education_theme/tests/test_theme.py @@ -30,3 +30,37 @@ class TestTheme(TransactionCase): self.assertNotIn("Powered by", html) self.assertNotIn("odoo.com", html) self.assertNotIn("Odoo Logo", html) + + def test_backend_cast_logins_exist_in_the_right_groups(self): + # shared/DEMO_SCRIPT.md's cast table names six logins. Two + # (parent@demo.school, student@demo.school) are created by + # mc_education_portal. The other four were explicitly deferred + # to this module (see demo/mc_cast_users_demo.xml) and, until + # that file existed, were never actually created anywhere - + # the demo script would have stalled at Scene 1 on a clean + # rehearsal. This test is the regression guard for that gap. + principal = self.env["res.users"].search([("login", "=", "principal@demo.school")]) + self.assertTrue(principal) + self.assertIn( + self.env.ref("mc_education_base.group_school_administrator"), principal.group_ids + ) + + office = self.env["res.users"].search([("login", "=", "office@demo.school")]) + self.assertTrue(office) + self.assertIn(self.env.ref("mc_education_base.group_school_staff"), office.group_ids) + + accountant = self.env["res.users"].search([("login", "=", "accounts@demo.school")]) + self.assertTrue(accountant) + self.assertIn(self.env.ref("mc_education_base.group_accountant"), accountant.group_ids) + + teacher = self.env["res.users"].search([("login", "=", "teacher@demo.school")]) + self.assertTrue(teacher) + self.assertIn(self.env.ref("mc_education_base.group_teacher"), teacher.group_ids) + + # Not just "a teacher login exists" - it has to be *the* login + # that Grade 8-A's class_teacher_id points at, because that is + # what mc_education_attendance's record rule actually checks. + arun = self.env.ref("mc_education_base.demo_employee_arun_prakash") + self.assertEqual(arun.user_id, teacher) + grade_8a = self.env.ref("mc_education_base.demo_batch_grade8_a") + self.assertEqual(grade_8a.class_teacher_id, arun)