Skip to content

fix: prepare spp_cel_vocabulary for stable release#106

Open
gonzalesedwin1123 wants to merge 15 commits into19.0from
feat/spp-cel-vocabulary-stable-release
Open

fix: prepare spp_cel_vocabulary for stable release#106
gonzalesedwin1123 wants to merge 15 commits into19.0from
feat/spp-cel-vocabulary-stable-release

Conversation

@gonzalesedwin1123
Copy link
Member

Summary

Prepares spp_cel_vocabulary for Production/Stable status after staff engineer and UX expert
reviews identified bugs, documentation inconsistencies, and Odoo 19 compliance gaps.

  • Fix display_namelabel bug in test concept group creation (field was silently ignored)
  • Migrate all old-style tuples to Odoo 19 Command API in tests (17 occurrences)
  • Standardize documentation on r prefix and _id field suffixes across all docs/docstrings
  • Fix phantom relationship_type field references (replaced with relationship_type_id + notes)
  • Improve translator error messages with "how to fix" guidance for 14 error paths
  • Add QA UI testing guide with 10 test scenarios (readme/USAGE.md)
  • Add maintainers list to manifest

Bug Fixes

  • _create_test_concept_group helper in spp_cel_domain/tests/common.py used display_name
    (a computed field silently ignored by Odoo) instead of label — fixed at root cause
  • 17 test occurrences of display_name replaced with label across all 4 test files
  • relationship_type referenced in 8 doc/docstring locations does not exist as a field —
    replaced with relationship_type_id and added notes that is_head() requires a
    deployment-defined code field

Odoo 19 Compliance

  • Replaced 14 (4, id)Command.link(id) and 3 (6, 0, [ids])Command.set([ids])

Documentation

  • Standardized all docs on r prefix (was me. in 66 locations)
  • Fixed field names to include _id suffix (53 occurrences across docs + docstrings)
  • Fixed menu paths to "Settings > Vocabularies > Concept Groups"
  • Added head() to quick reference tables with is_head() vs head() distinction
  • Added "When to Use Which Function" decision guide
  • Added sudo() justification comment in head() function
  • Added QA UI testing guide (10 scenarios covering installation, concept groups, CEL
    expression validation, security, local codes, empty/missing groups)

Files Changed (16 files, +1240/-225)

File Changes
spp_cel_domain/tests/common.py Fix helper: display_namelabel, Command API
spp_cel_vocabulary/__manifest__.py Add maintainers
spp_cel_vocabulary/models/cel_vocabulary_translator.py Error message improvements, docstring fixes
spp_cel_vocabulary/services/cel_vocabulary_functions.py Docstring fixes, sudo() comment
spp_cel_vocabulary/tests/test_*.py (4 files) display_namelabel, Command API
spp_cel_vocabulary/README.md Prefix, field names, structure diagram
spp_cel_vocabulary/USAGE.md Prefix, field names, decision guide, disclaimers
spp_cel_vocabulary/data/README.md Menu path, XML IDs, label, Command API
spp_cel_vocabulary/data/concept_groups.xml Fix old-style tuple in comment
spp_cel_vocabulary/readme/DESCRIPTION.md Field names, operator consistency
spp_cel_vocabulary/readme/USAGE.md New: QA UI testing guide
spp_cel_vocabulary/README.rst + index.html Regenerated

Test plan

  • spp_cel_vocabulary: 117/117 tests pass
  • spp_cel_domain: 569/569 tests pass (cross-module helper change)
  • All pre-commit hooks pass (ruff, prettier, pylint, semgrep, bandit, OpenSPP checks)
  • Test coverage estimated at ~99% (all error paths, edge cases, and integrations covered)
  • QA: Follow UI testing guide in readme/USAGE.md (10 test scenarios)
  • After QA approval: change development_status to "Production/Stable"

