feat(spp_mis_demo_v2): add child/spouse/other membership types#165
Merged
feat(spp_mis_demo_v2): add child/spouse/other membership types#165
Conversation
Enable the child, spouse, and other group-membership-type vocabulary codes inside the demo module and apply them when generating households. The existing blueprint roles already honor gender and age ranges, so the generator assigns membership types from those roles: head -> head spouse -> spouse child -> child adult, elderly -> other Fix a stale reference to spp_registry.group_membership_kind_child in the add_member change-request demo data; point it to the new xmlid. The types are scoped to spp_mis_demo_v2 (not spp_vocabulary) so that core stays non-prescriptive about household composition.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 19.0 #165 +/- ##
==========================================
+ Coverage 71.45% 71.60% +0.14%
==========================================
Files 932 933 +1
Lines 54792 55372 +580
==========================================
+ Hits 39152 39649 +497
- Misses 15640 15723 +83
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces structured membership types (head, spouse, child, and other) for household members within the demo data generator. Key changes include the definition of new vocabulary codes, updates to the mis_demo_generator and seeded_volume_generator to assign these types based on member roles, and the addition of a test case to verify correct assignment and basic business logic. One improvement was suggested to use the modern Odoo Command helper instead of legacy tuple syntax for Many2many field operations in the seeded volume generator.
|
|
||
| type_id = self._get_membership_type_id(type_code) | ||
| if type_id: | ||
| mval["membership_type_ids"] = [(4, type_id)] |
There was a problem hiding this comment.
Using the Command helper is preferred over the legacy tuple syntax (4, id) for Many2many fields in modern Odoo versions.
Suggested change
| mval["membership_type_ids"] = [(4, type_id)] | |
| mval["membership_type_ids"] = [Command.link(type_id)] |
gonzalesedwin1123
approved these changes
Apr 24, 2026
Member
|
@emjay0921 Please fix the CI / test errors |
… run `_get_demographic_enricher` cached the enricher on the model class (`type(self)._demo_enricher_cache`), which survives TransactionCase savepoint rollbacks between test cases. The enricher's `_bank_ids` / vocab / country caches are populated against a specific cursor at construction time; once that cursor's banks roll back at the end of a test, a later test re-using the cached enricher picks one of those now-non-existent ids and the next `res.partner.bank` insert raises a `res_partner_bank_bank_id_fkey` violation. Past that point Postgres aborts the transaction and the rest of the demo generation falls over, which is exactly what `test_claim169_credential_generation` was hitting in CI. The `_ensure_banks` / `_cache_vocab_ids` lookups inside the enricher are idempotent (search-then-create), so re-instantiating per call costs only a handful of SELECTs and avoids the stale-cache class entirely. Local `spp_mis_demo_v2` suite is now green: 0 failed, 0 errors of 270.
The new `data/vocabulary_group_membership_type.xml` data file registers `child` / `spouse` / `other` membership-type codes. Without a version bump, `Apps → Upgrade` won't re-run data files on existing databases, so these codes wouldn't appear after upgrade — only on fresh installs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why is this change needed?
OpenProject #922 —
spp_mis_demo_v2should populategroup-membership-typeon every household membership so the demo data realistically exercises the vocabulary. Before this change, onlyheadwas assigned; spouse/adult/child members had no type at all, and a demo change-request referenced a non-existent xmlid (spp_registry.group_membership_kind_child).How was the change implemented?
New demo vocabulary data —
spp_mis_demo_v2/data/vocabulary_group_membership_type.xmlregisterschild,spouse,othercodes against the existingvocab_group_membership_typevocabulary. Scoped to the demo module (notspp_vocabulary) so core stays non-prescriptive about household composition.Blueprint roles drive type assignment. The existing story blueprints and seeded blueprints already encode demographically-correct gender and age ranges (child ≤ 17 in most cases, adult spouse opposite-gender to head, etc.). The generator just maps role → membership type:
headheadspousespousechildchildadult,elderlyotherseeded_volume_generator.py— replaced_get_head_type_idwith a cached_get_membership_type_id(code); assigns per-role.mis_demo_generator.py— applies the mapping in_create_household_membersfor spouse, adults, and children (head already had it); also fixed the stale xmlid on thecarlos_elena_moralesadd_member demo change request.New unit tests
test_non_head_members_have_membership_types— asserts every generated membership carries exactly one of{head, spouse, child, other}, at most one spouse per household, andchildmembers are younger than the head.Unit tests executed by the author
Full
spp_mis_demo_v2suite (270 tests, Docker): 0 failed on my changes. The only errors (3) are pre-existingtest_claim169_demoFK issues onres_partner_bank, unrelated to this PR.How to test manually
spp_mis_demo_v2on a fresh DB.Head, optionally oneSpouse, zero or moreChild, with the rest asOther.Related links