[19.0] [MIG] Migrate queue addons to Odoo 19: API/ORM updates, harness‑safe tests, upstream‑like cron behavior

[tishmen]

[19.0] Migrate queue addons to Odoo 19: API/ORM updates, harness‑safe tests, upstream‑like cron behavior

• Impacted versions: 19.0
• Addons: base_import_async, queue_job, queue_job_batch, queue_job_cron, queue_job_cron_jobrunner, queue_job_subscribe, test_queue_job, test_queue_job_batch

Motivation

Bring the queue suite to Odoo 19.0 with minimal functional changes, align views/data with v19 expectations, and make tests deterministic under the 19.0 harness (commit/rollback restrictions + cron locks).

Summary of Changes

1) Core API/ORM migrations (19.0)

• Use env.cr and tools.sql helpers:
  • queue_job: replace self._cr, create idempotent indexes via odoo.tools.sql.create_index + index_exists.
• Constraints and fields:
  • queue_job_channel: migrate _sql_constraints to models.Constraint UNIQUE(complete_name).
  • queue_job: use tools.misc.SENTINEL; replace isinstance(A|B) with tuples.
• Base import API:
  • base_import_async: drop deprecated @api.returns, return recordset directly.
• Groups and security:
  • Replace res.groups users -> user_ids with Command.link in XML.
  • Replace deprecated category_id with privilege_id; add privilege “Job Queue”.
• Views/search RNG updates:
  • Remove search <group expand>; inline group-by filters.
  • Drop widget=selection on company_id; align with core.
  • Drop python date filters in search.
• Config and deps:
  • queue_job: v19‑safe config fallback for jobrunner.
  • queue_job: restore dependency on base_sparse_field where Serialized is used.
• Minor warning fix:
  • queue_job: _compute_dependency_graph uses _read_group with 'id:recordset' to silence a 19.0 ORM warning (no behavior change). Added a one‑line comment.

2) Cron module behavior + tests (19.0 harness)

• Module (queue_job_cron):
  • Keep upstream‑like behavior: use identity_exact for no_parallel dedup; no write guard for channel_id; no pre‑enqueue duplicate checks.
• Tests (queue_job_cron):
  • Use enter_registry_test_mode() around method_direct_trigger for safe cron execution.
  • Perform ir.cron writes and core ir.cron._callback in separate cursors and assert within those cursors (commit/rollback forbidden on main test cursor; avoid serialization failures).
  • Ensure tests which enqueue in a separate cursor clean up committed jobs to avoid leakage into later modules (e.g., jobrunner acquisition tests).
  • Add comments explaining deviations from upstream and why they’re needed in 19.0.

3) Jobrunner compatibility

• No changes to acquisition SQL (ORDER BY priority, date_created … SKIP LOCKED) — upstream logic is correct.
• Prevent interference by cleaning up committed jobs from queue_job_cron tests as noted above.

4) Pre-commit

• Ran pre‑commit; refreshed generated README.rst and addon static description HTML files.

Validation

• pre-commit: clean
• Tests (focused):
  • queue_job_cron: pass under 19.0 harness
  • queue_job_cron_jobrunner: acquisition order and processing validated; no cross‑module leakage after test cleanup

Notes

• Functional changes are kept to a minimum; cron behavior is aligned to upstream.
• Test changes are narrowly scoped to 19.0’s test harness constraints (commit/rollback & locking).
• The minor warning fix in queue_job has no behavioral impact.

Checklist

• ORM/API updated for 19.0
• Tests deterministic under 19.0
• No broad refactors or formatting-only churn
• Pre‑commit OK

[sbidoul]

Thank you @tishmen !

Ideally we'd need an agreement between you and @richard-willdooit to know which PR we start from. #832 (comment)

Regarding this one, in order to facilitate review and follow recommended OCA practice, could you split it into one PR per addon? A first one with queue_job and test_queue_job which go together, and then one for each other module.

[tishmen]

@jaredkipe Migration is done, all checks are passing, waiting for code review and merge

[tishmen]

@sbidoul will update ASAP. Regarding @richard-willdooit PR, i see that the checks are not passing. @richard-willdooit can you elaborate?

[tishmen]

Hi again @sbidoul.

I’ve closed my previous PRs to avoid noise while we align on the review flow. I’m ready to re-open them split per addon as requested, starting with a base PR for queue_job + test_queue_job, then one PR per remaining addon.