display_name is a computed field in Odoo and gets silently ignored during
create(). The correct field on spp.vocabulary.concept.group is label.
Also migrate old-style tuple to Command API.
Fix r.gender → r.gender_id and m._link.kind → m.relationship_type
in all function docstrings. Add comment explaining why sudo() is
needed in head() function.
Add actionable guidance to warning messages (menu paths, field name
hints). Fix r.gender → r.gender_id in docstring examples.
Standardize on r prefix, fix gender → gender_id, add vocabulary_cache.py
and all test files to structure diagram, update test command, fix XML
example to use label and search-by-name pattern, add head() to helpers.
Replace display_name → label in concept group create() calls (17
occurrences). display_name is a computed field that gets silently
ignored; label is the correct field. Also migrate old-style tuples
(4, id) and (6, 0, [ids]) to Command.link() and Command.set().
Standardize on r prefix (49 me. → r.), fix field names to use _id
suffix (gender_id, not gender), replace m._link.kind with head(m),
add head() to Quick Reference, add "When to Use Which" guide, add
disclaimers for country-module fields and external functions.
Fix menu path to Settings > Vocabularies > Concept Groups, note
that groups are created by hook (no XML IDs), fix display_name →
label in XML examples, fix Python example to use Command API, add
note about cel_function being metadata only.
Concise quick reference with function table, basic examples,
and when-to-use-which guide for inclusion in README.rst.
The readme/USAGE.md will contain a UI testing guide for QA.
Current developer quick reference content is already in root USAGE.md.
- H-1: replace phantom relationship_type with relationship_type_id,
  add notes that is_head() requires deployment-defined code field
- H-2: replace old-style tuple in concept_groups.xml comment with
  Python search-and-write pattern
- M-2: clarify "Display name" → "Label (display value)" in README.md
- L-1: standardize && to and in DESCRIPTION.md and docstrings
- L-2: standardize menu path separator → to > in data/README.md
10 test scenarios covering: concept group verification, adding codes,
idempotent installation, CEL expression validation, domain translation,
empty/nonexistent group behavior, local codes, security, and search.
@gemini-code-assist
Copy link

Summary of Changes

Hello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the spp_cel_vocabulary module by addressing critical bugs, ensuring full compatibility with Odoo 19's Command API, and vastly improving its documentation. The changes aim to provide a more robust, maintainable, and user-friendly experience, particularly for developers and QA engineers working with CEL expressions and vocabulary management.

Highlights

  • Bug Fixes: Fixed a bug where display_name was incorrectly used instead of label in test concept group creation, which was silently ignored by Odoo. This included updating the root cause in _create_test_concept_group and 17 test occurrences.
  • Odoo 19 Compliance: Migrated all old-style tuple commands (e.g., (4, id), (6, 0, [ids])) to the Odoo 19 Command API (e.g., Command.link(id), Command.set([ids])) across 17 test occurrences and documentation examples.
  • Documentation Standardization: Standardized documentation to consistently use the r prefix for registrant symbols (replacing me in 66 locations) and _id field suffixes (53 occurrences across docs and docstrings).
  • Relationship Field Correction: Corrected phantom relationship_type field references to relationship_type_id in 8 doc/docstring locations and added notes clarifying that is_head() requires a deployment-defined code field.
  • Improved Error Messages: Enhanced translator error messages with specific "how to fix" guidance for 14 different error paths, making debugging easier.
  • New QA UI Testing Guide: Added a comprehensive QA UI testing guide with 10 detailed test scenarios covering installation, concept groups, CEL expression validation, security, local codes, and handling empty/missing groups.
  • Maintainers List: Added a maintainers list to the module's manifest file.
Changelog
  • spp_cel_domain/tests/common.py
    • Updated _create_test_concept_group to use label instead of display_name.
    • Migrated list operations to Odoo 19 Command API.
  • spp_cel_vocabulary/README.md
    • Added a note about r prefix standardization.
    • Updated CEL examples to use r prefix and _id suffixes.
    • Changed 'Display name' to 'Label' in code resolution description.
    • Updated configuration section for concept groups.
    • Expanded directory structure description.
    • Updated testing instructions.
  • spp_cel_vocabulary/README.rst
    • Updated CEL examples to use _id suffixes and and operator.
    • Added a comprehensive UI Testing Guide.
  • spp_cel_vocabulary/USAGE.md
    • Added a note about r prefix standardization.
    • Updated quick reference table with _id suffixes and head() function.
    • Added 'When to Use Which Function' decision guide.
    • Updated examples to use r prefix and _id suffixes.
    • Added notes about is_head() vs head() distinction.
    • Updated best practices and troubleshooting sections.
  • spp_cel_vocabulary/manifest.py
    • Added maintainers list to the module manifest.
  • spp_cel_vocabulary/data/README.md
    • Updated UI path for concept groups.
    • Added a note about concept group XML IDs.
    • Updated Python example to use Command API and search by name.
    • Migrated XML examples to use Command.link.
  • spp_cel_vocabulary/data/concept_groups.xml
    • Updated comment to reflect Command.link usage for adding codes.
  • spp_cel_vocabulary/models/cel_vocabulary_translator.py
    • Improved warning messages with guidance for field resolution, group not found, and empty group scenarios.
    • Updated docstrings to reflect _id suffixes.
  • spp_cel_vocabulary/readme/DESCRIPTION.md
    • Updated CEL examples to use _id suffixes and and operator.
  • spp_cel_vocabulary/readme/USAGE.md
    • Added a new comprehensive UI Testing Guide.
  • spp_cel_vocabulary/services/cel_vocabulary_functions.py
    • Updated docstrings for various CEL functions to use _id suffixes.
    • Added a note clarifying is_head() vs head() behavior.
    • Added sudo() justification comment to the head function.
  • spp_cel_vocabulary/static/description/index.html
    • Updated CEL examples to use _id suffixes and and operator.
    • Integrated the new UI Testing Guide content.
  • spp_cel_vocabulary/tests/test_cel_vocabulary.py
    • Migrated code addition to concept groups to use Command.link.
    • Updated _create_test_concept_group calls to use label instead of display_name.
  • spp_cel_vocabulary/tests/test_init_and_coverage.py
    • Migrated list operations to Odoo 19 Command API.
    • Updated _create_test_concept_group calls to use label instead of display_name.
  • spp_cel_vocabulary/tests/test_vocabulary_cache.py
    • Updated _create_test_concept_group calls to use label instead of display_name.
    • Migrated code addition to concept groups to use Command.link.
  • spp_cel_vocabulary/tests/test_vocabulary_in_exists.py
    • Updated _create_test_concept_group calls to use label instead of display_name.
    • Migrated code addition to concept groups to use Command.link.
