T3206-Correct-existing-translation-data

[jordyBSK]

refactor: count only completed translations in stats

• Update nb_translated_letters to filter on translation_status == "done"
• Replace translate_date usage with translate_done for yearly stats
• Add precise @api.depends on translation_status and translate_done
• Ensure counters reflect only completed translations

[gemini-code-assist]

Code Review

This pull request updates the computed fields tracking translated letters to filter by status and date. The reviewer suggests optimizing these computations by replacing the in-memory Python filtering on the One2many field with database-level aggregations using read_group to prevent performance degradation and high memory usage.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Using filtered on a One2many field (translated_letter_ids) loads all associated correspondence records into memory. For translators with a large history of letters, this can cause significant performance degradation and high memory usage. Since this is a stored computed field, it will be recomputed frequently. Using read_group allows Odoo to perform a single optimized SQL aggregation query, which is much faster and avoids loading any records into memory.

    @api.depends("translated_letter_ids.translation_status")
    def _compute_nb_translated_letters(self):
        groups = self.env["correspondence"].read_group(
            [("new_translator_id", "in", self.ids), ("translation_status", "=", "done")],
            ["new_translator_id"],
            ["new_translator_id"]
        )
        mapped_data = {
            g["new_translator_id"][0]: g["new_translator_id_count"]
            for g in groups
            if g["new_translator_id"]
        }
        for translator in self:
            translator.nb_translated_letters = mapped_data.get(translator.id, 0)

[gemini-code-assist]

Filtering the One2many field in Python to count letters for the current year loads all correspondence records into memory. We can optimize this by using read_group with a date range filter on translate_done directly in the database query, which avoids loading records and executes a highly efficient database-level aggregation.

    @api.depends("translated_letter_ids.translation_status", "translated_letter_ids.translate_done")
    def _compute_nb_translated_letters_this_year(self):
        current_year = fields.Datetime.now().year
        groups = self.env["correspondence"].read_group(
            [
                ("new_translator_id", "in", self.ids),
                ("translation_status", "=", "done"),
                ("translate_done", ">=", f"{current_year}-01-01 00:00:00"),
                ("translate_done", "<=", f"{current_year}-12-31 23:59:59"),
            ],
            ["new_translator_id"],
            ["new_translator_id"]
        )
        mapped_data = {
            g["new_translator_id"][0]: g["new_translator_id_count"]
            for g in groups
            if g["new_translator_id"]
        }
        for translator in self:
            translator.nb_translated_letters_this_year = mapped_data.get(translator.id, 0)

[gemini-code-assist]

Similar to the current year computation, filtering the One2many field in Python to count letters for the last year loads all correspondence records into memory. Using read_group with a date range filter on translate_done directly in the database query avoids loading records and executes a highly efficient database-level aggregation.

Suggested change

	@api.depends("translated_letter_ids.translation_status", "translated_letter_ids.translate_done")
	def _compute_nb_translated_letters_last_year(self):
	last_year = fields.Datetime.now().year - 1
	for translator in self:
	translator.nb_translated_letters_last_year = len(
	translator.translated_letter_ids.filtered(
	lambda it: it.translate_date
	and it.translate_date.year == fields.Datetime.now().year - 1
	lambda it: it.translation_status == "done" and
	it.translate_done and
	it.translate_done.year == last_year
	)
	)
	@api.depends("translated_letter_ids.translation_status", "translated_letter_ids.translate_done")
	def _compute_nb_translated_letters_last_year(self):
	last_year = fields.Datetime.now().year - 1
	groups = self.env["correspondence"].read_group(
	[
	("new_translator_id", "in", self.ids),
	("translation_status", "=", "done"),
	("translate_done", ">=", f"{last_year}-01-01 00:00:00"),
	("translate_done", "<=", f"{last_year}-12-31 23:59:59"),
	],
	["new_translator_id"],
	["new_translator_id"]
	)
	mapped_data = {
	g["new_translator_id"][0]: g["new_translator_id_count"]
	for g in groups
	if g["new_translator_id"]
	}
	for translator in self:
	translator.nb_translated_letters_last_year = mapped_data.get(translator.id, 0)

[greptile-apps]

Confidence Score: 5/5

The change is merge-safe based on the focused stats logic and migration refresh.

The updated domains and stored-field dependencies align with the stated goal of counting only completed translations, and no issues were identified in the changed files.

T-Rex Logs

What T-Rex did

• T-Rex captured translation stats before and after from the same executable run to verify counter behavior.
• T-Rex captured depends recompute before/after states showing status and date mutations in the same run.
• T-Rex captured migration recompute path before/after states from the same executable run.

_{Ran code and verified through T-Rex}

_{Reviews (6): Last reviewed commit: "feat: add the migration file to calculat..." | Re-trigger Greptile}

[NoeBerdoz]

Thanks for your work on this! The refactor direction looks great, however, there is a key issue to fix before we can merge your proposal.

You changed the compute method, but not the existing data in the database:
Because these fields have store=True, Odoo will not automatically recompute the old rows during an upgrade. It will just keep reading the old, incorrect values. To fix this and meet the ticket requirements, we need a migration script to backfill the data and force a recompute for existing records.

Let me know if you need help setting up the migration script!

[NoeBerdoz]

Looks like a code duplication to remove

Suggested change

	@api.depends(
	"translated_letter_ids.translation_status",
	"translated_letter_ids.translate_done",
	)
	@api.depends(
	"translated_letter_ids.translation_status",
	"translated_letter_ids.translate_done",
	)
	@api.depends(
	"translated_letter_ids.translation_status",
	"translated_letter_ids.translate_done",
	)

[greptile-apps]

Queued Counters Stay Stale

When this migration runs, env.add_to_compute() only queues these stored fields for recomputation; flush_model() flushes cached values but does not drain the recompute queue. Existing translation.user rows can keep their old inflated counters after upgrade, so the dashboard API continues to return the pre-change totals until another write happens to trigger a recompute.