One note on CI: dependent addons import queue_job and/or its tests, so their CI will be red until the base PR merges. Locally (fresh DB per run) I validated:

queue_job + test_queue_job: all green (169)
queue_job_cron: all green (7)
queue_job_subscribe: all green (4)
queue_job_cron_jobrunner: installs OK (no tests)
base_import_async: blocked locally by missing core base_import; CI should cover it
queue_job_batch: tests skipped in isolation; they pass once queue_job is present
How would you like me to proceed?

Option A: I open the base PR now and the others as Draft with “Depends on base PR”; let CI be red on dependents until the base merges, then I rebase to turn them green.
Option B: I temporarily include the queue_job diff in each dependent PR to keep CI green, then rebase them back after the base merges.
Option C: I follow any OCA-preferred pattern you recommend for cross-PR dependencies.
I’m also happy to start from whichever base (mine vs @richard-willdooit’s) you prefer. Once you confirm the approach, I’ll open the fresh PRs accordingly.

[sbidoul]

@tishmen You should be able to reference the unmerged queue_job base PR from the others, using this procedure: https://github.com/OCA/maintainer-tools/wiki/Use-temporary-reference(s)-to-another-pull-request(s)

I have not reviewed either PR so I can't say if one is better than the other so I won't decide :) My only concern is to avoid frustration. Since at first sight @tishmen is more advanced it might make sense to add @richard-willdooit as co-author of some commits, but your choice, really.

[richard-willdooit]

@tishmen @sbidoul

I am not precious. Just frustrated at the fact that I can't sort out why the pre-commit seems to be using the wrong linter.

In any case, I just want a working version. Mine has just been the ticking along for the last 6 months of keeping it going, and I was not even doing the tests - it was for us and 18.3 and master tracking only, really. I only looked at the tests and pre-commit in the last few days.

I will happily close mine and do not need any co-author acknowledgement.

[richard-willdooit]

@tishmen I will say, I am getting in the habit of using Command to replace the tuple notations....

[tishmen]

Thanks @richard-willdooit - I really appreciate the work you’ve put into keeping queue moving and your openness to my PR. I also believe using fields.Command instead of the old tuple notation is a step forward for Odoo, the (0, 0, …), (6, 0, …) style always felt like magic numbers to me. I’ll adopt Command consistently in the changes and follow-ups.

[tishmen]

@sbidoul Thanks for the link, I should get into the habit of reading maintainer-tools more often. I'll make sure to issue the new PR's by the end of today CET. Will close this PR and will notify you of the new ones as soon as they are up.

[tishmen]

@sbidoul Quick update — I’ve split the 19.0 migration into separate PRs and set up temporary refs for CI/runboat as per maintainer-tools. All are ready for code review and functional testing:

Base:

• [19.0] [MIG] queue_job: migrate + tests #840 - queue_job + test_queue_job
• [19.0] [MIG] base_import_async: migrate #841 - base_import_async
• [19.0] [MIG] queue_job_batch: migrate + tests #842 - queue_job_batch + test_queue_job_batch
• [19.0] [MIG] queue_job_cron: migrate #843 - queue_job_cron
• [19.0] [MIG] queue_job_cron_jobrunner: migrate #844 - queue_job_cron_jobrunner
• [19.0] [MIG] queue_job_subscribe: migrate #845 - queue_job_subscribe

Notes:

The “Detect unreleased dependencies” job is expected to fail due to the temporary references in test-requirements.txt; other checks (pre-commit, OCB tests, runboat build) are green for review and testing.

I’m ready to remove the temporary references and re-run pre-commit as soon as the base PR (840) merges, so CI turns fully green.

Thanks again to @richard-willdooit for your initial effort!

[richard-willdooit]

@tishmen @sbidoul Any progress on getting this approved and merged - I would prefer not to add this branch in my submodules...

[tishmen]

@richard-willdooit Please see: #840. I am planning on fixing the last open code review issues later on today.

[sbidoul]

Can we close this one?

[tishmen]

@richard-willdooit Quick update on #840.

All outstanding review items are addressed; pre-commit passes and CI is green. We’ll continue the migration work here.
When you have a moment, could you take another look and compare with your PR/branch to spot anything I might have missed? Feedback or blockers welcome. Thanks!

[tishmen]

Can we close this one?

Done.