Wednesday, July 9, 2025
14 changes · saas-18.1
Resolved issues and error corrections
Shipping connector settings no longer show installation checkboxes that pointed to older connector versions. Users are now directed to the Apps menu to choose the appropriate connector, with clearer labeling for new REST API-based options and legacy connectors hidden by default to reduce confusion.
Original PR description
We have recently introduced several new versions of the delivery connectors, based on the newer REST APIs introduced by the shipping companies (USPS, FedEx, UPS, DHL). However, in the settings we still link with installation checkboxes to the old modules. To avoid confusion for the user, we remove these checkboxes and refer the user to the Apps menu instead for manual installation of the preferred shipping connector. In the apps menu, we clarify that these new modules are only compatible with the new REST APIs, and we also hide the legacy modules by default by making them application: False. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213634 Forward-Port-Of: odoo/odoo#201583
Changes to analytic items are now automatically reflected on the related journal item’s analytic distribution. This prevents accounting records from showing outdated analytic information after an analytic item is edited or deleted.
Original PR description
overrode the write and unlink functions related to the analytic_line so that it synchronize the analytic distribution in the move_line every time a change happen before this commit whenever an analytic line is edited it is not reflected to its linked journal line's analytic distribution. so an update function is created so that the analytic distribution is updated whenever an analytic line is edited or deleted. task-4378407 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199020
This fix prevents manufacturing orders from creating and validating an extra by-product quantity when small decimal differences occur during stock move merging. It helps ensure produced quantities stay accurate, especially when by-products use percentage-based cost sharing.
Original PR description
### Steps to reproduce: - In the settings enable by-products - Create a product FP with a bill of material: - 1 operation: op 1 - 1 By-product line: cost share 3.3%, produced in op 1 - Create aand…
### Steps to reproduce: - In the settings enable by-products - Create a product FP with a bill of material: - 1 operation: op 1 - 1 By-product line: cost share 3.3%, produced in op 1 - Create aand confirm an MO for 1 unit of FP - On the by product line produce 10 instead of 1 - Produce All #### > 19 units of by products were produced: The initial by-product move was validated for 10 units and an extra move with a quantity of 9 was automatically created and validated aswell. ### Cause of the issue: Since the quantity of the by-product move exceed its initial demand, its validation will create an extra move that is expected to be merge into the main move during its confirmation: https://github.com/odoo/odoo/blob/474ac02d03c17af0274422ecb1e97ca14a3e80e7/addons/stock/models/stock_move.py#L1922 https://github.com/odoo/odoo/blob/474ac02d03c17af0274422ecb1e97ca14a3e80e7/addons/stock/models/stock_move.py#L1844-L1865 However, while `cost_share` value of the original move floats is correctly encoded as 3.3, the copied value of the extra is 3.3000000000000003. This discrepency is a well known issue of the way the orm handles float and convert them to cache as it calls the `float_round` method, which can effectively change its value: https://github.com/odoo/odoo/blob/8c22e358840f02c5b1596e1fbe0d6cf7315754f7/odoo/fields.py#L1553-L1557 In particular, the `cost_share` of both moves differs in terms of strict equality and the move will not be merged with its extra move. ### Note: The issue should not be reproducible in saas17.4+ because the float_round issues have been erased by commit 784f1511acc4352905a61f9bd90aecb78e8558ec opw-4846289 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216916 Forward-Port-Of: odoo/odoo#215372
Users working in one company could see an access error when creating a bank account number that already existed for a partner in another company. The fix ensures duplicate checks only consider records the user can access for the relevant company, allowing normal bank account setup in multi-company environments.
Original PR description
Step to reproduce 1. Createdb with account and contact module install in 18.0 version. 2. create 2 company A and B 3. create partner with both company A and B seperate 4. create a user that have only…
Step to reproduce 1. Createdb with account and contact module install in 18.0 version. 2. create 2 company A and B 3. create partner with both company A and B seperate 4. create a user that have only rights of company B and rights of Accounting/setting groups 5. create a Bank account(Contact->Configuration->Bank Account) with partner A in company A 6. Now login with user B and create a bank account number with same account number. Access error will come. For resolve the access error fetching the correct result according to company so it won't fetch other company result the changes merged last week https://github.com/odoo/odoo/commit/ad6c9001b447f5ffebafe1581512f48708c7d746#diff-22e97cf61c6826e67cd9a3276bdb292e997cb1117ca44c1749c69d5d01931787R69 ``` Access Error Uh-oh! Looks like you have stumbled upon some top-secret records. Sorry, Test B (id=7) doesn't have 'read' access to: - Contact, A (res.partner: 8) Blame the following rules: - res.partner company If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies. This seems to be a multi-company issue, but you do not have access to the proper company to access the record anyhow. ``` upg-2986193 opw-4876839 tbg-2093 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217042
This update prevents important activity types, such as calls, meetings, leave reminders, approvals, and tax closing tasks, from being deleted or incorrectly restricted to one business area. It also makes activity creation more reliable, reducing crashes and broken workflows when calendar events or automated processes create activities.
Original PR description
Master data protection ====================== In general, be defensive with activity types: avoid crash when activity type has been removed, try to gracefully recover from non existing data, protect…
Master data protection
======================
In general, be defensive with activity types: avoid crash when activity
type has been removed, try to gracefully recover from non existing
data, protect types linked to business code that should not be unlinked
or changed from model.
Introduce a generic way to mark some activity types as master data
* model is fixed and should not be modified, because it is linked
to specific flows e.g. todo should be generic;
* data should not be unlinked, because it is used in automated flows
like plans, business code, ... and cannot easily be replaced;
Mail: make "Call", "Meeting" and "Todo" activity types master data users
cannot remove as they are required in various flows: fleet, plans,
voip, ... Also force their model to be False (aka be cross model).
Mail: make "Warning" and "Upload document" activity types in addition
to "Call" and "Todo", always cross model. As they are used in various
apps it should not be specific to a model.
Hr holidays: prevent from modifying leave activity types, as they are
used in business flows and in automated code.
Fleet: prevent from modifying contract activity type (same reason).
Account Online Synchornization: make "Bank Synchronization" master
data as business behavior dependso on it. Also fix model used for
the type.
Account reports: make "Tax Closing" master data as business flow
depends on it.
Approvals: make "Approval" master data as business flow depends on it
and it is not easy to remove it in their usage.
Hr Payroll: make "Leaves to defer" master data as business flow
depends on it.
Voip: make "Call" activity type master data users cannot remove as it
is required in various flows of VOIP. Also force its model to be False
as it is used in various models and should not suddenly be limited to
a given model. Done in community, as activity is defined in 'mail'.
Studio: make "Approval" master data as approval flow depends on it.
Calendar: fix activities creation
=========================
Current event creation tries to create activities. However code coming
from https://github.com/odoo/odoo/pull/72043 seems quite broken: it tries to find if the
target model accepts activities, but does not by browsing the wrong
model with wrong ids ... which globally turns off activity creation.
This fix rewrites a bit code creating activities when creating an event so
that
* check activity support on the right model;
* it uses the right model on activity type: otherwise you may end up with
models that do not match between record and activity type;
* remove useless (or wrong) code trying to browse 'model ids' on a given
model;
* we now correctly check for activity inheritance using 'is_mail_activity'
field on IrModel;
Task-3777606
Forward-Port-Of: odoo/odoo#217688
Forward-Port-Of: odoo/odoo#156731Manufacturing orders created from make-to-stock-order sales flows now consistently show their related sales order. This removes confusion for users by making navigation work both ways between sales and manufacturing documents.
Original PR description
Currently, with an MTSO rule, the smart button from the Sale Order to the Manufacturing Order was available. However, the reverse link (from the MO to the SO) was missing. But they share the same…
Currently, with an MTSO rule, the smart button from the Sale Order
to the Manufacturing Order was available. However, the reverse link
(from the MO to the SO) was missing.
But they share the same link between object and people don't
understand. So we copy the condition to have the same SO<->MO
link.
It was missing the sale_id on the procurement group itself. Before
production.procurement_group_id.move_dest_ids.group_id.sale_id
was enough since mtso share move links but with the new MTSO it's
not the case anymore. But the sale_id is copied from a procurement
to the new ones.
Steps to reproduce:
- Enable multi-step routes in Inventory settings
- Unarchive the MTO route:
- Select the rule with the production usage
- Set its supply method to "MTSO"
- Create a storable product “P1”:
- routes: MTO + Manufacture
- Create and confirm a Sale Order with one unit of P1
- Confirm the SO
Problem:
The smart button from the SO to the MO appears correctly,
but the reverse link from the MO to the SO is missing.
opw-4619136
opw-4557138
opw-4875937
opw-4854581
opw-4887746
Forward-Port-Of: odoo/odoo#204276Analytic distribution details entered on reimbursable expenses are now copied to the related sales order. This helps teams keep sales reporting and cost allocation accurate when expenses are reinvoiced to customers.
Original PR description
#### Step to reproduce: - Enable Analytic accounting in Accounting settings - Create a sale order - Show Analytic Distribution - Create an expense and put this sale order in the "Customer to…
#### Step to reproduce: - Enable Analytic accounting in Accounting settings - Create a sale order - Show Analytic Distribution - Create an expense and put this sale order in the "Customer to Reinvoice" field. - Add an Analytic Distribution - Create Report - Submit to Manager - Approve - Post Journal Entries #### Curent behavior: - No analytic_distribution on the sale_order #### Expected behavior: - analytic_distribution form the expense should be copied to the sale_order #### Cause: analytic_distribution was not set at the creation of the sale order from the account_move `_sale_get_invoice_price()` is called only in `_sale_create_reinvoice_sale_line()` which is only called in `_prepare_analytic_lines()`. According to [this note](https://github.com/odoo/odoo/blob/18.0/addons/sale/models/account_move_line.py#L31-L32) `_prepare_analytic_lines()` is called only on `move.line` having an `analytic_distribution`. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4710137) opw-4710137 Forward-Port-Of: odoo/odoo#216291
The IoT Box image setup now ensures required software packages are available when connecting to newer Odoo database versions. This prevents connection failures after building an image from this branch, improving reliability for upgrades and deployments.
Original PR description
As saas-18.1 does not pip/apt install packages on checkout, a built image could not connect to a db in an upper version if new packages were required.
This update prevents important activity types, such as calls, approvals, tax tasks, bank synchronization, and payroll leave reminders, from being deleted or incorrectly changed. This helps avoid workflow failures across accounting, HR, approvals, fleet, VoIP, and Studio when these shared activities are needed by automated business processes.
Original PR description
The UAE Corporate Tax Report now prevents taxable amounts and tax due from appearing as negative when profits are below the exemption threshold. This avoids confusing reports that could incorrectly suggest a tax credit or refund when the correct tax amount is zero.
Original PR description
The Corporate Tax Report was incorrectly showing a negative"Corporate TAX Amount" when the taxable profit fell below the exemption threshold (e.g 375,000 AED). This issue happened because the formula used to compute the Corporate TAX Amount was: `AE_CORP_TAXABLE.balance * (AE_CORP_TAX_PERC.balance / 100)` This formula applies the tax rate even when `AE_CORP_TAXABLE.balance` is negative, which results in an incorrect negative tax amount in the report. Since the report engine doesn't support conditional logic like `max(...)` or `> 0` in XML formulas, we couldn't fix this in the formula definition directly. To solve the issue, we added a check in the Python report handler `_custom_line_postprocessor` to override the value of the Corporate TAX Amount and cap it at zero when it would otherwise be negative. Steps to reproduce: In run bot or any db go to Corporate tax report OPW-4739052 Forward-Port-Of: odoo/enterprise#86087
This fix prevents employees with limited point of sale permissions from entering negative quantities through the ticket screen when UrbanPiper integration is installed. It helps ensure refund controls are enforced consistently and reduces the risk of unauthorized refund adjustments.
Original PR description
Fix issue where when `pos_urban_piper` was installed, minimal right employee were able to set negative orderline qty with a refund through the ticket screen. task-id: 4922318 community PR: https://github.com/odoo/odoo/pull/217774
This fixes a rounding mismatch when Mexican electronic payment documents are issued for USD payments, so tax totals now align with official validation rules. Businesses using Mexican CFDI payments in foreign currency should see fewer rejected payment documents caused by small exchange-rate rounding differences.
Original PR description
Steps to reproduce: - With an MX Company setup - Set USD rate to 20.4277 - Create an invoice as follows: - line 1: price_unit 93.76, quantity 172, tax 16% - line 2: price_unit 74.18, quantity 161,…
Steps to reproduce:
- With an MX Company setup
- Set USD rate to 20.4277
- Create an invoice as follows:
- line 1: price_unit 93.76, quantity 172, tax 16%
- line 2: price_unit 74.18, quantity 161, tax 16%
- line 3: price_unit 74.18, quantity 162, tax 16%
- line 4: price_unit 93.76, quantity 384, tax 16%
- line 5: price_unit 111.28, quantity 178, tax 16%
- Confirm and send CFDI
- Register full payment in USD
- Send Payment CFDI
Issue: Payment validation will fail with error
> Code : 301
> Message : Error en complemento Recepción de Pagos. [Error #CRP20204] El
> Valor del campo TotalTrasladosBaseIVA16 no es igual al redondeo de la
> Suma del resultado de multiplicar cada uno de los importes de los
> Atributos BaseP de los impuestos trasladados registrados en el elemento
> TrasladoP donde los atributos contengan en ImpuestoP el valor IVA, en
> TipoFactorP el valor Tasa y en TasaOCuotaP el valor 0.160000, por el
> Valor registrado en el atributo TipoCambioP de cada nodo Pago. Folio: 2.
> Serie: PBNK1/2025/. El atributo "Totales:TotalTrasladosBaseIVA16"
> Contiene el valor "95898.54" sin embargo se calculó que la sumatoria
> Debe contener el valor "95898.45".
opw-4750981
Forward-Port-Of: odoo/enterprise#89728
Forward-Port-Of: odoo/enterprise#88952Settings no longer show installation checkboxes that pointed users to older shipping connectors. Users are now directed to the Apps menu to choose the appropriate connector, while legacy connector apps are hidden by default and newer REST-based connector descriptions are clarified.
Original PR description
We have recently introduced several new versions of the delivery connectors, based on the newer REST APIs introduced by the shipping companies (USPS, FedEx, UPS, DHL). However, in the settings we still link with installation checkboxes to the old modules. To avoid confusion for the user, we remove these checkboxes and refer the user to the Apps menu instead for manual installation of the preferred shipping connector. In the apps menu, we clarify that these new modules are only compatible with the new REST APIs, and we also hide the legacy modules by default by making them application: False. Forward-Port-Of: odoo/enterprise#87337 Forward-Port-Of: odoo/enterprise#81354
Users can now open field service task details from the portal without hitting an error when the optional report module is not installed. The report filename logic was moved into the core Field Service module so the portal flow works in the standard setup.
Original PR description
An error occurs when a user attempts to generate a report from the portal because the `industry_fsm_report` module is not installed. **Steps to reproduce:** * Install `industry_fsm` * Field Service>New Task>log time sheet using `start` button * open portal view( `/my/tasks` )> Your created task> `View details` `AttributeError: 'project.task' object has no attribute '_get_report_base_filename'` **Solution:** * Define `_get_report_base_filename` inside `industry_fsm` instead of `industry_fsm_report`. **Sentry-6685756279** Forward-Port-Of: odoo/enterprise#87949
Master data protection ====================== In general, be defensive with activity types: avoid crash when activity type has been removed, try to gracefully recover from non existing data, protect…
Master data protection
======================
In general, be defensive with activity types: avoid crash when activity
type has been removed, try to gracefully recover from non existing
data, protect types linked to business code that should not be unlinked
or changed from model.
Introduce a generic way to mark some activity types as master data
* model is fixed and should not be modified, because it is linked
to specific flows e.g. todo should be generic;
* data should not be unlinked, because it is used in automated flows
like plans, business code, ... and cannot easily be replaced;
Mail: make "Call", "Meeting" and "Todo" activity types master data users
cannot remove as they are required in various flows: fleet, plans,
voip, ... Also force their model to be False (aka be cross model).
Mail: make "Warning" and "Upload document" activity types in addition
to "Call" and "Todo", always cross model. As they are used in various
apps it should not be specific to a model.
Hr holidays: prevent from modifying leave activity types, as they are
used in business flows and in automated code.
Fleet: prevent from modifying contract activity type (same reason).
Account Online Synchornization: make "Bank Synchronization" master
data as business behavior dependso on it. Also fix model used for
the type.
Account reports: make "Tax Closing" master data as business flow
depends on it.
Approvals: make "Approval" master data as business flow depends on it
and it is not easy to remove it in their usage.
Hr Payroll: make "Leaves to defer" master data as business flow
depends on it.
Voip: make "Call" activity type master data users cannot remove as it
is required in various flows of VOIP. Also force its model to be False
as it is used in various models and should not suddenly be limited to
a given model. Done in community, as activity is defined in 'mail'.
Studio: make "Approval" master data as approval flow depends on it.
Calendar: fix activities creation
=========================
Current event creation tries to create activities. However code coming
from https://github.com/odoo/odoo/pull/72043 seems quite broken: it tries to find if the
target model accepts activities, but does not by browsing the wrong
model with wrong ids ... which globally turns off activity creation.
This fix rewrites a bit code creating activities when creating an event so
that
* check activity support on the right model;
* it uses the right model on activity type: otherwise you may end up with
models that do not match between record and activity type;
* remove useless (or wrong) code trying to browse 'model ids' on a given
model;
* we now correctly check for activity inheritance using 'is_mail_activity'
field on IrModel;
Task-3777606
Forward-Port-Of: odoo/enterprise#89613
Forward-Port-Of: odoo/enterprise#58164