Activity
  • The pull request is new and has no human activity yet.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

@codecov
Copy link

codecov bot commented Mar 13, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 69.96%. Comparing base (9c2376e) to head (00919a9).
⚠️ Report is 4 commits behind head on 19.0.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             19.0     #106      +/-   ##
==========================================
- Coverage   71.17%   69.96%   -1.21%     
==========================================
  Files         704      738      +34     
  Lines       38554    44024    +5470     
==========================================
+ Hits        27439    30802    +3363     
- Misses      11115    13222    +2107     
Flag Coverage Δ
spp_analytics 86.64% <ø> (ø)
spp_api_v2 79.96% <ø> (ø)
spp_api_v2_change_request 60.29% <ø> (ø)
spp_api_v2_cycles 71.12% <ø> (ø)
spp_api_v2_data 64.41% <ø> (ø)
spp_api_v2_entitlements 70.19% <ø> (ø)
spp_api_v2_gis 71.52% <ø> (ø)
spp_api_v2_products 66.27% <ø> (ø)
spp_api_v2_service_points 70.94% <ø> (ø)
spp_api_v2_simulation 71.12% <ø> (ø)
spp_api_v2_vocabulary 57.26% <ø> (ø)
spp_approval 50.29% <ø> (ø)
spp_audit 64.19% <ø> (?)
spp_base_common 90.26% <ø> (ø)
spp_case_cel 89.01% <ø> (ø)
spp_case_entitlements 97.61% <ø> (ø)
spp_case_programs 97.14% <ø> (ø)
spp_cel_domain 61.06% <ø> (?)
spp_programs 45.51% <ø> (ø)
spp_security 66.66% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
spp_cel_vocabulary/__manifest__.py 0.00% <ø> (ø)
...cel_vocabulary/models/cel_vocabulary_translator.py 95.23% <ø> (-0.29%) ⬇️
...el_vocabulary/services/cel_vocabulary_functions.py 94.11% <ø> (ø)

... and 34 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request is a significant step towards a stable release of spp_cel_vocabulary. It successfully addresses several key areas: fixing a bug in test data creation by replacing display_name with label, migrating all test and data files to the Odoo 19 Command API, and standardizing documentation across the board. The documentation has been greatly improved with consistent field naming (_id suffixes, r prefix), clearer explanations, and the addition of a comprehensive UI testing guide. The improved error messages in the translator will also be very helpful for developers. My only suggestion for improvement is to address the content duplication between the new UI testing guide in README.rst and readme/USAGE.md to enhance long-term maintainability.

Comment on lines +132 to +136
Usage
=====

UI Testing Guide
----------------

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The new 'UI Testing Guide' section seems to duplicate the content from the newly added spp_cel_vocabulary/readme/USAGE.md file. While the formatting is different (RST vs Markdown), maintaining the same content in two places can lead to inconsistencies in the future. To improve maintainability, consider generating one file from the other as part of your documentation build process, or using a tool that allows including Markdown in RST files if your documentation toolchain supports it.

@gonzalesedwin1123 gonzalesedwin1123 marked this pull request as ready for review March 13, 2026 10:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant