Tuesday, July 14, 2026
187 changes
14 changes
Enhancements to existing features
Mexican payroll reporting is updated to match CFDI version 1.2e requirements. The change strengthens validation of taxable and exempt payroll amounts and subsidy limits, helping reduce rejected payroll XML submissions and compliance issues.
Original PR description
**. Perceptions – ImporteGravado / ImporteExento (XML Nodes)** For each Perception node, validate that: If ImporteExento = 0, then ImporteGravado > 0. If ImporteGravado = 0, then ImporteExento > 0. Both values cannot be 0 at the same time. These validations must be applied per Perception node, not at an aggregated level. **. TipoPercepcion = "038" (Other Salary Income) (XML Nodes)** When TipoPercepcion = "038": ImporteExento must always be 0. The amount must be recorded only in ImporteGravado. **. SubsidioCausado (XML Nodes)** Update the validation logic for the SubsidioCausado attribute based on NumDiasPagados: If NumDiasPagados ≤ 31, SubsidioCausado ≤ 628.00 If NumDiasPagados > 31, SubsidioCausado ≤ NumDiasPagados × 0.206 task-5412728 Forward-Port-Of: odoo/enterprise#121304
This update improves how manufacturing work orders handle continuous production, making the process cleaner and more reliable for operational teams. It helps reduce friction in production tracking and supports smoother shop floor execution.
Resolved issues and error corrections
This fix prevents errors when calculating CP200 seniority for multiple employees at once in Belgian payroll. It helps payroll batches run reliably and avoids interruptions caused by multi-employee processing.
Original PR description
The CP200 loop in _compute_l10n_be_computed_seniority read from `self` instead of the `version` loop variable, raising "Expected singleton" whenever the batch spanned more than one employee. opw-6349286
3 changes
Enhancements to existing features
This update improves the reliability of marketing automation by expanding test coverage and fixing timing issues when campaign steps are synchronized. It also improves handling of failed, bounced, SMS, and WhatsApp-related activities so campaign flows behave more consistently as they scale.
8 changes
Enhancements to existing features
This update strengthens marketing automation behavior around campaign synchronization, message failures, and user-triggered activities such as opens and clicks. It fixes scheduling and trace handling issues across email, SMS, and WhatsApp journeys, helping campaigns behave more consistently as they scale.
Canadian EFT export files now include a nonzero unique trace number for each payment, using the payment's own ID. This helps ensure CPA-005 payment files meet banking standards and avoids rejection caused by zero-filled trace numbers.
Original PR description
Issue: The Item Trace Number according to CPA-005 standard should be a nonzero sequence that serves as unique reference ID for payments. Currently, Odoo sets the Item Trace Number of all payments as…
Issue: The Item Trace Number according to CPA-005 standard should be a nonzero sequence that serves as unique reference ID for payments. Currently, Odoo sets the Item Trace Number of all payments as a zero-filled sequence According to CPA-005 standards on the Item Trace Number: "The data elements (b), (c) and (d) each must be greater than zero or the TRANSACTION WILL BE REJECTED" (page 36). https://www.payments.ca/sites/default/files/standard005eng.pdf Steps to reproduce: 1. Install the module l10n_ca_payment_cpa005 2. Go into "CA Company" 3. In the configuration for "CA Company", add something to the fields "Short Name used in Canadian EFT" and "Company ID" i.e. "CCC" 4. Set all the fields in the "Canadian EFT/CPA Configuration" section of the bank journal 5. Set the bank record on the bank journal. Set the field "Financial Institution ID Number" field of the "Account Number" record of the bank journal to any numerical sequence 6. Create a bank account on "Azure Interior" and make sure to check the field to trust the bank account that you created (otherwise there will be an error) 7. Create two payments with the vendor of "Azure Interior" using the payment method of "Canadian EFT" 8. Create a batch payment for both payments created 9. Validate the batch payment and the export file should show up in the chatter 10. Note that in the export file, the Item Trace Number for each payment is set to be all zeros, whereas it should be a nonzero identification sequence Solution: Set the Item Trace Number to be the payment's id opw-6323432 Forward-Port-Of: odoo/enterprise#124016 Forward-Port-Of: odoo/enterprise#123633
This fix restores support for portal users to archive or unarchive documents when the action is performed through trusted system-controlled flows. It also prevents unnecessary errors when no documents are involved, improving reliability for document-related processes.
Original PR description
In #116886, we fixed the blocking of portal users to (un)archive documents, but it appears that some flows did rely on it and we were lacking a way of supporting it. Task-6205627 Forward-Port-Of: odoo/enterprise#123015
The Belgian salary package now calculates the maximum mobility budget using the legally correct pay basis, excluding holiday allowance and handling 13th month rules more accurately. It also includes recent commissions, helping employers offer mobility budgets that better match Belgian compliance requirements.
Original PR description
https://lebudgetmobilite.be/fr/6-quel-est-le-montant-du-budget-mobilite#remunerationtotalebrute Simple and double holiday allowance should not be not accounted in the total brut remuneration for the cap of 20% for the mobility budget. 13th month should not be included if it is paid in warrants. This commit fixes the max mobility budget amount computation by multipling the wage by 12.08 instead of 13, as we remove the simple holiday allowance. Ratio = 12 months + 13th month - Simple holiday allowance (0.92 month) Also, Commissions should included: Sum the commissions on payslips of the last 12 months for this employee. MB_Budget = monthly_wage * ratio / 5 + commissions Task-5948733 Forward-Port-Of: odoo/enterprise#109845
The barcode app now fills in the stock owner automatically when scanning eligible products for delivery orders, even when the product is not lot-tracked. This prevents Odoo from creating or updating the wrong stock record and helps ensure consigned inventory is consumed from the correct existing stock.
Original PR description
### Steps to reproduce: - In the settings enable: "Storage Locations" and "Consignment" - Create a storable product and put 1 unit in stock with a set owner - Go to the barcode app > Operations >…
### Steps to reproduce: - In the settings enable: "Storage Locations" and "Consignment" - Create a storable product and put 1 unit in stock with a set owner - Go to the barcode app > Operations > Delivery Orders > New - Scan your product and validate #### > The owner was not set on the stock move line so that a new quant was created and updated in stock rather than using the available unit. ### Cause of the issue: The mechanism of prefilling an owner or a package in the barcode app is currently gate-kept behind the existence of a lot name: https://github.com/odoo/enterprise/blob/0be4f71de3420fb9b72fd4e70d48c6cbbbc0ecb4/stock_barcode/static/src/models/barcode_model.js#L1382-L1407 However, the option also make sense for none tracked products. ### Note: Performing the flow form the backend and adding quantity will generate the move line by setting the owner if possible since the quantity of a move is set via the back end, move lines are generated by looking at the existing quant data's: https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L2364 https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L2328-L2330 Setting the same owner on the new move line as on the quant we are going to reserve: https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L2337 https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L1715 Additional subtelties appearing when prefilling for non tracked product: 1. Currently the available quantity is not taken into account to determine if the the value provided to the prefilled is actually relevant, in particular if there is a quant with an available quantity of 0, it will be used as a valid value to prefill and it will parasit the prefill that could be done by other quants. 2. The location source used to determine the quants taken into account is not set on the first scan since the scan is performed without any existing line: https://github.com/odoo/enterprise/blob/4f0d25f9fe4ca8ff1b0ecd7900899a2a246ba888/stock_barcode/static/src/models/barcode_model.js#L1387 > This was not problematic with respect to tracked product since the product needs to be scanned prior to the lot, hence there is always a current line when the the lot is scanned. opw-6050657 Forward-Port-Of: odoo/enterprise#124017 Forward-Port-Of: odoo/enterprise#115021
Fixes invoice status handling for Field Service sales orders that include zero-priced lines. Existing free items on a quotation can now still be invoiced normally, while free materials added during field work are treated correctly so orders can reach fully invoiced status.
Original PR description
## [FIX] industry_fsm_sale: fix invoice status for zero price lines ### Issue: Without Anglo-Saxon accounting, the system incorrectly sets the invoice status of all zero price sales order lines…
## [FIX] industry_fsm_sale: fix invoice status for zero price lines
### Issue:
Without Anglo-Saxon accounting, the system incorrectly sets the invoice status of all zero price sales order lines linked to an FSM task to 'no'
This includes pre-existing lines that were already present on the quotation before confirmation. If a zero price line is pre-existing, it should follow the standard flow and be marked as 'to invoice'
Only lines added as materials from the field service task at a zero price should be considered included in the price and marked as 'no'
### Cause:
In `SaleOrderLine._compute_invoice_status`, the system forced `invoice_status = 'no'` for all zero price lines when Anglo-Saxon accounting was disabled
It failed to check if the lines were actually materials added via the FSM task or original quotation lines
### Fix:
A new `material_sale_lines` compute field is added to `project.task` to distinctly isolate and track lines added specifically as materials during the task execution
In `SaleOrderLine._compute_invoice_status`, the logic is updated to ensure that only zero price lines identified as FSM materials are set to 'no' when Anglo-Saxon accounting is disabled
Other pre-existing zero price lines properly remain as 'to invoice'
### Steps to reproduce:
- Install `industry_fsm_sale`
- In Settings > Users & Companies > Companies > Any company, add the field Anglo-Saxon using Studio (In 19.0+)
- Disable Anglo-Saxon on the current company
- Create a product Service (Fixed Price, that create a task in a Field Service Project)
- Create and confirm a Sale Order with the Service and one product with unit price 0
Before the fix, the pre-existing SO line with price 0 is
incorrectly considered as not to invoice ('no')
opw-6169802
------------------------------
## [FIX] industry_fsm_sale: sync sale order invoice status
### Issue:
When a sale order contains FSM material lines with a price of zero and Anglo-Saxon accounting is disabled, the overall sale order invoice status remains stuck on 'to invoice' even after all other invoiceable lines are fully invoiced
### Cause:
The standard `SaleOrder._compute_invoice_status` does not handle FSM business rules regarding zero price material lines that are marked as `invoice_status = 'no'`
Because these lines are never technically invoiced, the global order status fails to transition to 'invoiced'
### Fix:
Override `SaleOrder._compute_invoice_status` to recompute the status of confirmed orders linked to FSM tasks
We use the task's `material_sale_lines` to filter out material components
If all lines on the order are either 'invoiced' or are zero price FSM material lines with Anglo-Saxon disabled, the global sale order status is forced to 'invoiced'
### Steps to reproduce:
- Install `industry_fsm_sale`
- In Settings > Users & Companies > Companies > Any company, add the field Anglo-Saxon using Studio (In 19.0+)
- Disable Anglo-Saxon on the current company
- Create a product Service (Fixed Price, that create a task in a Field Service Project)
- Create and confirm a Sale Order with the Service and one product with unit price 0
- Add a Product from the Task (Use a price 0 product, or set the unit price to 0 on the SO)
- Create the invoice for the Sale Order
Before the fix, the Service and Pre-existing product are invoiced, but in the Other Info Tab of the SO, the status stays on 'To Invoice' instead of 'Fully Invoiced'
opw-6169802
Forward-Port-Of: odoo/enterprise#123151
Forward-Port-Of: odoo/enterprise#119238Payslip creation now includes employees assigned to Belgian branch companies when payroll is managed from the parent company. This prevents missing employee records and helps payroll teams process branch employees consistently.
Original PR description
Bug: employees registered on branch companies don't appear in the
employee_id field when creating a payslip from the parent company.
Reason: the domain used ('company_id', '=', company_id) which only
matches the exact company, not its children.
Solution: replaced '=' with 'child_of' to include all descendant
companies in the hierarchy.
task - 6299634
Forward-Port-Of: odoo/enterprise#122381
Forward-Port-Of: odoo/enterprise#120974Users with the Invoicing & Banks accounting access level can now open the Accounting app without encountering an access error. The change restores a missing permission needed to load accounting views, bringing behavior back in line with previous versions.
Original PR description
**Description of the issue/feature this PR addresses:** Users in the 'Accounting / Invoicing & Banks' group were encountering an access error when attempting to open the Accounting app. This was…
**Description of the issue/feature this PR addresses:** Users in the 'Accounting / Invoicing & Banks' group were encountering an access error when attempting to open the Accounting app. This was caused by a missing read access right for the `account.return.type` model that is present in previous versions (e.g. saas-19.3). Without this permission, the basic accounting group (`account.group_account_basic`) is blocked from loading the necessary accounting views. This commit restores the `access_account_return_type_basic` rule, granting read access to the basic accounting group so they can access the app without errors. opw-6377912 **Steps to reproduce:** - Sign in as Mitchell Admin - Settings > Users & Companies > Users > Mitchell Admin > Access Rights > Accounting > Accounting > change to ‘Invoicing & Banks’ - Attempt to access the Accounting app > observe Access Error **Current behavior before PR:** - Users in the 'Accounting / Invoicing & Banks' group are unable to access the Accounting app due to Access Error **Desired behavior after PR is merged:** - Users in the 'Accounting / Invoicing & Banks' are able to access the Accounting app
This fixes an issue where invoice line pre-tax amounts could stay outdated after recalculating taxes with Avatax. The system now refreshes both tax and pre-tax values from the latest Avatax response, helping keep invoice totals accurate.
Original PR description
Previously, when recomputing taxes via Avatax, `manual_tax_amounts` was cleared and repopulated from the fresh API response, but `manual_total_excluded_currency` was only set if it was None. This meant that after the first Avatax call, the pre-tax base amount was never refreshed from subsequent API responses, even though the tax amounts were. This inconsistency could cause stale pre-tax base amounts to persist on invoice lines across recomputations, even when Avatax returned a different base amount. By resetting `manual_total_excluded_currency` to `None` at the start of each recomputation, mirroring what is already done for `manual_tax_amounts`, we ensure that the pre-tax base is always taken from the current Avatax response rather than a previously cached value. opw-6235597 Forward-Port-Of: odoo/enterprise#124152 Forward-Port-Of: odoo/enterprise#123802
Fixed a conflict that could stop Obox quality-control cameras from being detected after the IoT module was installed. This keeps photo-based quality checks working reliably and avoids confusing camera errors for warehouse users.
Original PR description
Steps to reproduce: - Install `obox_quality_control` but do not install `iot`. - Configure a quality check to take a picture with an Obox camera. - Validate a receipt an confirm the camera works as expected. - Now install the `iot` module, and try to take a picture again. **Expected behaviour:** The camera still works as expected. **Actual behaviour:** There is a 'Camera not found' error. This issue is caused by both the Obox and IoT quality modules adding an `identifier` field to the quality control wizard. The fix is simply to use a different name for the Obox field. In addition, we now hide the IoT button in the wizard if the IoT device is not set. task-6329066
Luxembourg payroll now uses the latest official salary index values for contracts starting in 2025 and 2026. This ensures contract signature indexes and related payroll calculations reflect current legal figures instead of outdated 2023 values.
Original PR description
## Issue When creating or browsing an existing contract in a Luxembourgish company, the current index shown is the one from September 2023 (which was up-to-date until Mai 2025). If the contract is…
## Issue
When creating or browsing an existing contract in a Luxembourgish company, the current index shown is the one from September 2023 (which was up-to-date until Mai 2025). If the contract is created after Mai 2025, the "Index on Contract Signature" field is also wrong.
## Steps to reproduce
1. Install *Luxembourg - Payroll* (`l10n_lu_hr_payroll`)
2. Using a Luxembourgish company, create a new contract for an employee
- *Contract Start Date*: Any date after 05/01/2025 (Mai 1st 2025)
3. __The *Index on Contract Signature* shows `944.43`, which is the index from September 2023. It does not match with the most recent indices.__
## Cause
The two most recent indices are missing from the [`rule_parameter_lu_index`](https://github.com/odoo/enterprise/blob/885edbc270a86ab76e0a6eff4acb5767c0fe29d1/l10n_lu_hr_payroll/data/rule_parameters/general_rules_data.xml#L4-L58). These indices are:
- `968.04` from 2025-05-01 (Mai 1st 2025)
- `992.24` from 2026-06-01 (June 1st 2026)
These values were taken from [here](https://salary.lu/en/tools/social-parameters/indexation-of-salaries) and double-checked [here](https://lustat.statec.lu/?lc=en&tm=DF_C1201&pg=0&snb=1).
## Tests modification
Updating the latest index had an impact on the tests from the `l10n_lu_hr_payroll_account` (testing the salary rules). In fact, the current index (`l10n_lu_current_index`) is [used to compute the indexed wage](https://github.com/odoo/enterprise/blob/7892d035ddb968d67a3e8da0daf91292bd8fb499/l10n_lu_hr_payroll/models/hr_contract.py#L24-L33) (`l10n_lu_indexed_wage`), which is then used to compute most lines in the payslip (e.g., the `WAGE_SUPPLEMENT_70`).
https://github.com/odoo/enterprise/blob/7892d035ddb968d67a3e8da0daf91292bd8fb499/l10n_lu_hr_payroll/data/salary_rules/hr_salary_rule_data.xml#L70-L74
Since the latest index is not the same as when those tests were written, the values are not correct anymore. To prevent this, time was frozen to 01/01/2024 to use the expected index (944.43, from September 2023).
opw-6330790
Forward-Port-Of: odoo/enterprise#122147POS users can now access the Kitchen Display app directly from the main dashboard without being blocked by an access error. This removes an inconsistent entry point issue and helps restaurant staff reach preparation displays more reliably.
Original PR description
**Description of the issue/feature this PR addresses:** When a POS user attempts to open the Kitchen Display app from the main dashboard, they are blocked by an Access Error, despite being able to…
**Description of the issue/feature this PR addresses:**
When a POS user attempts to open the Kitchen Display app from the main dashboard, they are blocked by an Access Error, despite being able to access the interface from within the POS app's sub-menu.
This occurs because the dashboard menu triggers a server action (`action_pos_preparation_display_kitchen_display`) to route the user. When a server action has no explicitly defined `group_ids`, Odoo's `_can_execute_action_on_records` method falls back to requiring `write` access on the underlying model (`pos.prep.display`) to execute the code. Since standard POS users do not have 'write' access to this model, the execution engine blocks the routing attempt.
This commit resolves the issue by explicitly appending the POS User group to the server action's `group_ids`.
opw-6305014
**Steps to reproduce:**
- As Mitchell Admin:
- Settings > Users & Companies > Users > Marc Demo > Access Rights > Sales > set POS to User
- As Marc Demo:
- Attempt to access Kitchen Display app > observe Access Error
- POS > Orders > Preparation Display > observe no error
**Current behavior before PR:**
- POS Users receive an Access Error when attempting to access the Kitchen Display app from the main dashboard
**Desired behavior after PR is merged:**
- No Access Error when POS Users access the Kitchen Display app
Forward-Port-Of: odoo/enterprise#122531
Forward-Port-Of: odoo/enterprise#121419Original PR description
RATIONALE In order to prepare upcoming improvements for marketing automation application, as well as performance improvements, some tests are added to improve coverage and cover some synchronization…
RATIONALE
In order to prepare upcoming improvements for marketing automation
application, as well as performance improvements, some tests are added
to improve coverage and cover some synchronization use cases.
SPECIFICATIONS
Add some tests improve coverage of synchronization, as we recently
discovered limitations
* "opposite" triggers when checking brother traces to skip in
'action_update_participants' (which synchronizes traces): sub
addons (sms, whatsapp) is not taken into account;
* 'schedule_date' is not correct for user-based activities (e.g.
mail_open, mail_click, ...) when new activities are added to
a campaign. They should not have scheduled dates, as it depends
on user action. Date is correct for activities when participants
enter child activities but not when doing the synchronize;
* add some checks on participant state;
* globally try to improve some corner cases coverage;
Add some tests to improve coverage of bounce / fail behavior with
various activities, as we want to make it clearer how MA should
behave when dealing with issue. First step is to assert current
behavior and fix some odd bits.
Notably in some cases trace update is missing, notably with SMS
sending with does not call trace update method, which means some
triggers are not processed.
Various fixes are included in this branch, spotted by newly added tests.
See commits for more details.
Task-4224152: [marketing_automation] Performance / Scalability
Forward-Port-Of: odoo/enterprise#124126Resolved issues and error corrections
Fixed an issue in Documents where the Actions button could stop responding after selecting multiple files. Users can now reliably open the Actions menu when working with several selected documents, while selection counts after uploads remain accurate.
Original PR description
***Issue:*** Since https://github.com/odoo/enterprise/commit/8baaad621a1555680cd77ab514f626137b5b584d the div holding the selection box and the Actions menu carries t-key="targetRecords.length" in…
***Issue:*** Since https://github.com/odoo/enterprise/commit/8baaad621a1555680cd77ab514f626137b5b584d the div holding the selection box and the Actions menu carries t-key="targetRecords.length" in the documents list and kanban views, so every change of the selection count destroys and recreates everything inside it. Ticking a document checkbox updates both the selection and the focused record, and with these two updates the recreation goes wrong: the new ActionMenus component ends up destroyed while its button is still in the page. The dropdown click listeners are removed with the component, so clicking Actions does nothing until the selection changes again. That t-key was added because the selection box shows a stale count after a file upload. The real problem is that SelectionBox caches this.root once in setup. The upload flow reloads the model, which replaces the root record list, and the box keeps counting the selection of the old one. ***Fix:*** Remove the t-key from documents_list_controller.xml and documents_kanban_controller.xml and make DocumentsSelectionBox read the current props.root instead of the value cached by the parent setup. The count follows the new record list after an upload without remounting anything, and the Actions menu is not recreated so its dropdown keeps working. The upload scenario stays covered by the existing multi_view.test.js test, a new test checks that the Actions menu opens with two selected documents. ***Steps to reproduce:*** 1. Open the Documents app 2. Switch to the list view 3. Tick the checkboxes of two documents 4. Click the Actions button next to the "2 selected" box => the Actions dropdown does not open Ticket [link](https://www.odoo.com/odoo/project.task/6365618) opw-6365618 Forward-Port-Of: odoo/enterprise#123986 Forward-Port-Of: odoo/enterprise#123575
POS users can now access the Kitchen Display app directly from the main dashboard without being blocked by an access error. This removes an inconsistent entry point issue and helps staff reach preparation displays more reliably during operations.
Original PR description
**Description of the issue/feature this PR addresses:** When a POS user attempts to open the Kitchen Display app from the main dashboard, they are blocked by an Access Error, despite being able to…
**Description of the issue/feature this PR addresses:**
When a POS user attempts to open the Kitchen Display app from the main dashboard, they are blocked by an Access Error, despite being able to access the interface from within the POS app's sub-menu.
This occurs because the dashboard menu triggers a server action (`action_pos_preparation_display_kitchen_display`) to route the user. When a server action has no explicitly defined `group_ids`, Odoo's `_can_execute_action_on_records` method falls back to requiring `write` access on the underlying model (`pos.prep.display`) to execute the code. Since standard POS users do not have 'write' access to this model, the execution engine blocks the routing attempt.
This commit resolves the issue by explicitly appending the POS User group to the server action's `group_ids`.
opw-6305014
**Steps to reproduce:**
- As Mitchell Admin:
- Settings > Users & Companies > Users > Marc Demo > Access Rights > Sales > set POS to User
- As Marc Demo:
- Attempt to access Kitchen Display app > observe Access Error
- POS > Orders > Preparation Display > observe no error
**Current behavior before PR:**
- POS Users receive an Access Error when attempting to access the Kitchen Display app from the main dashboard
**Desired behavior after PR is merged:**
- No Access Error when POS Users access the Kitchen Display app
Forward-Port-Of: odoo/enterprise#122531
Forward-Port-Of: odoo/enterprise#121419Original PR description
RATIONALE In order to prepare upcoming improvements for marketing automation application, as well as performance improvements, some tests are added to improve coverage and cover some synchronization…
RATIONALE
In order to prepare upcoming improvements for marketing automation
application, as well as performance improvements, some tests are added
to improve coverage and cover some synchronization use cases.
SPECIFICATIONS
Add some tests improve coverage of synchronization, as we recently
discovered limitations
* "opposite" triggers when checking brother traces to skip in
'action_update_participants' (which synchronizes traces): sub
addons (sms, whatsapp) is not taken into account;
* 'schedule_date' is not correct for user-based activities (e.g.
mail_open, mail_click, ...) when new activities are added to
a campaign. They should not have scheduled dates, as it depends
on user action. Date is correct for activities when participants
enter child activities but not when doing the synchronize;
* add some checks on participant state;
* globally try to improve some corner cases coverage;
Add some tests to improve coverage of bounce / fail behavior with
various activities, as we want to make it clearer how MA should
behave when dealing with issue. First step is to assert current
behavior and fix some odd bits.
Notably in some cases trace update is missing, notably with SMS
sending with does not call trace update method, which means some
triggers are not processed.
Various fixes are included in this branch, spotted by newly added tests.
See commits for more details.
Task-4224152: [marketing_automation] Performance / ScalabilityThe AI module now moves away from an embedding model that will soon be retired. It also refreshes existing AI data created with deprecated models, helping keep AI-powered features reliable without manual intervention.
Original PR description
The model gemini-embedding-001 will be deprecated soon, so this commit is: - Deprecating that model. - Introducing an autovacuum to recompute embeddings that were done using embedding models that have been deprecated. task-6004597
Resolved issues and error corrections
Invoice tax recalculations through Avatax now refresh the pre-tax base amount each time, instead of reusing an older cached value. This helps prevent incorrect invoice line totals when Avatax returns updated base amounts during recomputation.
Original PR description
Previously, when recomputing taxes via Avatax, `manual_tax_amounts` was cleared and repopulated from the fresh API response, but `manual_total_excluded_currency` was only set if it was None. This meant that after the first Avatax call, the pre-tax base amount was never refreshed from subsequent API responses, even though the tax amounts were. This inconsistency could cause stale pre-tax base amounts to persist on invoice lines across recomputations, even when Avatax returned a different base amount. By resetting `manual_total_excluded_currency` to `None` at the start of each recomputation, mirroring what is already done for `manual_tax_amounts`, we ensure that the pre-tax base is always taken from the current Avatax response rather than a previously cached value. opw-6235597 Forward-Port-Of: odoo/enterprise#123802
Fixed an issue where products using cost-based pricelists showed an outdated On Sale Price after changing the cost. The price now refreshes immediately, helping users see accurate sale pricing when managing product variants.
Original PR description
When we create a product variant and have a pricelist which is based on the cost price, and change the cost price, the on_sale_price doesn't update correctly. It gets delayed by one update because the product._origin isn't getting updated with the new onchanged value. Steps to Reproduce: 1.Create a pricelist and add a line with "formula" price type, and based on "cost", 2.Create a product variant, and add the pricelist just created. 3.Change the "Cost". The "On Sale Price" updates based on the value before. To fix the issue, we need to update the product._origin for standard_price just like the lst_price before computing the on_sale_price opw-5947995 Forward-Port-Of: odoo/enterprise#120420 Forward-Port-Of: odoo/enterprise#119470
Indian GST reports now better reflect legal requirements for import purchases. Imports of services are no longer shown in GSTR-2B, and GSTR-3B reporting has been aligned with the updated sections for imports of goods and services.
Original PR description
As per the law, import of services is not required to be shown in GSTR-2B. Therefore, the related report lines are removed in this commit. Additionally, GSTR-3B reporting is now handled according to the updated section changes for import of goods and services. task-6330737
The appointment calendar now uses the appointment's own timezone when deciding which month to show. This prevents available dates from disappearing or incorrectly showing no slots for bookings near month boundaries.
Original PR description
Steps to reproduce: 1. Install website_appointment 2. Create an appointment with `on specific dates` as Allow booking 3. Set Start time to 1 Jan 2027 2 AM to 31 Dec 2027 4 PM (2 AM is important here)…
Steps to reproduce: 1. Install website_appointment 2. Create an appointment with `on specific dates` as Allow booking 3. Set Start time to 1 Jan 2027 2 AM to 31 Dec 2027 4 PM (2 AM is important here) 4. Set timezone as `Asia/Kolkata` 5. Go to the website via the smart button 6. Navigate through the months in the calendar Issue: - Some months are not showing dates or showing ``` Sorry, we have no more slots available for this month. ``` Why? - The month used for calendar navigation is computed from the appointment `start_datetime`, which is stored in UTC. For appointments close to a month boundary, the UTC date may belong to the previous month (e.g., `2026-12-31 20:30 UTC` instead of `2027-01-01 02:00 Asia/Kolkata`). https://github.com/odoo/enterprise/blob/6b18215bfa98ef636b63f4fafbba1d25264f4883/appointment/controllers/appointment.py#L1061-L1066 As a result, the requested month offset is computed from the wrong month, causing the calendar to display an incorrect month. Solution: - Convert the appointment start_datetime from UTC to the appointment timezone before computing the requested month used for calendar navigation. opw-6224929
Sale Details reports are no longer incorrectly blocked or reformatted for point-of-sale sessions that were opened before Belgian blackbox signing was active. The change also prevents changing the linked blackbox device while a POS session is still open, reducing reporting inconsistencies.
Original PR description
The Sale Details report was blocked and reformatted for every session whose config has a blackbox, including sessions opened before the blackbox was used (whose orders were never signed by the FDM). Introduce a non-stored `use_blackbox` field on `pos.session` Also prevent changing `l10n_be_blackbox_be_id` on a POS config while it has an open session.
This fixes Belgian payroll rules so the 3000 deduction uses the correct values for the second and third quarters of 2026. It helps ensure payroll calculations remain compliant and accurate for affected employees during those periods.