[WIP] FEAT! Make queue_job dependencies optional

[ecino]

• NEW module queue_job_sh_safe that will safely use queue_jobs when available and fallback to an alternate mechanism with ir_cron in case the module is not installed.
• This is useful for Nordic using odoo.sh on which queue jobs are prohibited and not optimal for the infrastructure

[gemini-code-assist]

Code Review

This pull request introduces the queue_job_sh_safe module, which abstracts the OCA queue_job module to provide a fallback database-backed queue processed via a cron job when queue_job is not installed. This allows compatibility between dedicated environments and odoo.sh. Other modules are updated to depend on this new module and use the with_delay_sh method. Feedback on the changes highlights a critical transaction handling issue where exceptions caught inside the context manager could lead to partial commits, a performance bottleneck from instantiating a new registry with Registry.new(), and another bottleneck from querying ir.module.module on every delay call. Additionally, suggestions were made to use sudo() to prevent potential access errors for regular users and to dynamically filter unsupported fields during record creation.

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.

[greptile-apps]

Confidence Score: 1/5

The queue fallback has multiple runtime paths that can fail or run work with the wrong execution context.

• No-split fallback calls can crash before creating replacement jobs.
• Chained replacement jobs can update the parent while leaving the child pending.
• Cron execution does not switch to the stored enqueuing user.
• partner_communication still reaches the queue-job-only API despite no longer depending on that module.

queue_job_sh_safe/models/base.py, queue_job_sh_safe/models/queue_job_replacement.py, and partner_communication/manifest.py

T-Rex Logs

What T-Rex did

• Inspected the pre-run log queue-fallback-01-before.log, which shows queue_job_present: false, a cron trigger, and two queue.job.replacement jobs in pending state for IDs [10] and [20] after with_delay_sh('safe_increment', 5, split=1).
• Inspected the post-run log queue-fallback-02-after.log, which shows both replacement jobs processed by cron_run_jobs and now in done state with job_result values captured.
• Validated the verification command exited with code 0.

_{Ran code and verified through T-Rex}

_{Reviews (3): Last reviewed commit: "[WIP] FEAT! Make queue_job dependencies ..." | Re-trigger Greptile}

[greptile-apps]

Executable Jobs Remain Editable

The new access group still has full create and write access to rows that cron_run_jobs() executes from stored res_model, res_ids, job_function, and job_args. When an operator is assigned this UI group, they can create or edit a replacement job that the cron later runs as stored executable work, so the dispatch path still needs a read-only/operator split or an allowlist tied to jobs created by with_delay_sh.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Old Queue API Still Runs

This manifest no longer installs queue_job, but the automated-action code in partner_communication/models/ir_actions.py still searches self.env["queue.job"] and calls self.with_delay(...). In the intended no-queue_job deployment, triggering that action raises at runtime instead of using the replacement queue.

[greptile-apps]

Unsplit Jobs Crash Immediately

When a caller omits split, split defaults to 0, so this fallback builds range(0, len(self), 0) and raises ValueError before creating any replacement job. The migrated S2B button calls with_delay_sh("generate_letters_job", identity_key=...) without split, so no-queue_job deployments show a traceback and never queue the letter generation.

[greptile-apps]

Blocked Child Rewrites Parent

When a chained child is pending and its parent is failed or still not done, this loop walks job_new_env to the parent but still executes the original child's stored method. The cron then writes processing and done onto the parent with the child's result while leaving the child pending, so the GMC chained batches can revive a failed predecessor and rerun the child on the next cron cycle.

[greptile-apps]

Queued Work Runs As Admin

with_delay_sh stores the enqueuing user_id, but cron dispatch browses records and calls the job method in the cron environment instead of switching to that user. In no-queue_job deployments, queued methods that normally depend on record rules or env.user now run as the cron/admin user and can perform work outside the original caller's permissions.

[greptile-apps]

Queue API Still Required

This manifest no longer installs queue_job, but partner_communication still has direct with_delay() callers in its models and wizard code. On the intended Odoo.sh setup with only queue_job_sh_safe, those workflows raise AttributeError instead of using the fallback queue.