Skip to content

[ADD] base_exception_compat: keep the pre-3590 exception flow for every model - #455

Closed
fw-bot-adhoc wants to merge 1 commit into
ingadhoc:19.0from
adhoc-dev:19.0-18.0-t-75458-lef-9032-fw
Closed

fw-bot-adhoc wants to merge 1 commit into
ingadhoc:19.0from
adhoc-dev:19.0-18.0-t-75458-lef-9032-fw

Conversation

@fw-bot-adhoc

Copy link
Copy Markdown
Contributor

What changes

sale_exception_compat replaces base.exception.method.detect_exceptions(), the method every exception module inherits from. Keeping that replacement inside a sale module left stock_exception covered only while a sale module happened to be installed, and nothing declared that dependency.

This moves the replacement to its own module, auto installed with base_exception. sale_exception_compat keeps only what is specific to sales (companion PR in ingadhoc/sale, same branch name).

Why it matters

On a database with stock_exception and no sale_exception, confirming a transfer that matches an exception rule raises BaseExceptionError from detect_exceptions(). The web client catches it and asks the record for its popup, but stock.picking does not override _must_popup_exception(), so the default False turns it into a soft reload: the transfer stays in draft and the user is told nothing.

About the test_base_exception guard

The override delegates to super() when the context carries test_base_exception, the key upstream sets to exercise the second cursor on purpose in its own tests. Nothing sets it outside tests.

It is needed because this module loads right after base_exception, while sale_exception_compat loaded after the tests of sale_exception had already run. Those tests were green only because the compat was not in the registry yet.

How it was checked

Odoo 18, base_exception 18.0.1.3.0, stock_exception on the branch deployed to customers.

without this module with this module
stock_exception suite, no sale 2 errors of 4 (BaseExceptionError) 0 failed, 0 errors of 4
sale_exception suite 0 failed, 0 errors of 8 0 failed, 0 errors of 8
confirm a picking with an exception, no sale silent soft reload, stays in draft stock.exception.confirm popup
confirm a sales order with an exception sale.exception.confirm popup sale.exception.confirm popup

Upgrading a database that already had sale_exception_compat 18.0.1.1.0 installs this module as the new dependency with no manual step.

Forward-Port-Of: #453

…ry model

The replacement of base.exception.method.detect_exceptions() used to live in
sale_exception_compat. The method is defined on the abstract model every
exception module inherits from, so stock_exception was covered only while a
sale module happened to be installed, with nothing declaring that dependency.

Move it to its own module that auto installs with base_exception, so the flow
is restored for stock.picking, stock.move and anything else that inherits
base.exception without depending on sales.

The override delegates to super() when the context carries test_base_exception,
the key upstream sets to exercise the second cursor on purpose in its own
tests. Nothing sets it outside tests, so the behaviour is unchanged elsewhere
and those tests keep meaning something once this module is loaded.

Without this module, on a database with stock_exception and no sale_exception,
confirming a transfer that matches an exception rule raises BaseExceptionError
from detect_exceptions(). The web client swallows it and asks the record for
its popup, but stock.picking does not override _must_popup_exception(), so the
default False turns it into a soft reload: the transfer stays in draft and the
user is told nothing. stock_exception's own test suite errors on 2 of its 4
tests for the same reason.

X-original-commit: dcab508
@roboadhoc

Copy link
Copy Markdown
Contributor

Pull request status dashboard

@fw-bot-adhoc

Copy link
Copy Markdown
Contributor Author

@lef-adhoc @maq-adhoc while this was properly forward-ported, at least one co-dependent PR (ingadhoc/sale#1878) did not succeed. You will need to fix it before this can be merged.

Both this PR and the others will need to be approved via @roboadhoc r+ as they are all considered “in conflict”.

More info at https://github.com/odoo/odoo/wiki/Mergebot#forward-port

@lef-adhoc

Copy link
Copy Markdown
Contributor

No va a ir a 19 esto

@lef-adhoc lef-adhoc closed this Oct 5, 2026
@lef-adhoc
lef-adhoc deleted the 19.0-18.0-t-75458-lef-9032-fw branch October 5, 2026 18:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants