[19.0] [MIG] Migrate queue addons to Odoo 19: API/ORM updates, harness‑safe tests, upstream‑like cron behavior #833
Conversation
…alformed manifest in queue_job_batch (duplicate keys/structure)\n- Set installable=True across queue addons (incl. tests)\n- queue_job: drop legacy base_sparse_field dep, fix assets path\n- No functional code changes, only manifests
…d used by Serialized field)
…lds.py: import SENTINEL, update Json field defaults\n- fields.py/job.py/queue_job_function.py: replace (a | b) with (a, b) in isinstance\n- Add top-level AGENTS.md documenting workflow and conventions
…ed config.misc; merge flat odoo.conf options into queue_job_config\n- Preserve precedence: env vars > server_environment > flat options\n- Add comments for community setups
…Add res.groups.privilege 'Job Queue'\n- queue_job, queue_job_batch: set group privilege_id instead of category_id\n- Keeps ir.module.category for module classification, but no longer used by groups
…nt\n\n- Replace deprecated _sql_constraints with models.Constraint UNIQUE(complete_name)\n- Short note inline about Odoo 19 change
…self._cr deprecated in 19.0)\n- Use odoo.tools.sql.create_index with index_exists for idempotent index creation\n- Inline comment noting Odoo 19 change
…L\n\n- res.groups no longer has 'users' field\n- Use 'user_ids' with Command.link(...) as per core base_groups.xml
…th core search views (Many2one is fine without widget)\n- Minor inline comment for v19
…ta)\n\n- These constructs are not used in core views in v19\n- Users can filter dates via searchpanel or saved filters
…lters\n\n- v19 RNG: no 'group' with expand attr in <search>\n- Place group-by filters directly with domain=[] and context={'group_by': ...}
…plain RNG restriction on Python in search domains\n- Suggest custom actions or saved filters for quick ranges
…appers; inline group-by filters with domain=[]\n- Drop widget=selection on company_id fields in search\n- Add brief comments explaining v19 change
… Odoo 19 api module no longer provides 'returns'\n- Function returns an ir.attachment recordset directly
…se now inherits doctest.DocTestCase and odoo.tests.case.TestCase only
- queue_job (functional): use group_ids in subscriber domain - tests: migrate groups_id -> group_ids where applicable - queue_job_cron/tests: run _callback in separate cursor; assert partner creation inside cursor; assert returned Job when queued; drop brittle queue.job count assert - tests: Odoo 19 tweaks (HttpCase cookie, doctest flags)
- base: replace removed api.propagate with update_wrapper + decorator metadata carryover - test_queue_job.autovacuum: call model.autovacuum() directly to avoid cron separate-cursor visibility issues - test_queue_job: use res.groups.user_ids (Odoo 19) instead of users - queue_job_cron test: keep assertions cursor-safe; logging retained - metapackage: keep version current
- We already assert partner count increase within the separate cursor where ir.cron._callback commits; main-env equality check can be flaky under Odoo 19 test transaction isolation. Cache refresh remains.
- tests(queue_job_cron): use enter_registry_test_mode for direct triggers; run ir.cron writes and callbacks in fresh cursors; clean up committed jobs to avoid cross-module leakage; add comments explaining deviations from upstream. - models(queue_job_cron.ir_cron): revert write guard and pre-enqueue duplicate checks; use identity_exact for no_parallel dedup; remove debug logging. - models(queue_job.queue_job): use _read_group with 'id:recordset' to avoid ORM warning; add 1-line comment. Functional changes in ir_cron and tests; minor warning fix in queue_job.
- Add setUpClass user in test classes\n- Replace base.user_demo references\n- Remove test demo XML; revert manifest demo\n- Scope: tests only (no functional changes)
|
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 |
|
@jaredkipe Migration is done, all checks are passing, waiting for code review and merge |
|
@sbidoul will update ASAP. Regarding @richard-willdooit PR, i see that the checks are not passing. @richard-willdooit can you elaborate? |
|
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) 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. |
|
@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. |
|
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. |
|
@tishmen I will say, I am getting in the habit of using Command to replace the tuple notations.... |
|
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. |
|
@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. |
|
@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:
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 Please see: #840. I am planning on fixing the last open code review issues later on today. |
|
Can we close this one? |
|
@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. |
Done. |
[19.0] Migrate queue addons to Odoo 19: API/ORM updates, harness‑safe tests, upstream‑like cron behavior
base_import_async,queue_job,queue_job_batch,queue_job_cron,queue_job_cron_jobrunner,queue_job_subscribe,test_queue_job,test_queue_job_batchMotivation
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)
queue_job: replaceself._cr, create idempotent indexes viaodoo.tools.sql.create_index+index_exists.queue_job_channel: migrate_sql_constraintstomodels.Constraint UNIQUE(complete_name).queue_job: usetools.misc.SENTINEL; replaceisinstance(A|B)with tuples.base_import_async: drop deprecated@api.returns, return recordset directly.res.groupsusers->user_idswithCommand.linkin XML.category_idwithprivilege_id; add privilege “Job Queue”.<group expand>; inline group-by filters.widget=selectiononcompany_id; align with core.queue_job: v19‑safe config fallback for jobrunner.queue_job: restore dependency onbase_sparse_fieldwhereSerializedis used.queue_job:_compute_dependency_graphuses_read_groupwith'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)
queue_job_cron):identity_exactfor no_parallel dedup; no write guard forchannel_id; no pre‑enqueue duplicate checks.queue_job_cron):enter_registry_test_mode()aroundmethod_direct_triggerfor safe cron execution.ir.cronwrites and coreir.cron._callbackin separate cursors and assert within those cursors (commit/rollback forbidden on main test cursor; avoid serialization failures).3) Jobrunner compatibility
ORDER BY priority, date_created … SKIP LOCKED) — upstream logic is correct.queue_job_crontests as noted above.4) Pre-commit
README.rstand addon static description HTML files.Validation
queue_job_cron: pass under 19.0 harnessqueue_job_cron_jobrunner: acquisition order and processing validated; no cross‑module leakage after test cleanupNotes
queue_jobhas no behavioral impact.Checklist