Skip to content

Conversation

@tishmen
Copy link

@tishmen tishmen commented Oct 1, 2025

Scope

  • queue_job, test_queue_job only

Summary

  • Migrate to Odoo 19 using the working feature branch code.
  • Tests create their own users (no demo data), context handling aligned with 19.0.
  • Asset paths are relative under web.assets_backend.

Pre-commit

  • Verified locally; no additional changes applied here to keep parity with the feature branch.

Tests

  • Command:
    ./odoo/odoo-bin -c odoo.conf -d odoo_queue_pr_queue_job_base_001 --init queue_job,test_queue_job --test-tags="/queue_job,/test_queue_job" --stop-after-init
  • Result: all tests green locally.

Milan Topuzov added 11 commits October 1, 2025 18:01
Scope: queue_job, test_queue_job only
…config.yaml excluded-addons update\n- Prettier reformat XML/JS/SCSS and pyproject changes\n- Fix ruff UP031 in controllers and job repr/exception
…._ in controller\n- Use self.env._ + lazy %% formatting in models\n- Paginate channel search in autovacuum\n- Avoid raise in unlink; skip root channel\n- Fix tests: avoid search([]) and correct pylint disable id
@sbidoul
Copy link
Member

sbidoul commented Oct 1, 2025

/ocabot migration queue_job

@OCA-git-bot OCA-git-bot added this to the 19.0 milestone Oct 1, 2025
@OCA-git-bot OCA-git-bot mentioned this pull request Oct 1, 2025
8 tasks
@sbidoul
Copy link
Member

sbidoul commented Oct 1, 2025

/ocabot migration test_queue_job

Copy link

@hoangtrann hoangtrann left a comment

Choose a reason for hiding this comment

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

appreciate all the work you done here! please review the comments since I notice many weird comments and many changes should be in another PR instead of a migration one

Copy link

@Reyes4711-S73 Reyes4711-S73 left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link

@omarsyscoon omarsyscoon left a comment

Choose a reason for hiding this comment

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

LGTM

Milan Topuzov and others added 5 commits November 10, 2025 23:05
- Remove extra space before "model" in value_json for test_decoder_recordset_list_without_user
- Align expected string with encoder output to avoid whitespace-only assertion failures
- Scope: tests only; no functional changes

Co-authored-by: Pieter Paulussen <[email protected]>
@tishmen
Copy link
Author

tishmen commented Nov 10, 2025

@tishmen Please take a look at this commit. I would create a PR for your branch, but for some reason I couldn't do it.

It's a fix related to a change in db_name parsing from config (src)

Handled in update.

@tishmen
Copy link
Author

tishmen commented Nov 10, 2025

