[FIX] integration_queue_job: repoint default_env to superuser in runjob

[o-diatlenko]

Problem

/queue_job/runjob is declared auth="none". In Odoo 19, _auth_method_none sets transaction.default_env to an environment with uid=None. The controller then does

env = http.request.env(user=SUPERUSER_ID)

which only builds a local environment, so transaction.default_env keeps no user. The job itself runs with its own user and company. But every flush that goes through Transaction.flush(), meaning every flushing cr.savepoint() and cr.commit() inside the job, recomputes stored fields through that uid=None environment, with an empty env.user and env.company.id == False.

This broke Shopify order imports for us (integration_queue_job 19.0.1.0.9 / 19.0.1.0.10). create_order_from_input hits an unmapped product, and _import_external_product opens a cr.savepoint(). The pending sale.order recompute then runs in that environment, and account_followup builds its query with company_id=False:

psycopg2.errors.UndefinedFunction: operator does not exist: integer = boolean
... AND next_ful.company_id = false

OCA queue_job had the same bug, where it showed up in Enterprise core as account_accountant._compute_signing_user raising "Expected singleton: res.users()": OCA/queue#922.

Fix

Same as the upstream OCA fix (OCA/queue#923, commit 415420f):

- env = http.request.env(user=SUPERUSER_ID)
+ http.request.update_env(user=SUPERUSER_ID)
+ env = http.request.env

Test

tests/test_run_job_controller_http.py is adapted from the OCA test. It calls the real /queue_job/runjob route with the X-Odoo-Database header the jobrunner sends, and checks transaction.default_env when the job would be performed. _try_perform_job is patched, so nothing gets committed.

• Current controller: 1 failed of 54 (AssertionError: None != 1, so default_env has no user during the job)
• With the fix: 0 failed, 0 errors of 54, and 0 failed of 731 on our full odoo.sh build
• On our staging database, the Shopify orders that failed before now import without this error.

The 20.0 branch has the same line in runjob and probably needs the same change.