Daily updates from Odoo
Tuesday, January 6, 2026
429 changes
16 changes
Enhancements to existing features
This update automatically sends email notifications to applicants when a recruiter declines their application, provided a pre-defined email template is available for that reason. This streamlines the recruitment process by ensuring timely communication and reduces manual effort for the HR team. It improves applicant experience and efficiency.
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 Forward-Port-Of: odoo/odoo#234759
Resolved issues and error corrections
This update resolves an issue where a reporting view was incorrectly referencing a non-existent element in Odoo. By adjusting the priority of the views, the system now correctly displays information, ensuring accurate reporting for Mexican EDI stock transactions. This fix was coordinated with a related community PR.
Original PR description
Currently, `base_vat.view_partner_base_vat_form` creates a new div `vat_vies_container`, which is later referenced by the `l10n_mx_edi_stock.mx_partner_operator_form` view. **Root cause:** When the corresponding fix is applied in the community PR, both views end up having the same priority. In this situation, the `mx_partner_operator_form` view applied before `vat_vies_container` is created, causing it to reference a div that does not yet exist (see commit [1]). **Fix:** This commit ensures that the priority of `l10n_mx_edi_stock.mx_partner_operator_form` is lower than `base_vat.view_partner_base_vat_form`, and the container is created before it is referenced. Related community PR: https://github.com/odoo/odoo/pull/241707 [1]: https://github.com/odoo/odoo/pull/161962/commits/653a3eae0bd848cff5862288f30333aa43ae8fe9 opw-5443833
This update improves the clarity of our gratuity reports by now including information on how gratuity is calculated. Previously, this crucial detail was missing, making it difficult to understand the report's figures. This change ensures greater transparency and accuracy for financial reporting.
Original PR description
Before: - We were not printing any information about how gratuity is being calculated. After: - We are going to print information about how gratuity is being calculated. task-5454700
This update fixes an issue where Odoo incorrectly processed partner names consisting of only one word. Previously, these names resulted in an empty first name field. Now, single-word names are correctly assigned to the first name, ensuring accurate partner data is displayed and processed.
Original PR description
Description of the issue/feature this PR addresses: The name splitting logic fails when the partner name contains only one word, resulting in an empty first name. Current behavior before PR: Splitting a single-word name returns an empty first name and assigns the word to the last name. Desired behavior after PR is merged: A single-word name is correctly assigned to the first name field, leaving the last name empty. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241926
This update fixes an issue where navigation using the up/down arrow keys within the HTML editor was not working correctly when inserting stars. The fix ensures that the star-containing lines are properly accessible and selectable, improving the user experience. This resolves a minor usability problem.
Original PR description
When put on a single line, the `o_stars` blocks are not reachable by up/down keyboard navigation because they lack `FEFF` characters to put the cursor. This commit fixes this be removing the outdated `200B` characters that were introduced in [1] and making `o_stars` surrounded by `FEFF`. Steps to reproduce: - Write two lines of text - Add a third line between the two by pressing enter at the end of the first one - Insert stars with `/stars` - Navigate with up/down arrow - Notice that the line with the stars is not skipped - Press Backspace before the stars and before the third line so that everything is on the same line - Press Enter before and after the stars to put then back in three lines - Navigate with up/down arrow => The line with the stars was skipped task-5392572 Forward-Port-Of: odoo/odoo#239432
This update fixes an issue where HR Officers could access restricted functionality within employee forms, leading to potential errors. The changes limit access to 'Create User' and certain data views to authorized HR Managers, ensuring data security and proper user permissions within the HR module. This prevents unauthorized actions and maintains data integrity.
Original PR description
* = hr_work_entry
Steps to reproduce:
- Install 'hr' and 'hr_work_entry'.
- Log in as an HR Officer.
- Open an employee form and click:
- 'Create User'
- 'Work Entries' smart button
- 'History' smart button
Cause:
- 'Create User' was visible to HR Officers, but only users with Settings rights
('base.group_erp_manager') can create 'res.users', causing an AccessError.
- The 'Work Entries' and 'History buttons were visible to HR Officers, but
fields as 'contract_date_start' which only HR Managers can read when
payroll is not installed.
Fix:
- Restricted 'Create User' to 'base.group_erp_manager'.
- Limited the 'History' smart button to 'hr.group_hr_manager'.
- Limited the 'Work Entries' smart button to 'hr.group_hr_manager'.
Task - 5188997
Forward-Port-Of: odoo/odoo#235923This update resolves an issue where HR Officers without payroll access could still view and modify salary adjustments data. The fix restricts access to sensitive payroll information and ensures that users only see relevant data based on their roles, improving data security and user experience.
Original PR description
* = hr_contract_salary Steps to reproduce: - Install 'hr', 'hr_payroll', 'hr_work_entry', and/or 'hr_contract_salary'. - Log in as an HR Officer without payroll access. - On an employee form: -…
* = hr_contract_salary
Steps to reproduce:
- Install 'hr', 'hr_payroll', 'hr_work_entry', and/or 'hr_contract_salary'.
- Log in as an HR Officer without payroll access.
- On an employee form:
- Switch to the 'Salary Adjustments' tab.
- Edit/save a record (tracking reads 'salary_offer_ids').
- Click the 'Work Entries', 'History', or 'Offers' smart buttons.
Cause:
- HR Officers could still reach payroll-only data:
- 'salary_offer_ids' (one2many to 'hr.contract.salary.offer') triggered
tracking reads on a model restricted to HR Managers/Recuriters.
- The 'Salary Adjustments' tab and offer buttons remained visible even when
the user lacked payroll rights.
- The payroll overrides changed 'contract_date_start' to
'hr_payroll.group_hr_payroll_user', so the 'Work Entries'/'History' buttons
show AccessErrors while the buttons stayed visible.
Fix:
- Restricted 'salary_offer_ids' to 'hr.group_hr_manager'.
- Made the 'Salary Adjustments' tab visible only to
'hr_payroll.group_hr_payroll_user' and existing 'Offers' buttons stay for
HR Managers.
- Added dedicated overrides giving 'Work Entries' and 'History' buttons the
'hr_payroll.group_hr_payroll_user' group when payroll is installed.
Task - 5188997
Forward-Port-Of: odoo/enterprise#99234This update fixes a potential issue where printing failed on Windows systems. The change adds a safety net to catch errors during printing, ensuring a more stable and reliable print experience. This improves the overall user experience for Odoo users on Windows.
Original PR description
This commit adds the try/except block around print_raw method of the virtual iot box to allow catching exceptions when printing on Windows Forward-Port-Of: odoo/odoo#238774 Forward-Port-Of: odoo/odoo#238633
This update resolves a bug that prevented users from exporting data from the MPS (Material Requirements Planning) view. The issue stemmed from a recent change that incorrectly pulled data from a related model, causing an error. Now, the export function correctly displays the expected fields from the 'mrp.product.forecast' model.
Original PR description
Steps to reproduce: - Go to MPS - Select one or more records - Click on Action > Export - Search and expand "Forecasted quantity at date" - Select "Forecasted quantity at date/Minimum to Replenish" - Export Before: A traceback is raised with the following error: "ValueError: Invalid field 'min_to_replenish_qty' on 'mrp.product.forecast'" This is caused by the model being overwritten by "mrp.production.schedule". The regression was introduced by commit ac52882, which added a default model "mrp.production.schedule". After: The export works correctly with sub fields. https://github.com/odoo/enterprise/commit/ac52882891a9ede6a5b008ac39fc62b82b7bf813 opw-5406704 Forward-Port-Of: odoo/enterprise#103097
This update fixes an issue where holiday carryover days weren't accurately calculated, leading to discrepancies in the number of days expiring. The change ensures that accrued holiday days are correctly added before the expiration date is determined, resulting in accurate holiday accrual and reporting.
Original PR description
To reproduce: ============= - Create an accrual plan: - Carryover date: allocation - One level: - Accrues 2 days. - Accrual date: monthly on 1st of each month - Starts immediately on allocation start…
To reproduce:
=============
- Create an accrual plan:
- Carryover date: allocation
- One level:
- Accrues 2 days.
- Accrual date: monthly on 1st of each month - Starts immediately on allocation start date - Carryover policy: all days carry over - Carried over days validity: 3 months.
- Create an allocation that uses the above accrual plan on 23/09/2025:
- Starts on 01/07/2024
We should have 30 days in total with 24 expiring on 01/10/2025 but we only have 22 expiring on 01/10/2025.
Problem:
========
When `accrued_gain_time` of the accrual plan is 'start', in the `_process_accrual_plans` method, the property `expiring_days` is set when the first accrual still hasn't been added to the `number_of_days` (it is usually added at the [end of the loop](https://github.com/odoo/odoo/blob/18.0/addons/hr_holidays/models/hr_leave_allocation.py#L596)).
Solution:
=========
In the `_process_accrual_plans`, add the accrued days to the `number_of_days` before the `expiring_days` is set.
[opw-4963163](https://www.odoo.com/odoo/all-tasks/4963163)
Forward-Port-Of: odoo/odoo#240738
Forward-Port-Of: odoo/odoo#233424This update fixes a technical issue that caused an error when reconciling invoices with multiple bank transactions. The fix ensures the reporting of invoice line amounts is accurate, even when multiple bank statements are used for reconciliation. This improves the reliability of financial reporting within the system.
Original PR description
### Issue description: The `_compute_full_amount_switch_html` method assumes that `reconciled_lines_excluding_exchange_diff_ids` contains at most one line (which is true only for move lines of bank statement lines). However, if an invoice is reconciled with multiple bank transactions, when accessing the `full_amount_switch_html` for any move line in the invoice, it triggers `ValueError: Expected singleton`, as the compute method uses the reconciled_lines as if they are a single line. ### Steps to reproduce: 1. Create an invoice 2. Reconcile the invoice with multiple bank transactions. 3. Perform a read on the `full_amount_switch_html` field on the invoice line from the invoice (using the web tool, or add the field to any view). 4. You will get `ValueError: Expected singleton: account.move(XX, XX)` opw-5224135 Forward-Port-Of: odoo/enterprise#103193 Forward-Port-Of: odoo/enterprise#102048
This update addresses a critical issue by implementing a 'neutralization' process for the l10n_gt_edi module. This ensures that support teams can safely examine database copies without risking disruptions to live customer data or impacting the main production database. It's a standard security practice to allow for safe troubleshooting.
Original PR description
This commit adds the missing neutralization necessary for the l10n_gt_edi module The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. Forward-Port-Of: odoo/enterprise#102695
This update ensures that Point of Sale line merges are only successful when the discount and unit price are identical. Previously, merging worked inconsistently, leading to potential errors. This change provides a more reliable and predictable merging process for Point of Sale orders.
Original PR description
Only allow merging lines if they have the same discount and unit price. Before this commit, you were able to merge lines with different discounts or unit prices only if the source order contained the line with the discount/price change. It was not working the other way which was inconsistent. task-id: 5189949 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232963
This update adds a critical neutralization process for the l10n_tw_edi_ecpay tax module. This ensures that support teams can safely examine database copies without risking changes to the live production system or impacting customer data. This is a standard security practice to allow for safe troubleshooting.
Original PR description
This commit adds the missing neutralization necessary for the l10n_tw_edi_ecpay module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] https://github.com/odoo/odoo/pull/223132 Forward-Port-Of: odoo/odoo#240975
This update fixes an issue where the hours view would overlap with the progress bar display in the Gantt view when work entries were activated in sparse mode. This enhancement ensures a cleaner and more functional user experience for managing work entries within the Gantt chart.
Original PR description
When the work entry is activated in sparse mode prevent the hours view from overlapping. task-5410789 Forward-Port-Of: odoo/enterprise#101939
This update fixes an issue where imported DTE invoices in a multi-company environment incorrectly assigned tax to the wrong company. The fix ensures that the tax aligns with the company receiving the invoice, improving financial accuracy and compliance. This resolves inconsistencies during import processes.
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-5378068
Forward-Port-Of: odoo/enterprise#10227410 changes
Resolved issues and error corrections
This update fixes an issue where links to headings within locked articles didn't scroll to the correct location after loading. The fix ensures consistent navigation behavior for all articles, regardless of whether they're locked, improving the user experience for accessing content within the Knowledge base.
Original PR description
Problem: When navigating to a link that points to a heading in a locked article, the page does not scroll to the target heading after load. Cause: When an article is locked, `HtmlViewer` is used instead of the editor. In this mode, `HeadingLinkPlugin` is not loaded, even though it is the component responsible for scrolling to elements with `data-heading-link-id`. Solution: Add the same heading link scrolling logic to `HtmlViewer` so that links to headings work consistently, even when the article is locked. Steps to reproduce: - Go to Knowledge. - Copy a heading link. - Lock the article. - Paste the URL in the browser. - When the page loads, it does not scroll to the heading. opw-5418474 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where links to headings within locked Knowledge articles didn't scroll to the correct section after loading. By adding scrolling logic to the `HtmlViewer` component, the system now consistently supports heading link navigation, regardless of article locking status. This improves the user experience for accessing information within Knowledge articles.
Original PR description
Problem: When navigating to a link that points to a heading in a locked article, the page does not scroll to the target heading after load. Cause: When an article is locked, `HtmlViewer` is used instead of the editor. In this mode, `HeadingLinkPlugin` is not loaded, even though it is the component responsible for scrolling to elements with `data-heading-link-id`. Solution: Add the same heading link scrolling logic to `HtmlViewer` so that links to headings work consistently, even when the article is locked. Steps to reproduce: - Go to Knowledge. - Copy a heading link. - Lock the article. - Paste the URL in the browser. - When the page loads, it does not scroll to the heading. opw-5418474
This update resolves an issue where tax grouping keys in the account_edi_ubl module could sometimes be unexpectedly empty. This fix ensures accurate tax reporting when generating invoices and other financial documents, particularly when using customizations. It also includes a minor correction related to excise taxes.
Original PR description
Some overrides assign a value to the tax's grouping_key after the super call. However, the returned value could be None. Also fix a little mistake regarding excise taxes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239954
This update fixes a reporting error in the French P&L statements. The 'owner remuneration' account (644) was incorrectly categorized as 'tax and duties'. It has now been moved to the correct 'wages and salaries' category, ensuring accurate financial reporting for French businesses.
Original PR description
Account '644 owner remuneration' was in the 'tax and duties' category in the french P&L but it belongs to the 'wages and salaries' category task-5446018 Forward-Port-Of: odoo/enterprise#103214 Forward-Port-Of: odoo/enterprise#103061
This update resolves an issue where color fields within editable list views weren't consistently saving changes when using the 'bottom' editing mode. Previously, users would need to refresh the page to see updates. This fix ensures color field edits are reliably saved, improving the user experience and data accuracy within Odoo's list views.
Original PR description
This commit fixes the issue where editing a field with widget="color" does not save it when the list is in editable="bottom" mode. project.task~5262582 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#238644
This update clarifies delivery slip reports by explicitly labeling the delivery address as 'Delivery Address' and simplifying customer information labels. These changes reduce potential errors and improve operational efficiency when processing deliveries.
Original PR description
To resolve ambiguities and improve operational efficiency: 1. The delivery address is explicitly labeled 'Delivery Address'. Ensuring no doubt about the final destination. 2. The label for the customer's primary information has been updated from 'Customer Address' to simply Customer, which prevents operators from mistaking it for the delivery point. Backport of https://github.com/odoo/odoo/pull/220019 Task: 3379926 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#241988
A bug prevented the correct calculation of working time for tasks assigned in company B when a time off was previously set in company A. The issue stemmed from a system-wide holiday check that didn't account for the specific company, leading to incorrect working time assignments. This fix ensures accurate working time calculations across multiple companies.
Original PR description
__ ## Short functional explanation of the error Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in…
__ ## Short functional explanation of the error Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in company A, then switch back to company B. In company B, we create a project and a task, and assign this task. The working time to assign will stay at 0. ## Reproduction Steps 1. Switch to company A and create a timeoff starting before today and ending later. 2. Switch back to company B. Create a project, a stage and a task. 3. Enable the debugger. 4. The field Working Time to Assign is invisible by default, so open studio, click on View, and check Show Invisible Elements. 5. Click on the tab Extra info and on the block Working time to assign. Uncheck Invisible. 6. Close studio and assign someone to the task. Make sure that you do this operation at a different time than the one recorded for the last stage change. ### Expected behavior The hours under Working Time to Assign should compute the difference between the last time the task got its stage changed and the time of assignation ### Unexpected behavior Nothing happens ## Origin of the issue When computing the working time to assign, we also take into consideration leaves: if this happened during public holidays, we consider that it took no working time to get assigned. However, when a holiday is set in another company, the Working Time to Assign duration will be impacted, as the domain to retrieve the corresponding leaves is the following: https://github.com/odoo/odoo/blob/c7e965a61b7ce856c2daa8e2574cf4c60caf7a20/addons/resource/models/resource_calendar.py#L537-#546 The company isn't taken into account in the domain, applying the holiday for every company. _________________________________________ opw-5222883 Forward-Port-Of: odoo/odoo#236043
This update fixes a technical issue where Odoo incorrectly processed partner names with only one word. Previously, a single-word name would result in an empty first name field. Now, single-word names are correctly assigned to the first name, ensuring accurate data entry and reporting.
Original PR description
Description of the issue/feature this PR addresses: The name splitting logic fails when the partner name contains only one word, resulting in an empty first name. Current behavior before PR: Splitting a single-word name returns an empty first name and assigns the word to the last name. Desired behavior after PR is merged: A single-word name is correctly assigned to the first name field, leaving the last name empty. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241926
This update fixes an issue where delivery slips were printed with move lines in the wrong order. The fix ensures that move lines are printed in the correct sequence based on their original move IDs, resulting in accurate delivery slip generation. This improves the reliability of the delivery slip printing process.
Original PR description
**Steps to reproduce:** - Add 2 products in a delivery - Add the second's product move lines before the first one. - Validate and print delivery slip **Issue:** We iterate the `move_line_ids` directly which means if we have a new move line for a move with a lower id, it will push the product to the end of the delivery slip. **Example:** If we have `stock.move(1,)` with `stock.move_line(52,)` and `stock.move(2,)` with `stock.move_line(51,)`. `stock.move_line(51,)` will be printed first, which introduces a change in the order of the delivery slip. **Fix:** Iterate on `move_ids` and access `move_line_ids` through it, to print `move_lines_ids` in the same order of the `move_id`. Task: 4570203 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213400
This update resolves a bug that prevented users from exporting data from the MRP MPS view. The issue stemmed from a recent change that incorrectly pulled fields from a related model. Now, the export function correctly displays the expected fields from the 'mrp.product.forecast' model, ensuring data can be exported without errors.
Original PR description
Steps to reproduce: - Go to MPS - Select one or more records - Click on Action > Export - Search and expand "Forecasted quantity at date" - Select "Forecasted quantity at date/Minimum to Replenish" - Export Before: A traceback is raised with the following error: "ValueError: Invalid field 'min_to_replenish_qty' on 'mrp.product.forecast'" This is caused by the model being overwritten by "mrp.production.schedule". The regression was introduced by commit ac52882, which added a default model "mrp.production.schedule". After: The export works correctly with sub fields. https://github.com/odoo/enterprise/commit/ac52882891a9ede6a5b008ac39fc62b82b7bf813 opw-5406704 Forward-Port-Of: odoo/enterprise#103097
7 changes
Resolved issues and error corrections
This update resolves a bug that prevented users from assigning statements to multiple bank lines within the Bank Reconciliation widget. The fix ensures the system handles multiple selections correctly, preventing a common error. This improves the usability of a key accounting function.
Original PR description
An error occurs when a user tries to assign a Statement to multiple selected lines in the Bank Statement list view. Steps to reproduce: 1) Install Accounting with demo data. 2) Open the Bank…
An error occurs when a user tries to assign a Statement to multiple selected lines in the Bank Statement list view. Steps to reproduce: 1) Install Accounting with demo data. 2) Open the Bank Reconciliation widget. 3) Switch to the List view. 4) Select multiple statement lines. 5) Click on the 'Statement' field to assign a statement to the selected lines. Error: `TypeError: Cannot read properties of undefined (reading 'root')` Root Cause: The `BankRecMany2OneMultiID` component attempts to access `active_ids` through `this.env.model.root` (see [1]). During re-rendering, the value of `this.env.model` becomes undefined, which leads to the error. Fix: Add a check for the existence of `this.env.model` in the getter to avoid accessing `root` on an undefined model. [1]- https://github.com/odoo/enterprise/blob/c194bee0e48db407288e3c402e71840af299568d/account_accountant/static/src/components/bank_reconciliation/list_view/list_view_many2one_multi_edit.js#L14 opw-5403564
This update fixes a reporting error in the French P&L statements. The 'owner remuneration' account (644) was incorrectly categorized as 'tax and duties.' This change ensures accurate reporting of wages and salaries for French businesses, aligning with accounting standards.
Original PR description
Account '644 owner remuneration' was in the 'tax and duties' category in the french P&L but it belongs to the 'wages and salaries' category task-5446018 Forward-Port-Of: odoo/enterprise#103214 Forward-Port-Of: odoo/enterprise#103061
This update resolves an issue where color fields within editable lists weren't saving changes when using the 'bottom' editing mode. Previously, edits to color fields were lost. Now, color field changes will correctly save when the list is in 'bottom' mode, ensuring data integrity and a consistent user experience.
Original PR description
This commit fixes the issue where editing a field with widget="color" does not save it when the list is in editable="bottom" mode. project.task~5262582 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#238644
This update fixes a limitation in generating payslips for previous years. Now, employee data can be retroactively updated, allowing for accurate reporting of payroll snapshots across all years. This ensures compliance and provides a complete historical record of employee compensation.
Original PR description
Currently employee data only updates current year snapshots, which can be an issue when generating payslips for previous years, in this PR we enable retroactive updates by changing the mecanism. The new mecanism updates snapshots of the payslip years, making a reference date usage possible. Forward-Port-Of: odoo/enterprise#103147
This update clarifies delivery slip reports by explicitly labeling the delivery address as 'Delivery Address' and simplifying customer information labels. These changes reduce potential errors and improve the accuracy of delivery details, leading to smoother operations.
Original PR description
To resolve ambiguities and improve operational efficiency: 1. The delivery address is explicitly labeled 'Delivery Address'. Ensuring no doubt about the final destination. 2. The label for the customer's primary information has been updated from 'Customer Address' to simply Customer, which prevents operators from mistaking it for the delivery point. Backport of https://github.com/odoo/odoo/pull/220019 Task: 3379926 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#241988
This update fixes an issue where Odoo incorrectly processed partner names with only one word, resulting in an empty first name field. Now, single-word names are properly assigned to the first name, ensuring accurate data entry and reporting. This improves the reliability of payment processing and customer information.
Original PR description
Description of the issue/feature this PR addresses: The name splitting logic fails when the partner name contains only one word, resulting in an empty first name. Current behavior before PR: Splitting a single-word name returns an empty first name and assigns the word to the last name. Desired behavior after PR is merged: A single-word name is correctly assigned to the first name field, leaving the last name empty. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241926
This update fixes an issue where delivery slips were printed with move lines in the incorrect order. The change ensures that move lines are printed in the same order as their associated stock moves, resulting in accurate and consistent delivery slip reports. This improves the reliability of our shipping documentation.
Original PR description
**Steps to reproduce:** - Add 2 products in a delivery - Add the second's product move lines before the first one. - Validate and print delivery slip **Issue:** We iterate the `move_line_ids` directly which means if we have a new move line for a move with a lower id, it will push the product to the end of the delivery slip. **Example:** If we have `stock.move(1,)` with `stock.move_line(52,)` and `stock.move(2,)` with `stock.move_line(51,)`. `stock.move_line(51,)` will be printed first, which introduces a change in the order of the delivery slip. **Fix:** Iterate on `move_ids` and access `move_line_ids` through it, to print `move_lines_ids` in the same order of the `move_id`. Task: 4570203 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213400
7 changes
Resolved issues and error corrections
This update fixes an issue where Odoo incorrectly processed partner names with only one word. Previously, single-word names resulted in an empty first name field. Now, single-word names are correctly assigned to the first name, ensuring accurate data entry and reporting for partner information.
Original PR description
Description of the issue/feature this PR addresses: The name splitting logic fails when the partner name contains only one word, resulting in an empty first name. Current behavior before PR: Splitting a single-word name returns an empty first name and assigns the word to the last name. Desired behavior after PR is merged: A single-word name is correctly assigned to the first name field, leaving the last name empty. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241926
This update fixes an issue where delivery slips were printed with move lines in the wrong order. The fix ensures that move lines are printed in the correct sequence based on their move IDs, resulting in accurate delivery slip generation. This improves the reliability of delivery documentation.
Original PR description
**Steps to reproduce:** - Add 2 products in a delivery - Add the second's product move lines before the first one. - Validate and print delivery slip **Issue:** We iterate the `move_line_ids` directly which means if we have a new move line for a move with a lower id, it will push the product to the end of the delivery slip. **Example:** If we have `stock.move(1,)` with `stock.move_line(52,)` and `stock.move(2,)` with `stock.move_line(51,)`. `stock.move_line(51,)` will be printed first, which introduces a change in the order of the delivery slip. **Fix:** Iterate on `move_ids` and access `move_line_ids` through it, to print `move_lines_ids` in the same order of the `move_id`. Task: 4570203 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213400
This update ensures that payments made on the website for ecommerce orders are correctly reflected in the POS. Now, the POS automatically recognizes and accounts for previously paid amounts, preventing duplicate payments and simplifying the checkout process. Fully paid orders will no longer appear in the POS, allowing invoices to be created through the standard Odoo Sale app.
Original PR description
Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the…
Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the Quotation/Order menu, but the POS didn't have any reference on the payment, so you would have to create another duplicate payment. Now the amount_paid (which is the amount already paid in transactions) is taken into account when calculating what's left to pay in the POS. So anytime you open a sale order in the POS it should create a down payment line for anything already paid on the website (the same as we were already doing for invoices). Also to avoid double payments, now the sale orders which have been already paid in full, even if they are not invoiced yet, will not show up in the POS. The invoice can still be created normally from the Sale app in Odoo. Task-5187602 Original Task-5138081 Backport-[#230809](https://github.com/odoo/odoo/pull/230809) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232841
This update fixes a problem where payments made on the website weren't correctly reflected in the POS. Now, the POS automatically recognizes and accounts for payments made through ecommerce, creating down payment lines and preventing duplicate payments. This ensures accurate order totals and simplifies the payment process for users.
Original PR description
Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the…
Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the Quotation/Order menu, but the POS didn't have any reference on the payment, so you would have to create another duplicate payment. Now the amount_paid (which is the amount already paid in transactions) is taken into account when calculating what's left to pay in the POS. So anytime you open a sale order in the POS it should create a down payment line for anything already paid on the website (the same as we were already doing for invoices). Also to avoid double payments, now the sale orders which have been already paid in full, even if they are not invoiced yet, will not show up in the POS. The invoice can still be created normally from the Sale app in Odoo. Task-5187602 Community PR-[#232841](https://github.com/odoo/odoo/pull/232841) Backport-[#96876](#https://github.com/odoo/enterprise/pull/96876) Original Task-5138081 Forward-Port-Of: odoo/enterprise#98029
This update addresses a critical issue related to database copies used for support investigations. The addition of 'neutralization' safeguards against unintended interactions with the live production database, protecting customer data and ensuring stable support processes. This improves the security and reliability of our support operations.
Original PR description
This commit adds the missing neutralization necessary for the l10n_gt_edi module The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. Forward-Port-Of: odoo/enterprise#102695
This update adds a crucial neutralization step for the l10n_tw_edi_ecpay module, allowing our support team to safely investigate database duplicates without impacting live customer data. This neutralization framework prevents unintended interactions between database copies and the production system, ensuring data integrity and security.
Original PR description
This commit adds the missing neutralization necessary for the l10n_tw_edi_ecpay module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] https://github.com/odoo/odoo/pull/223132 Forward-Port-Of: odoo/odoo#240975
This update fixes an issue where modifying a product's Bill of Materials (BOM) didn't properly remove associated move raw materials from the manufacturing order. The change ensures that move raw records are correctly updated and removed when the BOM is modified, preventing data inconsistencies in production planning. This improves the accuracy of inventory management.
Original PR description
### Steps to reproduce: - Create a bom for a product with 2 component lines: - 1 x COMP1 - 1 x COMP2 - Create an MO for your product (do not confirm it) - Delete the second bom line of the bom - On…
### Steps to reproduce:
- Create a bom for a product with 2 component lines:
- 1 x COMP1
- 1 x COMP2
- Create an MO for your product (do not confirm it)
- Delete the second bom line of the bom
- On the draft MO, click on `update bom`
#### > This automatically modifies the `move_raws` of the MO but the un-linked move raws were neither deleted nor cancelled as shown by the move analysis
### Cause of the issue:
Clicking on `update bom` will launch a call of the `action_update_bom` which will itself call the `_link_bom` to update the record: https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/mrp_plm/models/mrp_production.py#L73-L80 https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L2406-L2418 Now the issue is that the `bom_id` is set to `False` before the value of the `move_raw_ids` and `workorder_ids` are stored to be unlinked in the `moves_to_unlink` and `workorders_to_unlink` variable. Now, the issue is that the `bom_id` is a dependency of both compute methods: https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L745-L746 https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L563-L564 in particular, `moves_to_unlink` will always be an empty record set and the value of the `workorders_to_unlink` might be unreliable.
opw-5243203
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#23965436 changes
New functionality added to Odoo
This update adds helper functions to manage slot selections within the Point of Sale system. These functions will be used during training tours to guide users through scheduling orders with specific time slots. This enhancement improves the clarity and usability of the slot selection process for Point of Sale operations.
Original PR description
Add utils function `selectSlotDays` & `selectPresetTimingSlotIndex` to select the nth day and nth timing slot in the slot selection dialog. These functions will be used in POS tours to manage orders with slots. enterprise PR: https://github.com/odoo/enterprise/pull/95136 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241644 Forward-Port-Of: odoo/odoo#233920
Enhancements to existing features
This update enhances the Point of Sale category system by allowing users to delete categories only when they aren't actively used in POS sessions. It also streamlines product creation from POS sessions, ensuring new products always appear on the relevant POS. Design improvements include a refined form view and enhanced Kanban/List views for better category organization.
Original PR description
**Functional** - Removed the restriction of deleting pos categories while sessions are open and replaced it with a restriction on removing categories which are used by POS. If the category is not in…
**Functional** - Removed the restriction of deleting pos categories while sessions are open and replaced it with a restriction on removing categories which are used by POS. If the category is not in use by any POS deleting it will have no side-effects. - Moved the definition of pos_config_ids from the pos_self_order override of the pos.category to the base class in point_of_sale so it can be always accessed, not only when the self_order is installed. - Creating a new product from a POS session with a category which is not displayed on the current POS session will automatically add the category to the POS session config and reload the data to show the new products. This way when a user creates a new product, it will always show up on their POS from where they created the product. **Design (Categories)** - [Form View] For a better design will align the category title with the rest of the fields on the form view. Also added a placeholder on the pos_restaurant course field. - [Kanban] Improved the kanban view to show the color, parent category and course if they are present directly on the card. - [List] Made the parent category and color display by default. Added the points of sale where the category is used to the list Task - 5172551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update allows users to schedule invoice and EDI sending from the account move send wizard, providing greater control over delivery timing. It categorizes sending methods (email, EDI, etc.) for efficient scheduling and ensures accurate invoice data is prepared for each scheduled message. Additionally, the system now validates invoice data before scheduling to prevent errors during the sending process.
Original PR description
PURPOSE - The purpose of this commit is to allow users to schedule the execution of the Invoice and EDI sending in the future from the account move send wizard. - Users have control to schedule the…
PURPOSE - The purpose of this commit is to allow users to schedule the execution of the Invoice and EDI sending in the future from the account move send wizard. - Users have control to schedule the e-mail, EDIs, and other sending methods on different dates and times, as there will be separate scheduled messages for all these sending methods and EDI requests. TECHNICAL DETAILS - Introduced basic scheduling functionalities similar to the mail compose message wizard into the account move send wizard. - Categorising the selected checkboxes into 3 categories of scheduled messages: 1. For email sending method 2. For all the selected extra EDIs 3. For all the other selected sending methods (snailmail, peppol, ...) - Classifying the calculated `invoice_data` based on the selected checkboxes and preparing the invoice_data for individual scheduled messages. - Preserving this invoice_data in the `notification_parameter` of the scheduled message to retrieve it later when posting the scheduled messages and calling the actual `_generate_and_send_invoices` process. - Manually added attachments in the scheduled message will also be added to the `mail_attachments_widget` in invoice_data to consider it for the email sending method. Related Enterprise PR: https://github.com/odoo/enterprise/pull/92857 Task: 4677423
This update simplifies the employee search experience by removing redundant fields and filters. The employee list view has also been cleaned up for better clarity and usability. This change focuses on improving user efficiency when managing employee data.
Original PR description
- Reduced and removed employee search fields. - Removed and renamed filters. - Clean up employee list view. task-5441509 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update simplifies the employee search experience by removing redundant fields and filters. The employee list view has also been cleaned up for better clarity and usability. This change focuses on improving user efficiency when managing employee data.
Original PR description
- Reduced and removed employee search fields. - Removed and renamed filters. - Clean up employee list view. task-5441509
This update enhances order reporting within Odoo by allowing users to group orders and order analysis data by hour. This provides more granular insights into sales trends and helps businesses better understand customer behavior and operational efficiency. The change impacts the 'Orders' and 'Order analysis' views.
Original PR description
After this commit: == - Views of `Orders` and `Order analysis` can be grouped by hour. task: 5022973
This update resolves an issue where 'Validate' and 'Discard' buttons in the Quality Worksheet Template form were non-functional, preventing users from easily navigating back. The team has removed these buttons and implemented a Kanban view to enhance visibility and usability, streamlining the template management process.
Original PR description
In the Quality Worksheet Template form view, the "Validate" and "Discard" buttons were non-functional and blocked users when navigating back after designing a worksheet. This commit removes these buttons and adds a Kanban view to improve visibility and usability. These enhancements streamline the interface and make it more intuitive for users managing Quality Worksheet Templates. Task - [4637037](https://www.odoo.com/odoo/project/966/tasks/4637037)
This update enhances the system's ability to process Electronic Data Interchange (EDI) orders by learning from previous order files. It automatically identifies and reuses customer product references, reducing manual effort for sales staff and improving order accuracy. This change streamlines the EDI workflow, particularly for repeat customers.
Original PR description
This commit add functionality to make edi more efficient by learning it from past PO order files extracted. Working: - when we extract file and didn't find any matching products for line then store that customer product reference on SOL after then Sales person will set proper product from his DB or create one and set product then confirm order so On order confirmation we extract product customer reference and store it on `customer.product.reference` then when we extract new file from same customer we look and don't find matching product then we will look for product in `customer.product.reference` and if we find matching product then set that product on SOL. task-4086173
This update automatically sends email notifications to applicants when a recruiter declines their application, provided a pre-defined email template is available for that reason. This streamlines the recruitment process by ensuring timely communication and reduces manual effort for the HR team. The change improves applicant experience and efficiency.
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 Forward-Port-Of: odoo/odoo#234759
Resolved issues and error corrections
This update fixes an issue where clicking on employee avatars within vehicle records didn't open the employee details. The outdated widget was replaced with a new, supported version, ensuring users can now easily access employee information from vehicle records. This improves the user experience and data accessibility.
Original PR description
**Steps to reproduce:** - Install the Fleet and Employees modules. - Navigate to the Fleet app. - Open any vehicle record. - Click on the employee avatar displayed on the vehicle form. **Issue:** - Clicking on the employee avatar does not open the employee details card. **Cause:** - The currently used widget is outdated and no longer functions correctly. **Fix:** - Replaced the old widget with the new, supported widget. task-5410251
This update fixes a reporting issue in the French P&L reports. The 'owner remuneration' account (644) was incorrectly categorized as 'tax and duties'. This change ensures accurate reporting of wages and salaries for French businesses, aligning with accounting standards.
Original PR description
Account '644 owner remuneration' was in the 'tax and duties' category in the french P&L but it belongs to the 'wages and salaries' category task-5446018 Forward-Port-Of: odoo/enterprise#103214 Forward-Port-Of: odoo/enterprise#103061
This update enhances the security of our expense tracking system by adding a crucial layer of protection during database copies. This ensures that database copies created for support investigations won't inadvertently impact the live production system or customer data, providing a safer environment for troubleshooting.
Original PR description
This commit adds a complement to the neutralization necessary for the hr_expense_stripe module. The main neutralization is handled by the certificates module, but this covers a rare edge case (creation of new accounts in production mode for companies that do not already have an account), and makes the overall neutralization more bullet proof. ---------------------------------------------------------------------- The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. Forward-Port-Of: odoo/enterprise#102702
This update addresses an issue where the Swedish blackbox feature in Odoo would generate tracebacks when receiving non-UTF-8 characters from connected devices. The fix silently ignores these decoding errors, preventing disruptions and ensuring reliable data transmission from serial devices.
Original PR description
If a non utf-8 chracter is returned by a serial-connected device, the supported method of the swedish bb raises a traceback. Forward-Port-Of: odoo/odoo#242114
This update resolves an issue where color fields within editable lists weren't consistently saving changes when using the 'bottom' editing mode. Previously, edits to color fields were lost. This fix ensures that color field changes are now reliably saved when the list is in 'bottom' mode, improving data accuracy and usability.
Original PR description
This commit fixes the issue where editing a field with widget="color" does not save it when the list is in editable="bottom" mode. project.task~5262582 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#238644
This update adjusts how preset options are displayed in the self-order mode, ensuring that available presets are only shown when appropriate (e.g., kiosk or with a table identifier). Previously, a single, unavailable preset was always used as the default. Now, users can see the correct options based on their current context, requiring a slight adjustment to the 'service_at' field for kiosk or mobile menu views.
Original PR description
*: pos_self_order, pos_online_payment_self_order Two things will change with this PR. First, before this commit, when a pos config had only one available preset (and set as default) and this preset…
*: pos_self_order, pos_online_payment_self_order Two things will change with this PR. First, before this commit, when a pos config had only one available preset (and set as default) and this preset was not available in self, this preset was used as the default one. But now, it's not the case anymore. We only use it if, and only if, it is available in self. The second thing was to fix the "Dine In" preset availability in the eating location choices. A dine-in preset is a preset which have service_at == table as attribute. If this preset (is `available_in_self`) and has `service_at === table`, we only show it when there is a table_identifier in the URL or when we are in the kiosk. In all other cases, it'll never be shown. If user wants to see this preset in the kiosk or in the mobile menu without table_identifier, user needs to change the `service_at` field at `counter` (or `delivery`) and put the product as `available in self` as well. task-id: 5190541 enterprise pr:https://github.com/odoo/enterprise/pull/103063 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241739 Forward-Port-Of: odoo/odoo#234522
This update ensures that preset options are only displayed in self-service modes (kiosk, mobile menu) when they are actually available for that specific order type. Previously, a preset would be shown even if it wasn't suitable for self-service. Users may need to adjust product settings to ensure availability in these modes.
Original PR description
*: pos_self_order, pos_online_payment_self_order Two things will change with this PR. First, before this commit, when a pos config had only one available preset (and set as default) and this preset…
*: pos_self_order, pos_online_payment_self_order Two things will change with this PR. First, before this commit, when a pos config had only one available preset (and set as default) and this preset was not available in self, this preset was used as the default one. But now, it's not the case anymore. We only use it if, and only if, it is available in self. The second thing was to fix the "Dine In" preset availability in the eating location choices. A dine-in preset is a preset which have service_at == table as attribute. If this preset (is `available_in_self`) and has `service_at === table`, we only show it when there is a table_identifier in the URL or when we are in the kiosk. In all other cases, it'll never be shown. If user wants to see this preset in the kiosk or in the mobile menu without table_identifier, user needs to change the `service_at` field at `counter` (or `delivery`) and put the product as `available in self` as well. task-id: 5190541 community pr:https://github.com/odoo/odoo/pull/234522 Forward-Port-Of: odoo/enterprise#103099 Forward-Port-Of: odoo/enterprise#103063
This update corrects a minor layout issue in the partnership module. A recent change shifted the grade ID field, and this fix restores it to its original position. This ensures data is displayed correctly and consistently within the system.
Original PR description
The following commit [1] modified the position of the VAT field, which caused the grade_id field to be shifted. So this commit updates the xpath to restore grade_id to its original location. [1]: https://github.com/odoo/odoo/commit/3a56f59d466e72b3bf99f241c479cd3130173b41 task-5461569 Forward-Port-Of: odoo/odoo#242006
This update fixes an issue where Odoo incorrectly processed partner names with only one word. Previously, single-word names resulted in an empty first name field. Now, single-word names are correctly assigned to the first name, ensuring accurate data entry and reporting for partner information.
Original PR description
Description of the issue/feature this PR addresses: The name splitting logic fails when the partner name contains only one word, resulting in an empty first name. Current behavior before PR: Splitting a single-word name returns an empty first name and assigns the word to the last name. Desired behavior after PR is merged: A single-word name is correctly assigned to the first name field, leaving the last name empty. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241926
This update fixes a potential issue where printing failed on Windows systems. By adding a catch-all exception handler, the system now gracefully manages printing errors, preventing disruptions to users. This enhances the overall stability and reliability of the IoT device printing functionality.
Original PR description
This commit adds the try/except block around print_raw method of the virtual iot box to allow catching exceptions when printing on Windows Forward-Port-Of: odoo/odoo#238774 Forward-Port-Of: odoo/odoo#238633
This update resolves a crash that occurred when exporting data from the MRP MPS view. The issue was caused by a recent change that incorrectly pulled data from a related model. Now, the export function correctly displays the expected fields from the 'mrp.product.forecast' model, ensuring data exports work as intended.
Original PR description
Steps to reproduce: - Go to MPS - Select one or more records - Click on Action > Export - Search and expand "Forecasted quantity at date" - Select "Forecasted quantity at date/Minimum to Replenish" - Export Before: A traceback is raised with the following error: "ValueError: Invalid field 'min_to_replenish_qty' on 'mrp.product.forecast'" This is caused by the model being overwritten by "mrp.production.schedule". The regression was introduced by commit ac52882, which added a default model "mrp.production.schedule". After: The export works correctly with sub fields. https://github.com/odoo/enterprise/commit/ac52882891a9ede6a5b008ac39fc62b82b7bf813 opw-5406704 Forward-Port-Of: odoo/enterprise#103097
This update fixes a problem where payments made on the website weren't correctly reflected in the POS. Now, the POS automatically recognizes and accounts for payments made through ecommerce, creating down payment lines and preventing duplicate payments. Users can still create invoices through the standard Odoo Sale app.
Original PR description
Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the…
Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the Quotation/Order menu, but the POS didn't have any reference on the payment, so you would have to create another duplicate payment. Now the amount_paid (which is the amount already paid in transactions) is taken into account when calculating what's left to pay in the POS. So anytime you open a sale order in the POS it should create a down payment line for anything already paid on the website (the same as we were already doing for invoices). Also to avoid double payments, now the sale orders which have been already paid in full, even if they are not invoiced yet, will not show up in the POS. The invoice can still be created normally from the Sale app in Odoo. Task-5138081 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230809
This update resolves a bug that prevented sale orders with zero unpaid amounts from appearing in the POS menu, causing test failures. The change increases the sale order quantity to 1, ensuring the order is visible and the tests can run correctly. This improves the reliability of the POS functionality.
Original PR description
Because of https://github.com/odoo/odoo/pull/230809, it will cause the quotations/orders menu to filter out any sale orders which have an unpaid amount of 0. The test_rental_pos test tries to create a sale order with a quantity of 0 and then settle it in the POS, but because of the filter, the sale order will not show up in the menu causing the test to fail. This PR is to increase the quantity in the sale order to 1 so that the order shows up and the test can be executed properly. Task-5138081 Forward-Port-Of: odoo/enterprise#96876
This update fixes an issue where assigned values in project properties would disappear after saving. The problem stemmed from how the system handled data retrieval, specifically when creating Many2one relationships. The fix ensures that property values are correctly saved and displayed.
Original PR description
**Steps to produce:** - Install project module. - Go to project > Open any project > Open any task > Click on gear icon. - Click on Add properies > Set Field type as `Many2one` and Model as…
**Steps to produce:** - Install project module. - Go to project > Open any project > Open any task > Click on gear icon. - Click on Add properies > Set Field type as `Many2one` and Model as `Contact`. - Now assign value to Property 1 > Click on `External button` > Click on `Save & Close`. **Issue:** - The assigned value disappears after saving. **Root cause:** - At [1], since `id` is not an active field (see [2]), it is not present in record.data, which is expected. However, record.data is then passed to m2oTupleFromData, which assumes that the data includes an id because it is normally used on data coming directly from the ORM. - Additionally, since display_name is also not present, m2oTupleFromData falls back to record.data.name, which is not proper. **Solution:** - Use an ORM read to retrieve the proper display_name of the record before constructing the Many2one tuple. [1]: https://github.com/odoo-dev/odoo/blob/24ccc3faf14ade70b21bf253af16a534df726fc8/addons/web/static/src/views/fields/properties/property_value.js#L87-L89 [2]: https://github.com/odoo/odoo/blob/369ca1e5a154235e80b9ea6af7b3f10442c0939f/addons/web/static/src/model/relational_model/record.js#L793-L795 Before: <img width="589" height="68" alt="bef" src="https://github.com/user-attachments/assets/b2aeba0c-1c52-4663-9f94-5c7808a882db" /> After: <img width="613" height="81" alt="after1" src="https://github.com/user-attachments/assets/a3b3d733-929d-4a24-9e17-c73d9569e9b7" /> **opw-5257819** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240443 Forward-Port-Of: odoo/odoo#238052
This update enhances the preparation display filters in the Point of Sale module, providing more flexible options for managing order preparation. Specifically, it adds multi-select time filters, a multi-select preset filter, and ensures the category filter is always visible, streamlining the process for staff.
Original PR description
- Time filter: * Remove "All" option (now default) * Add "Now" option for unscheduled and next-slot orders * Allow multi-selection - Preset filter: * Add multi-select preset filter * Only shown if related POS configs use presets - Category/Product filter: * Always show pos.category filter (even if no preparation card contains this category) * Move category/product filters below Time and Preset filters task: https://www.odoo.com/odoo/project/1737/tasks/5060221 community PR: https://github.com/odoo/odoo/pull/233920 Forward-Port-Of: odoo/enterprise#103091 Forward-Port-Of: odoo/enterprise#95136
This update removes the document selector from scheduled messages generated for EDI processes (like 'EDI, by Post'). This prevents users from adding attachments to these system-generated messages, aligning with how they're intended to be used. This change supports a new requirement for invoice validation errors before scheduling.
Original PR description
PURPOSE: - This commit makes the document selector invisible on the scheduled messages, which are generated from the account_move_send_wizard, like scheduled messages for 'EDI, by Post' methods. - Because we don't want to allow users to add attachments to such messages, as these messages are system-generated. Related to 'Schedule the send & print invoice' task. Related Community PR: https://github.com/odoo/odoo/pull/210730 Task: 4677423
This update fixes an issue where the recruiter selection dropdown in the Job Position form displayed all company users, regardless of their recruitment access rights. The change now restricts the dropdown to only employees with Recruitment Officer or Administrator roles, ensuring recruiters only see authorized candidates.
Original PR description
#### Issue In Recruitment → Job Position form, the Recruiter dropdown lists all company users, including those without recruiter rights. #### Fix - Replace the `user_id` field in `hr.applicant`, `hr_recruitment_reports`, and `hr.job` with `recruiter` for clarity, using `hr.employee` instead of `res.users`. - Restrict the dropdown to employees whose linked users have the correct recruiter access rights (Recruitment Officer or Administrator). - Update SQL queries accordingly. task-5083125
This update fixes an issue where the recruiter dropdown in job postings displayed users without the necessary permissions. The change now restricts the dropdown to only employees with Recruitment Officer or Administrator roles, ensuring recruiters only see authorized personnel. This improves the efficiency and accuracy of the recruitment process.
Original PR description
#### Issue In Recruitment → Job Position form, the Recruiter dropdown lists all company users, including those without recruiter rights. #### Fix - Replace the `user_id` field in `hr.applicant`, `hr_recruitment_reports`, and `hr.job` with `recruiter` for clarity, using `hr.employee` instead of `res.users`. - Restrict the dropdown to employees whose linked users have the correct recruiter access rights (Recruitment Officer or Administrator). - Update SQL queries accordingly. - Update demo data and replace Marc Demo with Mitchell Admin for consistency with domain condition in recruiter selection. #### Additional - Rename recruiter-related fields/classes/tests to make consistent with the changes from `user_id` to `recruiter_id`. task-5083125
This update fixes a minor issue where job application emails incorrectly displayed 'your applicant' in the subject line. The change now ensures the subject line accurately reflects 'your application,' improving clarity and professionalism for applicants. This ensures a better user experience.
Original PR description
Before this commit, when you applied for a job, the email notification you received incorrectly showed "your applicant" in the subject line (or header) instead of the: "your application." This change fixes that issue by correcting the header name in the email. task-5270293
This update improves the speed of account reports by optimizing how the system checks for specific issues like unknown partners and overdue payments. By streamlining data queries, the reports now run more efficiently, reducing processing times and improving overall system performance. This change focuses on internal improvements to the account reporting module.
Original PR description
* For unknown partner checks, instead of generating the lines twice, perform one query similar to report. * For overdue payable/receivable checks, instaed of building the report to get the `Older` period total, perform a limit query to have same info. * Consider return dates in the action of openning the report. task-5429134
This update resolves a technical issue related to the l10n_gt_edi module, specifically adding a 'neutralization' process. This ensures that database copies created for support investigations are safe and won't unintentionally impact the live production system or customer data.
Original PR description
This commit adds the missing neutralization necessary for the l10n_gt_edi module The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. Forward-Port-Of: odoo/enterprise#102695
This update fixes an issue where newly added buttons in the form editor weren't correctly focused or displayed in the sidebar. The fix ensures a smoother workflow for users creating and editing buttons within the Odoo Enterprise web_studio interface. This improves usability and efficiency.
Original PR description
Have an arch with many conditional button in the header Click on Add a button in the form editor. Before this commit, the new button was not correctly focused and the sidebar did not display the properties of the new button. This was because we gave the wrong xpath coordinates to focus to the editor. After this commit, this flow works as expected task-5364798 Forward-Port-Of: odoo/enterprise#102380 Forward-Port-Of: odoo/enterprise#101059
This update corrects a display inconsistency in promotions where the discount product name was incorrectly linked to the promotion description. This issue stemmed from a technical workaround introduced previously to address an accounting problem. Removing this field ensures accurate discount descriptions are shown to users.
Original PR description
### Issue: Due to this issue, users can change the technical field `discount product` which cause inconsistency in discount description. #### To reproduce: 1- Create a promotion called `AAA`: -…
### Issue: Due to this issue, users can change the technical field `discount product` which cause inconsistency in discount description. #### To reproduce: 1- Create a promotion called `AAA`: - Rules: If minimum 50.0 spent grant 1 point per order - Rewards: 10% discount per order in exchange of 1 point 2- Using debug mode, in promotion's reward view, change the `Description on order` to `AAA 10%`. Save the promotion and you can see the `Discount product`'s name is set to the same description. 3- Create another promotion called `BBB`: - Rules: If minimum 50.0 spent grant 1 point per order - Rewards: 10% discount per order in exchange of 1000 points. 4- In promotion reward's view change the `Discount product` to `AAA 10%` which is promotion `AAA`'s discount product. 5- Change the `Description on order` to `BBB 10%` and save. 6- You can see the name of `Discount product` is changed as well. 7- In promotion `AAA` and you can see the description and the name of `Discount product` mismatch. 8- Navigate to shop, and add a product to cart with a price of more than 50. 9. You can see after applying promotion `AAA` the description from promotion `BBB` is shown. ### Cause: The technical field `Discount product` is never meant to be changed, and this field is introduced for reporting purposes and showing the discount applied in cart. However, this field is added to view in #132857. This is done as a hack to find the `Discount product` created for the promotion, as a workaround for an accounting issue due to adding account to `Discount product`, and originally `discount_line_product_id` was not supposed to be shown or changed through form. After discussion with PO, we decided this field should be removed from the view. Also removing this field will not undo the main fix of #132857, and that workaround was introduced only to find the `Discount product` for that specific client's use case. opw-5229633 Forward-Port-Of: odoo/odoo#240684
Code cleanup and technical improvements
This update standardizes the codebase by replacing outdated references to `odoo.tools._` with the more modern `env._` method within various accounting modules. This change improves code consistency and maintainability across the Odoo accounting system, ensuring a smoother development experience.
Original PR description
`*` includes all the modules related to accounting, including l10n modules PURPOSE - The purpose of this pr is to replace the usage of `odoo.tools._` method with `env._` method from the Environment class in accounting-related module. Related PR: https://github.com/odoo/enterprise/pull/102688 PRs for remaining modules - COM: https://github.com/odoo/odoo/pull/241594 - ENT: https://github.com/odoo/enterprise/pull/103020 Task-5431538
This update standardizes how the accounting modules access core system functions. Previously, the modules relied on a less efficient internal library. This change improves code consistency and maintainability across the entire accounting suite, ensuring smoother future updates and integrations. It impacts several key accounting features.
Original PR description
`*` includes all the modules related to accounting, including l10n modules PURPOSE - The purpose of this pr is to replace the usage of `odoo.tools._` method with `env._` method from the Environment class in account related module. Related PR: https://github.com/odoo/odoo/pull/240704 PRs for remaining modules - COM: https://github.com/odoo/odoo/pull/241594 - ENT: https://github.com/odoo/enterprise/pull/103020 Task-5431538
This update standardizes the use of `env._` instead of `odoo.tools._` throughout the codebase. This improves code consistency and simplifies access to environment-specific data, leading to more maintainable and efficient development. It impacts a wide range of Odoo modules.
Original PR description
`*` includes all the remaining modules other than accounting PURPOSE - The purpose of this pr is to replace the usage of `odoo.tools._` method with `env._` method from the Environment class in every module. Related PR: https://github.com/odoo/enterprise/pull/103020 PRs for accounting modules - COM: https://github.com/odoo/odoo/pull/240704 - ENT: https://github.com/odoo/enterprise/pull/102688 Task-5431538
This update standardizes the use of `env._` instead of `odoo.tools._` throughout various Odoo modules, improving code consistency and simplifying access to environment-specific data. This change enhances maintainability and reduces potential errors related to outdated dependencies. It impacts numerous modules including sales, accounting, and customer support.
Original PR description
`*` includes all the remaining modules other than accounting PURPOSE - The purpose of this pr is to replace the usage of `odoo.tools._` method with `env._` method from the Environment class in every module. Related PR: https://github.com/odoo/odoo/pull/241594 PRs for accounting modules - COM: https://github.com/odoo/odoo/pull/240704 - ENT: https://github.com/odoo/enterprise/pull/102688 Task-5431538
19 changes
Resolved issues and error corrections
A recent update unintentionally removed the ability to sort sale order lines. This fix corrects a technical issue caused by a previous change that prevented sorting. Users can now properly sort their sale order lines, improving order management efficiency.
Original PR description
#### Versions: 19.0+ ### Issue: Sale order line rendered is not sortable anymore like it was in previous versions. #### Steps to reproduce: 1- Create a sale order. 2- Add multiple sale lines. 3- As you see sale lines are not sortable. ### Cause: This is done due to #219253, which has overridden `isSortable` to return `False` on `SectionAndNoteListRenderer`. `SectionAndNoteListRenderer` is a superclass of `SaleOrderLineListRenderer`, which causes it not to be sortable. opw-5407880
This update resolves an issue where filtering a Kanban view with progress bars would lose its state after reopening a related record. The fix ensures that filtered views remain accurate, even after navigating to and from records, maintaining data consistency and a better user experience. This prevents unexpected behavior when updating Kanban records.
Original PR description
Have a kanban view with progressbar and some records. Click on a progressbar to filter a column. Then open a record and come back. From that point, the data of the filtered kanban is in cache. Now,…
Have a kanban view with progressbar and some records. Click on a progressbar to filter a column. Then open a record and come back. From that point, the data of the filtered kanban is in cache. Now, open a record again, and make a change in the form that will have an impact in the kanban (e.g. that will move a record from a column to another). Come back to the kanban view, which will instantly show the data from the cache, and that will be then updated once the rpc returns. At that point, the view is still correct, but the cache callback has already erased the groups information (in particular, the extraDomain of the filtered column). So, if you open a record and come back a last time, the view is no longer correct: the column that is supposed to be filtered displays all records. Introduced by [1] This commit basically reverts [1] and fixes the original issue differently. When we receive the result of a web_read_group, we can trust it and determine that a group for which we receive records (or groups) is open. [1] https://github.com/odoo/odoo/pull/226312 Task~5387553 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
This update fixes a bug in the payroll calculation for Belgium (l10n_be_hr_payroll) that prevented the correct calculation of commission losses during specific contract end scenarios and public holidays. The fix ensures that the correct commission loss logic is executed, leading to accurate payroll processing.
Original PR description
When we enter in the conditions regarding the the end of a contract and the public holidays, it return and does not enter in the part of the code that handle the loss of commission on public holidays. So instead of returning the res, we just continue to the next condition.
This update resolves an issue preventing users from editing the 'test_type_id' field within quality checks when adding steps in the Shop Floor module. This change ensures users can accurately configure quality checks, improving workflow efficiency and data accuracy. It addresses a previously reported restriction.
Original PR description
This commit fixes the problem where the `test_type_id` of the `quality_check` is readonly when adding a step in Shop Floor. Task-5404503
This update resolves a bug that caused Odoo to crash when a user's session data (specifically, the 'persona' information) was missing. The fix ensures Odoo gracefully handles situations where this data isn't available, improving stability and preventing disruptions to user workflows. This change primarily impacts the email and communication features within Odoo.
Original PR description
<img width="889" height="290" alt="image" src="https://github.com/user-attachments/assets/c2519e22-f7c4-4d53-885d-01674b248260" />
This update resolves an issue where product amounts remained at zero after removing optional lines from a Sales Order. The fix ensures that when optional lines are unset, the product quantities and prices are correctly restored, preventing inaccurate order totals. This improves the reliability of sales order calculations.
Original PR description
**Steps to produce:** - Install the `Sales` module. - Create a Sales Order. - Add a section and some products under it. - In the section menu (three dots), click Set Optional. - Again, open the…
**Steps to produce:** - Install the `Sales` module. - Create a Sales Order. - Add a section and some products under it. - In the section menu (three dots), click Set Optional. - Again, open the section menu and click Unset Optional. **Issue:** - After unsetting the optional, the product amounts remain `0`. **Root cause:** - At[1], when setting options, both quantity and price are reset to `0`. - When unsetting optional, only the quantity is restored, leaving the price at `0`. **Solution:** - When unsetting optional, explicitly trigger the onchange on the field `product_uom_qty` using `.update()`. [1]https://github.com/odoo/odoo/blob/27cd0a3fea1b47a85a4f3d397b052bbec08e182b/addons/sale_management/static/src/fields/sale_order_line_field/sale_order_line_field.js#L138-L140 Before: <img width="1198" height="476" alt="image" src="https://github.com/user-attachments/assets/01dee1d6-2870-4222-8a6c-724fbfff8da1" /> After: <img width="1214" height="453" alt="image" src="https://github.com/user-attachments/assets/63ed4eb4-27cf-4b15-a957-c28a46a3ca42" /> opw-5368488 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug that prevented users from exporting data from the MRP MPS view. The issue stemmed from a recent change that incorrectly pulled fields from a related model. Now, exporting data from the MPS view functions correctly, ensuring accurate data export for forecasting.
Original PR description
Steps to reproduce: - Go to MPS - Select one or more records - Click on Action > Export - Search and expand "Forecasted quantity at date" - Select "Forecasted quantity at date/Minimum to Replenish" - Export Before: A traceback is raised with the following error: "ValueError: Invalid field 'min_to_replenish_qty' on 'mrp.product.forecast'" This is caused by the model being overwritten by "mrp.production.schedule". The regression was introduced by commit ac52882, which added a default model "mrp.production.schedule". After: The export works correctly with sub fields. https://github.com/odoo/enterprise/commit/ac52882891a9ede6a5b008ac39fc62b82b7bf813 opw-5406704 Forward-Port-Of: odoo/enterprise#103097
This update resolves a minor issue impacting the accuracy of account reports within the MRP module. The changes include re-enabling tests for related modules, ensuring the continued reliability of financial reporting and calculations. This improves the overall stability of the enterprise version.
This update fixes a bug where resizing images within website pages broke responsiveness on smaller screens (like mobile). The change ensures images adapt correctly to different display sizes, preventing overflow and maintaining a consistent user experience across devices. This improves the visual quality and usability of our website content.
Original PR description
Problem: On website pages, resizing an image using the transform option breaks responsiveness across display sizes. After resizing on desktop, the image may overflow its container on smaller screens. Cause: The resize logic currently sets both width and height in `px`. Once fixed in pixels on a large screen, the image no longer adapts when the responsive container becomes smaller on mobile. Solution: Use a percentage value for `width` and set `height` to `auto`. This preserves responsiveness while keeping the aspect ratio correct. Using `height: auto` is required because setting both width and height in percentages would still ignore height in practice. Steps to reproduce: - Add a card snippet to a website page. - Resize the image. - Switch the display mode to mobile. - Observe that the image is no longer responsive. opw-5368040 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where pressing 'shift+space' in the kanban view initially caused a system error. Now, users can reliably select kanban records using this keyboard shortcut, improving usability and workflow efficiency.
Original PR description
Before this commit: When navigating the kanban view using the keyboard, pressing `shift+space` for the first time to select a kanban record caused a traceback. After this commit: The traceback no longer occurs, and the kanban record is correctly selected. task-5410164 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a critical issue in the l10n_gt_edi module by implementing a 'neutralization' process. This ensures that database copies created for support investigations won't unintentionally impact the live production database or customer data. It allows for safer troubleshooting and duplicate database analysis.
Original PR description
This commit adds the missing neutralization necessary for the l10n_gt_edi module The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. Forward-Port-Of: odoo/enterprise#102695
This update resolves an issue where zooming out on the version timeline caused other versions to disappear. It also addressed the appearance of a vertical scrollbar when zooming in. The fix ensures all versions are visible and scrollable without a sidebar, providing a smoother user experience.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: . When you zoom-out below 100%, the other versions from the version bar disappear, leaving only the active one . Wen zoom-in, a side vertical scrollbar appear Desired behavior after PR is merged: . all versions on timeline appears normally without sides scrollbar task-5401380
This update fixes a problem where incorrect error messages were displayed when creating employees with negative fixed allowance values. The fix isolates error handling to payroll validation, ensuring users receive the precise error message related to their allowance data. This improves data accuracy and simplifies the employee onboarding process.
Original PR description
Issue: * When creating an employee with negative fixed allowance values, the system should show a payroll validation error. * Instead, a leave-related error from hr_holidays always appeared because the module wrapped the entire create() method in a broad try/except, catching all ValidationError messages including those from payroll. Fix: * Restricted the try/except only to the part that actually creates a new leave entries. Impact: * Users now see the correct and relevant error message when the fixed allowance values are invalid. task-5383700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects inconsistencies in how stock valuation is calculated, particularly related to manufacturing and subcontracting processes. Specifically, it re-enabled tests for stock valuation in manufacturing, ensuring accurate accounting for finished goods and resolving issues with incorrect value computations. This improves the reliability of financial reporting.
Original PR description
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
This update fixes an issue where Odoo incorrectly processed partner names with only one word. Previously, single-word names resulted in an empty first name field. Now, single-word names are correctly assigned to the first name, ensuring accurate data entry and reporting for customer information.
Original PR description
Description of the issue/feature this PR addresses: The name splitting logic fails when the partner name contains only one word, resulting in an empty first name. Current behavior before PR: Splitting a single-word name returns an empty first name and assigns the word to the last name. Desired behavior after PR is merged: A single-word name is correctly assigned to the first name field, leaving the last name empty. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241926
This update fixes an issue where one-day time off requests were incorrectly displayed as multi-day events in the Calendar app. The fix ensures that single-day leaves are accurately represented, resolving a visual inconsistency for users in specific time zones like Los Angeles. This improves the accuracy of employee schedules.
Original PR description
**Issue:** Single-day time off requests appear as multi-day events in the Calendar app when using certain tim> **Cause:** The `_compute_date_from_to()` method converts user-specified dates to UTC.…
**Issue:** Single-day time off requests appear as multi-day events in the Calendar app when using certain tim> **Cause:** The `_compute_date_from_to()` method converts user-specified dates to UTC. https://github.com/odoo/odoo/blob/028e7228cb830e47a9726bef4c82793ba4590cd5/addons/hr_holidays/models/hr_leave.py#L316-L317 The `_prepare_holidays_meeting_values()` method then uses these UTC datetime values (`holiday.date_from`, `holiday.date_to`) In Los Angeles timezone, and for a one day leave on september 17 2025 this leads to: - holiday.date_from: September 17, 2025 at 03:00 UTC - holiday.date_to: September 18, 2025 at 12:00 UTC causing a single-day leave to be displayed as a two-day event. **After fix:** - start_value: September 17, 2025 at 12:00 - stop_value: September 17, 2025 at 11:59 **Steps to Reproduce:** 1. Set the user timezone to "America/Los_Angeles" 2. Set the browser timezone to the same timezone 3. Create a one-day time off request (e.g., September 17, 2025) 4. Open the Calendar app: the event spans across two days opw-4744817 Forward-Port-Of: odoo/odoo#231662 Forward-Port-Of: odoo/odoo#224298
This update resolves errors identified during testing of the l10n_hr_edi module's flow processes, ensuring consistent functionality with the Odoo 19.0 release. It also corrects a specific SQL query issue, improving the stability and reliability of the HR EDI integration.
Original PR description
- Fixing runbot errors raised by the flow tests, consistent with 19.0+ version - Fixing neutralize.sql runbot-237635 runbot-237637 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242007
This update fixes a potential issue where printing errors on Windows could cause unexpected problems. By adding a safety net to catch these errors, the system is now more stable and reliable when printing, particularly on Windows devices. This ensures a smoother user experience for printing operations.
Original PR description
This commit adds the try/except block around print_raw method of the virtual iot box to allow catching exceptions when printing on Windows Forward-Port-Of: odoo/odoo#238774 Forward-Port-Of: odoo/odoo#238633
This update resolves an issue where file attachments added to Odoo activities (like project tasks) weren't visible after saving. The fix ensures attachments are correctly displayed with download links in the activity chatter, improving usability and allowing users to access attached files seamlessly.
Original PR description
**Description of the issue/feature this PR addresses:** In Odoo 19, file attachments added to activities (for example, on Project Tasks) were not visible after saving the activity. Although the…
**Description of the issue/feature this PR addresses:** In Odoo 19, file attachments added to activities (for example, on Project Tasks) were not visible after saving the activity. Although the attachment was correctly stored, it was not rendered in the activity chatter. The root cause was that the activity note containing the embedded attachment placeholder `(<span data-embedded="file">) `was rendered as raw HTML, bypassing the HtmlViewer logic that mounts embedded file components. As a result, the attachment card and download link were missing from the UI. **Current behavior before PR:** Attachments can be added to an activity and are saved correctly. After saving the activity: * The attachment card is not displayed. * No download link appears in the activity chatter. * The activity note is rendered as raw HTML, so embedded file components are never mounted. **Desired behavior after PR is merged:** * Attachments added to activities are correctly displayed after saving. * The attachment card and download link appear in the activity chatter. * Activity notes are rendered using the HtmlViewer component, ensuring embedded files are properly mounted and displayed. **Related issue** Closes #238967 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
4 changes
Resolved issues and error corrections
This update corrects a visual issue with the carousel's indicator display, specifically when using 'Numbers' as the indicator style. The previous design used incorrect colors, making the numbers unreadable and misaligned. This change ensures indicators are properly sized and colored, and that the 'next' and 'previous' buttons align correctly with the carousel slides.
Original PR description
The css rules for indicators outside the carousel were not adapted for number indicators, and used the button color intended for dots and bar as background of the numbers, making them unreadable and ugly. The height of the indicators when outside influences the margin needed to align the bottom of the prev/next buttons. That caused the bottom of the next/prev buttons to not reach the bottom of the slide with "Numbers" or "Hidden" as indicators. This commit adds the necessary css rules to correctly size and colors the number indicators (and the hidden one) when positioned outside. Steps to reproduce - Add a carousel - Set "Indicators" to "Numbers" - Set "Style" to "Indicators outside" - Bug: The colors are all wrong, we cannot see the numbers - Bug: The bottom of the previous/next buttons do not reach the bottom of the carousel - Set "Indicators" to "Hidden" - Bug: The bottom of the previous/next buttons is even further from the bottom of the carousel task- 5358507
This update ensures that delivery carriers set on pickings are consistently propagated to subsequent transfers, regardless of how the carrier was initially defined (sale order or manually). This change addresses a previous limitation where carrier settings weren't automatically applied in multi-step delivery flows, now supporting carrier selection managed by logistics teams.
Original PR description
Issue Before This Commit: ================================ Previously, the delivery carrier was only propagated between pickings when it was set from the sale order. If the carrier was manually set…
Issue Before This Commit: ================================ Previously, the delivery carrier was only propagated between pickings when it was set from the sale order. If the carrier was manually set on a picking (e.g., during the packing step in a multi-step delivery flow), it was not propagated to the consequent pickings, even when the stock rules had `Propagation of carrier` enabled. Steps to reproduce: ================================ 1. Activate Multi-Step Routes and Delivery Methods. 2. Configure a 3-step delivery route in the warehouse and enable Propagate Carrier on all rules. 3. Create a sale order with a product but without setting a delivery carrier. 4. Confirm the sale order to generate picking. 5. On the first picking (i.e., pick), manually set a delivery carrier (e.g., Local Delivery) and validate. 6. On the next transfer (i.e., pack), observe that the delivery carrier is not propagated. After this commit: ================================ The delivery carrier set on any picking is propagated to subsequent transfers when the corresponding stock rule has `Propagation of carrier` enabled and no carrier is already configured on the next picking. This ensures consistent carrier propagation across all routing configurations (all pull rules, all push rules, and mixed push/pull flows), even when the carrier is configured at the picking level rather than on the sale order. This behavior is required because, in many business scenarios, carrier selection is managed by the logistics team rather than the sales team. task-4454313
This update prevents the loss of Starshipit orders when label creation fails during delivery validation. Previously, a failed label attempt would delete the order, disrupting the validation process. Now, users can retry validation without losing existing orders, streamlining the delivery workflow.
Original PR description
## Current behaviour: When validating a delivery, Odoo sends data to Starshipit. If label creation fails, the module deletes the created order. ## Expected behaviour: If label creation fails, the…
## Current behaviour: When validating a delivery, Odoo sends data to Starshipit. If label creation fails, the module deletes the created order. ## Expected behaviour: If label creation fails, the Starshipit order should remain. Users should be able to fix data in Starshipit and retry validation in Odoo without losing the existing order. ## Steps to reproduce: 1. Validate a delivery order integrated with Starshipit. 2. Trigger a label generation failure (e.g., bad address). 3. Observe that the created Starshipit order is deleted. ## Cause of the issue: The integration treats label creation failure as a fatal step and cleans up the previously created Starshipit order. ## Fix: Do not delete the Starshipit order on label failure. When the user retries validation, first check Starshipit for an order matching the unique reference. If found, reuse it and continue with label creation and manifest. If not found, create a new Starshipit order as usual. ## Additional note: The _() wrapper in the error line was removed because the Starshipit service has no env or language context. Since translations cannot be resolved there, Odoo raised a warning. Removing _() avoids this warning and keeps the error clean. opw-5306979
This update fixes a layout issue that occurred when tax group names were too long, preventing the tax totals component from displaying correctly. The change adds text wrapping to the tax group labels, ensuring a clean and readable interface for users.
Original PR description
When tax group names or tax-related content are too long, they break the layout of the tax totals component, causing display issues and making the interface difficult to read. This change adds the…
When tax group names or tax-related content are too long, they break the layout of the tax totals component, causing display issues and making the interface difficult to read. This change adds the Bootstrap `text-wrap` class to the tax group label to enable text wrapping, ensuring that long content is properly contained within the table cell and the layout remains intact. The `text-wrap` utility class applies `word-wrap: break-word` and `word-break: break-word`, which allows long text to wrap to multiple lines instead of overflowing and breaking the table layout. Before: <img width="1920" height="868" alt="image" src="https://github.com/user-attachments/assets/cdf770ca-a586-487e-9283-45463ef4dc0e" /> After <img width="1920" height="793" alt="image" src="https://github.com/user-attachments/assets/24b9781c-d209-4a69-824c-13a59a8c9bc7" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240658
1 change
Resolved issues and error corrections
This update resolves a bug that prevented users from canceling the selection of an employee photo within the Salary Configurator. The fix ensures the system correctly handles image uploads and cancellations, improving the user experience and preventing potential errors. This change ensures smooth operation of the employee contract generation process.
Original PR description
**Version:** - 17.0 **Steps to reproduce:** - Install the hr_contract_salary module. - Go to Employee contract and click the Generate Offer. - Click on 'Send By Email' button and open Salary Configurator. - Upload an employee photo the first time. then cancel the image selection the second time. **Issue:** - Error occurs when canceling the image selection on Salary Configurator page. **cause:** - The condition to check whether the file exists properly was missing. **solution:** - Added the missing condition to properly check that file exist. Task-5423390