@tishmen jobs_groups = self.env["queue.job"].read_group(

I get: DeprecationWarning: Since 19.0, read_group is deprecated. Please use _read_group might be good to get rid of this?

Handled in update.

@tishmen
Copy link
Author

tishmen commented Nov 10, 2025

@tishmen i have this when i initialise new db,

DR-ODOO  | 2025-11-04 12:13:16,520 1 DEBUG ? odoo.addons.queue_job.jobrunner.runner: initializing database connections 
DR-ODOO  | 2025-11-04 12:13:16,520 1 ERROR ? odoo.addons.queue_job.jobrunner.runner: exception: sleeping 5s and retrying 
DR-ODOO  | Traceback (most recent call last):
DR-ODOO  |   File "/mnt/odoo/external_addons/queue_job/jobrunner/runner.py", line 597, in run
DR-ODOO  |     self.initialize_databases()
DR-ODOO  |   File "/mnt/odoo/external_addons/queue_job/jobrunner/runner.py", line 492, in initialize_databases
DR-ODOO  |     for db_name in sorted(self.get_db_names()):
DR-ODOO  |   File "/mnt/odoo/external_addons/queue_job/jobrunner/runner.py", line 476, in get_db_names
DR-ODOO  |     db_names = config["db_name"].split(",")
DR-ODOO  | AttributeError: 'list' object has no attribute 'split'
DR-ODOO  | 2025-11-04 12:13:17,230 1 INFO 19_controller3 odoo.modules.loading: loading base/data/report_paperformat_data.xml 

Handled in update.

@tishmen
Copy link
Author

tishmen commented Nov 10, 2025

@tishmen i have this when i initialise new db,

DR-ODOO  | 2025-11-04 12:13:16,520 1 DEBUG ? odoo.addons.queue_job.jobrunner.runner: initializing database connections 
DR-ODOO  | 2025-11-04 12:13:16,520 1 ERROR ? odoo.addons.queue_job.jobrunner.runner: exception: sleeping 5s and retrying 
DR-ODOO  | Traceback (most recent call last):
DR-ODOO  |   File "/mnt/odoo/external_addons/queue_job/jobrunner/runner.py", line 597, in run
DR-ODOO  |     self.initialize_databases()
DR-ODOO  |   File "/mnt/odoo/external_addons/queue_job/jobrunner/runner.py", line 492, in initialize_databases
DR-ODOO  |     for db_name in sorted(self.get_db_names()):
DR-ODOO  |   File "/mnt/odoo/external_addons/queue_job/jobrunner/runner.py", line 476, in get_db_names
DR-ODOO  |     db_names = config["db_name"].split(",")
DR-ODOO  | AttributeError: 'list' object has no attribute 'split'
DR-ODOO  | 2025-11-04 12:13:17,230 1 INFO 19_controller3 odoo.modules.loading: loading base/data/report_paperformat_data.xml 

I have this issue as well, are you on Odoo.sh?

no i was testing locally,

temporary i solved by the following jobrunner/runner.py L#474


    def get_db_names(self):
        if config["db_name"]:
            if isinstance(config["db_name"], list):
                return config["db_name"]
            return config["db_name"].split(",")
        return odoo.service.db.list_dbs(True)

I am going to use a similar solution to yours to handle this and not the PR that was suggested above. Thanks.

@tishmen
Copy link
Author

tishmen commented Nov 10, 2025

@tishmen Thanks for your effort on this. On the whole, this PR does the trick, but there are a lot of additional changes that are not essential to the module migration. In my opinion, you will get faster approvals if you slim down the changes to the bare minimum given the complexity of this module.

If you want to keep the translations in this PR, can we go one step further and use positional arguments for all translated string variables? This results in more flexibility for other languages during translating.

On the refactoring of the tests to remove the reliance on the demo_user, I would beg to differ. Unittests should rely on the presence of the demo data, just as the core does.

Finally, I would like to stress the following issue that I encountered during a local test with your code: #840 (comment) The jobrunner does not seem to enqueue AND process the queue jobs when running is preforked server configuration. This issue should be addressed first.

Thanks for the review. I’ve updated the PR to use positional arguments for all translated strings to improve i18n flexibility. Regarding the tests: in Odoo 19, demo data isn’t loaded by default during test runs, which caused failures when relying on the demo user, so the tests create a user explicitly to stay deterministic

@aisopuro
Copy link

For extra context, Odoo indeed changed the default for loading demo data in odoo/odoo@eeac3d4.

They even explicitly state in the commit message:

In testing we should not rely on demo data, but instead data constructed during the test.

I at least would interpret this to mean that part of migrating code to 19 is to rewrite/refactor tests so they no longer depend on demo data.

Copy link

@mostafabarmshory mostafabarmshory left a comment

Choose a reason for hiding this comment

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

@tishmen
@sbidoul
@PieterPaulussen

Please review and approve this PR. We need this branch, and progress is blocked by non-critical issues.

Comment on lines 46 to 47
"company_ids": [(6, 0, [main_company.id])],
"group_ids": [(6, 0, [group_user.id])],

Choose a reason for hiding this comment

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

@tishmen
@ sbidoul

Please review and approve this PR. We need this branch, and progress is blocked by non-critical issues.

Copy link
Contributor

@PieterPaulussen PieterPaulussen left a comment

Choose a reason for hiding this comment

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

Most of my feedback seems to be either ignored or resolved.

@OCA-git-bot
Copy link
Contributor

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

@Robrechtc
Copy link

@pedrobaeza Sorry for tagging you here again but you are the only one that I know has merge rights. Would you mind merging this? Thanks in advance.

@pedrobaeza
Copy link
Member

Hi, I'm afraid I don't know too much this module, so one PSC like @guewen, @simahawk or @sbidoul should check that it's correct and then merge.

@Robrechtc
Copy link

Hi, I'm afraid I don't know too much this module, so one PSC like @guewen, @simahawk or @sbidoul should check that it's correct and then merge.

Thanks for tagging them.

@sbidoul
Copy link
Member

sbidoul commented Nov 19, 2025

I plan to read the latest comments and re-review soon(ish). Maybe next week.

It the meantime, nothing prevents using it, and reporting further issues if any.

@richard-willdooit
Copy link

@tishmen Well done - all I can really say is, that I'm glad my PR was superseded - 😜

Overall, I really think we should be getting these PRs for migrations through as efficiently as possible. I know everyone has their opinions, and where code has been touched or altered, it is great to aim for perfection, but if the changes are not wrong, if they are not regressive, then there should be no obligation to "improve" during a migration. Nice if it does, but it should not be obligatory.

After watching this unfold, I will be VERY uninclined to offer a module migration, as my objective will be to get the module across as is, and correct, not suddenly inheriting everyone else's wishlists...

Of course, this does not mean dismissing anyone's reviews or input without due and proper consideration, but the end game of a migration PR seems different for different people....

Copy link
Member

@sbidoul sbidoul left a comment

Choose a reason for hiding this comment

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

Thanks, this looks great now.

A few last minor things, and one more important one for performance of graph handling in the read_group rewrite.

if db_name_opt:
if isinstance(db_name_opt, (list, tuple, set)):
return list(db_name_opt)
return [n for n in str(db_name_opt).split(",") if n]
Copy link
Member

Choose a reason for hiding this comment

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

Does any one know in which case config["db_name"] is not a list? As I read odoo/tools/config.py it seems it's always a list, since it is parsed with _check_comma.

Comment on lines +272 to +273
# Note: no local _patch_method helper; if needed, patch methods
# directly in _register_hook as shown above.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
# Note: no local _patch_method helper; if needed, patch methods
# directly in _register_hook as shown above.

Nit: this comment is not really helpful outside the migration PR.

Comment on lines 132 to 133
index_1 = "queue_job_identity_key_state_partial_index"
index_2 = "queue_job_channel_date_done_date_created_index"
Copy link
Member

Choose a reason for hiding this comment

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

nit: these two variables are not helpful, they could be inlined

ids_per_graph_uuid = {
group["graph_uuid"]: group["ids"] for group in jobs_groups
}
uuids = [uuid for uuid in self.mapped("graph_uuid") if uuid]
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
uuids = [uuid for uuid in self.mapped("graph_uuid") if uuid]
graph_uuids = [uuid for uuid in self.mapped("graph_uuid") if uuid]

To avoid confusion with job uuids.

Comment on lines +160 to +167
rows = self.env["queue.job"]._read_group(
[("graph_uuid", "in", uuids)],
groupby=["graph_uuid"],
aggregates=["id:recordset"],
)
# rows -> list of tuples: (graph_uuid, recordset)
for graph_uuid, recs in rows:
ids_per_graph_uuid[graph_uuid] = recs.ids
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
rows = self.env["queue.job"]._read_group(
[("graph_uuid", "in", uuids)],
groupby=["graph_uuid"],
aggregates=["id:recordset"],
)
# rows -> list of tuples: (graph_uuid, recordset)
for graph_uuid, recs in rows:
ids_per_graph_uuid[graph_uuid] = recs.ids
ids_per_graph_uuid = dict(self.env["queue.job"]._read_group(
[("graph_uuid", "in", graph_uuids)],
groupby=["graph_uuid"],
aggregates=["id:array_agg"],
))

This is simpler and more efficient, as we don't need the recordsets.

Comment on lines +227 to +232
rows = self.env["queue.job"]._read_group(
[("graph_uuid", "in", graph_uuids)],
["graph_uuid"],
["__count"],
)
count_per_graph_uuid = {graph_uuid: cnt for graph_uuid, cnt in rows}
Copy link
Member

Choose a reason for hiding this comment

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

nit, this is probably slightly more efficient than the dict comprehension

Suggested change
rows = self.env["queue.job"]._read_group(
[("graph_uuid", "in", graph_uuids)],
["graph_uuid"],
["__count"],
)
count_per_graph_uuid = {graph_uuid: cnt for graph_uuid, cnt in rows}
count_per_graph_uuid = dict(self.env["queue.job"]._read_group(
[("graph_uuid", "in", graph_uuids)],
groupby=["graph_uuid"],
aggregates=["__count"],
))

@tishmen
Copy link
Author

tishmen commented Nov 26, 2025

@sbidoul I will take care of all of the code review comments this weekend. Thanks for your feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.