Monday, January 5, 2026
8 changes · saas-18.4
Enhancements to existing features
This update automatically sends rejection emails to applicants when a predefined email template is associated with the refusal reason. Previously, users had to manually enable this feature. This streamlines the recruitment process and ensures timely communication with candidates.
Original PR description
In this commit, we make the toggle button "Send Email" enabled by default whenever the refusal reason has an email template, including the reason selected by default in the wizard. TaskID: 5245023
Resolved issues and error corrections
This update corrects a visual glitch on the Odoo website when using RTL languages like Arabic. Specifically, it eliminates a 200ms flicker when navigating to the top of the page, ensuring a smooth user experience. The fix addresses a positioning issue affecting the mobile menu.
Original PR description
Scenario: - install RTL language on website (eg. Arabic) - go on mobile (eg. chrome developer tools and enable mobile) on website - in arabic, go down to get the navbar that follow the top of…
Scenario:
- install RTL language on website (eg. Arabic)
- go on mobile (eg. chrome developer tools and enable mobile) on website
- in arabic, go down to get the navbar that follow the top of viewport
- go up to the top
Result: there is a 200ms moment when all the interface is moved ~90% to
the right outside of the viewport.
Cause:
In RTL, the header has this state when going down in the page:
- the class: o_header_affixed
- the inline style "transform: translate(0px, -100%);"
- the transition
```
.o_header_affixed {
position: fixed;
}
.o_header_affixed:not(.o_header_no_transition) {
transition: transform 200ms;
}
```
When we go up, the o_header_affixed class is removed as well as the
inline style, but the transition causes 200ms during which we have a
transform without header having the "position: fixed".
This seems to be caused by that situation which makes the offcanvas menu
(mobile menu that appear when clicking on hamburger icon) be at
top:0/left:0 of viewport instead of being at top:0/left:-100%, this
cause all the content to be offset to the right.
Fix:
Force the transition stop if we are at the top of the page where the top
menu is shown and not the affixed menu.
opw-5173822
__PR NOTE:__
Note: I have not been able to reproduce in a small reproduction (such as jsfiddle) so I must be missing one element for the reproduction.
It is "easy" to reproduce and check what is happening when changing the animation to eg. 20000s in this line:
https://github.com/odoo/odoo/blob/d8a875dcdd1262d2d3f15ff9c414e605a7b54526/addons/website/static/src/scss/website.scss#L1493
Then you don't need to block the debugger in the 200ms to check DOM and so on.
The issue is happening in 18.0 but it has been reported in 19.0 and the code has changed between the two so I'm targeting saas-18.4 version.This update corrects a problem where delivery pickings remained 'Waiting Another Operation' after cancelling a related manufacturing order (MTO). The fix reuses existing logic to properly unlink stock moves and update availability, ensuring deliveries can be confirmed correctly. This prevents delays and improves the flow of multi-step manufacturing processes.
Original PR description
Issue ----- After cancelling a MO created by a SO (MTO), user cannot reserve quantity from stock for the delivery picking. This happens for both MO & Reception as long as they are multi-step. Steps…
Issue ----- After cancelling a MO created by a SO (MTO), user cannot reserve quantity from stock for the delivery picking. This happens for both MO & Reception as long as they are multi-step. Steps to reproduce ----- - Enable multi step routes - Set WH to 3-step manufacturing - Create a product - empty bom - MTO & manufacturing routes - 5 in stock - Create a SO for the product - Cancel the linked MO - Open the delivery picking - Click "Check Availability" > The product is not getting reserved from stock > The delivery picking is still "Waiting Another Operation" Cause ----- The problem happens in `action_cancel` https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L1995 In 1-step case, `move.propagate_cancel` is false so we go through https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L2017-L2021 where `move_dest_ids` is the move of the delivery picking. This makes it so that, when we go to the delivery picking and do `action_assign` we go through the first condition while skipping the second of https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L1929-L1931 instead of going into the `else` part https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L1947-L1949 In 3-step, when we `action_cancel`, `move.propagate_cancel` so we go through https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L2009-L2014 which lacks the swap to MTS and unlink `move_dest_id` logic. Solution ----- We can re-use the logic of unlink and MTS swap to `move_dest_ids` that were not cancelled by https://github.com/odoo/odoo/blob/0eb44aec8867e292f8258df02045efe7fbd3303f/addons/stock/models/stock_move.py#L2012 This also takes care of the problem of the status of the delivery picking being `waiting` instead of `confirmed` because it gets recomputed https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L754 and since it was set to MTS, it goes into the `else`part of https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L2202-L2216 ----- Ticket: opw-5124380 Forward-Port-Of: odoo/odoo#241579 Forward-Port-Of: odoo/odoo#237890
This update fixes an issue where payments for payroll were incorrectly linked to the employee's bank account instead of the correct tax account. The change ensures that payments, particularly for taxes, are now routed to the intended bank account, preventing payment errors and improving financial accuracy.
Original PR description
## Reproducing steps 1. Create a DB with demo data (hr,hr_payroll,accountant modules) 2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying…
## Reproducing steps 1. Create a DB with demo data (hr,hr_payroll,accountant modules) 2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying the account number (here is a random account IT22M8576110068R4A56E760901) and setting it as "trusted") 3. Set the bank account of the Internal Revenue Service (IRS) partner (also set it as trusted, and here is another random account: IT77H400725028682A0R202P050) 4. Create a new Off-Cycle Payslip : a. Payroll -> Payslips -> Payslips -> New Off-Cycle button b. Set Mitchell Admin as the employee of the payslip c. Change the Structure to "United States: Regular Pay" d. Compute Sheets 5. Create payments : a. Go to the Journal Entries linked to the payslip, and Post them b. Go back to the payslip and 'Pay' c. In the new wizard: Click on 'Create Payments' 6. Go back to the journal entries, a new button should've appeared on top of the page for the payments (click it now!) 7. Click on the PAY00001 (it the Federal Income Tax which is made to the Internal Revenue Service (ISR) and notice that the bank account used in payment is the bank account of the employee (should be the ISR account obviously) ## Purpose Avoid payment wrong initialization when a default value has been set to initialize the `account.payment.register`. Indeed, the `account.payment` also has a `partner_bank_id` property, and so the method `_create_payment`of the `account.payment.register` can initialize payment with wrong `partner_bank_id`. [enterprise#99373](https://github.com/odoo/enterprise/pull/99373) [task-4979220](https://www.odoo.com/odoo/action-4043/4979220) Forward-Port-Of: odoo/odoo#235475
This update fixes an issue where payroll payments were incorrectly linked to the employee's bank account instead of the correct vendor account (like the IRS). The change ensures payments are accurately routed to the intended recipient, resolving a potential payment error. Automated tests have been added to verify this fix.
Original PR description
## Reproducing steps 1. Create a DB with demo data (hr,hr_payroll,accountant modules) 2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying…
## Reproducing steps 1. Create a DB with demo data (hr,hr_payroll,accountant modules) 2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying the account number (here is a random account IT22M8576110068R4A56E760901) and setting it as "trusted") 3. Set the bank account of the Internal Revenue Service (IRS) partner (also set it as trusted, and here is another random account: IT77H400725028682A0R202P050) 4. Create a new Off-Cycle Payslip : a. Payroll -> Payslips -> Payslips -> New Off-Cycle button b. Set Mitchell Admin as the employee of the payslip c. Change the Structure to "United States: Regular Pay" d. Compute Sheets 5. Create payments : a. Go to the Journal Entries linked to the payslip, and Post them b. Go back to the payslip and 'Pay' c. In the new wizard: Click on 'Create Payments' 6. Go back to the journal entries, a new button should've appeared on top of the page for the payments (click it now!) 7. Click on the PAY00001 (it the Federal Income Tax which is made to the Internal Revenue Service (ISR) and notice that the bank account used in payment is the bank account of the employee (should be the ISR account obviously) ## Purpose Modifying `account.payment.register` for fixing `hr.payslip` payments generation so that each payment is assigned the correct `partner_bank_id`. Also, fixing a SEPA payslip payment bug which says that the employee bank account is untrusted even if it isn't. ## Tests Adding `test_bank_account_partner_payment_payslip` test to check that the payment generated for Professional Tax is made to the correct bank account (before this fix, the selected account was always the employee bank account, whatever the vendor specified in the payment). Adding `test_sepa_payslip_partner_bank_id` test to check that the `partner_bank_id` is set after account_register_payment wizard has been initialized and that the action_create_payments (action launched when the user clicks on "Create Payments" button of the `account_register_payment` wizard) doesn't raise any error. This second test is not really specified in the specs, I just stumbled upon some stacktrace when coding this PR and decided to add a test to check the flow of sepa payment. [community#235475](https://github.com/odoo/odoo/pull/235475) [task-4979220](https://www.odoo.com/odoo/action-4043/4979220) Forward-Port-Of: odoo/enterprise#99373
This update resolves an issue where loyalty program conditions weren't being applied correctly in the Point of Sale (POS) system. The fix ensures the POS configuration properly identifies the pricelist, allowing loyalty discounts to function as intended. This improves the accuracy of loyalty program calculations during transactions.
Original PR description
Task: [#4974070](https://www.odoo.com/odoo/my-tasks/4974070) Runbot build error: [#229672](https://runbot.odoo.com/odoo/runbot.build.error/229672) --- ## Error FAILED: [12/46] Tour…
Task: [#4974070](https://www.odoo.com/odoo/my-tasks/4974070)
Runbot build error: [#229672](https://runbot.odoo.com/odoo/runbot.build.error/229672)
---
## Error
FAILED: [12/46] Tour test_refund_does_not_decrease_points → Step selection popup has '$ 1 per point on your order' (trigger: .selection-item:contains("$ 1 per point on your order")).
## Qualifiers
{
"module": "pos_loyalty",
"test_path": "/pos_loyalty/tests/test_frontend.py",
"tour_name": "test_refund_does_not_decrease_points",
"tour_step": ".selection-item:contains(\"$ 1 per point on your order\")",
"test_class": "TestUi",
"test_method": "test_refund_does_not_decrease_points",
"test_module": "pos_loyalty"
}
## Fix
In some cases, the POS config's `pricelist_id` was not available in the frontend, causing loyalty program conditions to be skipped when checking for a matching pricelist.
By explicitly setting `use_pricelist` to True on the POS config, we ensure that `config.pricelist_id` is properly loaded and available at runtime, allowing loyalty programs with pricelist conditions to behave as expected.
Forward-Port-Of: odoo/odoo#221921This update fixes an issue where imported DTE invoices in a multi-company Odoo environment incorrectly assigned tax. The fix ensures that the tax associated with a DTE invoice matches the company it belongs to, resolving inconsistencies and improving invoice accuracy. This prevents potential tax reporting errors.
Original PR description
**PROBLEM**
When importing a DTE from mail (using fetchmail) in a multicompany setting, there can be company inconsistencies during the import, i.e. the product created during the import belong to the right company, but the tax on a move line belong to another company.
**STEP TO REPRODUCE**
1. Create 2 CL companies with those VAT number: 22060449-7, 77697621-0
2. Set an incoming mail server for bills
3. Send XML to the mailbox (see in the ticket for the xml, one of them should trigger the bug, it depends on the order you created the companies).
4. Run a fetchmail scheduled action.
**CAUSE**
On the creation of the move line for the DTE bill, we retrieve the default purchase tax using `self.env['account.chart.template'].ref('OTAX_19')`. There is no guarantee this tax belong to the recipient company. We should use the default purchase tax of the recipient company instead.
opw-5378068This update ensures that future leave requests are accurately reflected in an employee's available time off, even when they have ongoing accrual allocations. Previously, employees with past accruals wouldn't have their future leaves properly deducted. This change fixes a bug that prevented accurate tracking of available vacation days based on accrual status.
Original PR description
Description of the issue/feature this PR addresses: This ticket: https://www.odoo.com/odoo/project/49/tasks/5218745 In the above ticket, an employee Norbert Loibl had an accrual allocation from Feb.…
Description of the issue/feature this PR addresses: This ticket: https://www.odoo.com/odoo/project/49/tasks/5218745 In the above ticket, an employee Norbert Loibl had an accrual allocation from Feb. 2023 to May 2024. Since then, all his allocations have been regular allocations, so he is no longer accruing vacation days. But, Norbert’s future leaves do not get counted against the “Days Available” displayed on his Time Off Dashboard. Current behavior before PR: If an employee had an accrual allocation (of the relevant type, e.g. past vacation allocations won’t affect sick leave) at any point in time, their future leaves do not get counted against the “Days Available” on their Time Off Dashboard. Desired behavior after PR is merged: If an employee has an accrual allocation between today’s date and the date of a future leave, that future leave does not get counted against the “Days Available” on their Time Off Dashboard. That way, we will count a leave against “Days Available” unless there is a possibility of accruing more days off before the leave. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238977