Skip to content

[FIX] portal_backend: assert the parent menus group on registry load - #436

Open
rov-adhoc wants to merge 1 commit into
ingadhoc:19.0from
adhoc-dev:19.0-t-64440-rov
Open

[FIX] portal_backend: assert the parent menus group on registry load#436
rov-adhoc wants to merge 1 commit into
ingadhoc:19.0from
adhoc-dev:19.0-t-64440-rov

Conversation

@rov-adhoc

Copy link
Copy Markdown
Contributor

portal_backend granted base.group_user to the parent menus without group from inside its load_menus override. That method serves /web/webclient/load_menus, a route declared readonly=True, so the write hits a read-only cursor:

ERROR odoo.sql_db: bad query: b'INSERT INTO "ir_ui_menu_group_rel" ("menu_id", "gid") VALUES (...) ON CONFLICT DO NOTHING'
ERROR: cannot execute INSERT in a read-only transaction
WARNING odoo.http: cannot execute INSERT in a read-only transaction, retrying with a read/write cursor
psycopg2.errors.ReadOnlySqlTransaction: cannot execute INSERT in a read-only transaction

The request survives (http._serve_db retries it with a read/write cursor), but odoo.sql_db already logged the failed query as an error, which is enough to turn a build red. On a real database it happens once, because the retry commits the group. On tests it happens on every tour that loads the webclient, since each test rolls that write back — so any module adding an HttpCase tour gets these errors in its log on a full OBA database that has a parent menu without group.

What changes

The assignment moves to _register_hook, which runs on a read/write cursor and is called every time the registry is loaded — which is exactly what installing or updating a module does. That keeps the case the original note cared about covered (another module installing a parent menu without internal group after portal_backend), without writing from a web request.

The ormcache on the override is dropped along with it: the core load_menus is already cached, and the override existed only for the write.

Also skips the write when there is nothing to fix, so the common case is a single search per registry load.

Test plan

On a 19.0 database with portal_backend installed and three active parent menus stripped of their group (Calendar, WhatsApp, Dashboards), running the three stock_account_ux tours of ingadhoc/account-financial-tools#984:

read-only transaction errors ERROR lines tours passed
before 9 3 (one per tour) 3
after 0 0 3

After the run the three menus have base.group_user again, written during the registry load.

Branch name matches ingadhoc/account-financial-tools#984 so runbot builds both in a single bundle.

@roboadhoc

Copy link
Copy Markdown
Contributor

Pull request status dashboard

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Pull request overview

Este PR corrige un efecto colateral en portal_backend donde se escribía en ir.ui.menu desde load_menus (ruta readonly), provocando errores de transacción de solo lectura en logs y fallos en CI/tours. La solución mueve la autocorrección de grupos a _register_hook, que corre con cursor de lectura/escritura durante la carga del registry.

Changes:

  • Mueve la asignación de base.group_user a menús raíz sin grupos desde load_menus a _register_hook.
  • Elimina el ormcache y el override de load_menus, evitando escrituras desde requests web readonly.
  • Evita la escritura cuando no hay menús que corregir.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread portal_backend/models/ir_ui_menu.py Outdated
Granting base.group_user to the parent menus without group was done while
loading the menus, but /web/webclient/load_menus is a readonly route, so
the write breaks its cursor with "cannot execute INSERT in a read-only
transaction". The request itself survives -it is retried with a read/write
cursor- but the failed query is already logged as an error, which is enough
to turn a test run red. On a real database it happened once, since the retry
commits the group; on tests it happens on every tour that loads the
webclient, because each test rolls that write back.

Doing it on _register_hook keeps the case covered -another module installing
a parent menu without internal group after portal_backend- and runs on a
read/write cursor: the hook is called when the registry is loaded, which is
what installing or updating a module does.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants