Daily updates from Odoo
Friday, April 3, 2026
55 changes · saas-19.1
New functionality added to Odoo
This update introduces a new module for Romania to comply with SAFT (Simplified Fiscal Transparency) reporting requirements. Specifically, it focuses on generating the 'On Demand' XML file needed to submit inventory valuation data to the Romanian tax authority (ANAF). This ensures accurate financial reporting for Romanian businesses using Odoo.
Original PR description
Baiscally the SAFT for Romania consists of 3 xml files to submit. This commit focuses on the "On Demand" xml to submit, consisting in the inventory valuation of of the company. File with fields and value to export can be found here: https://www.anaf.ro/anaf/internet/ANAF/despre_anaf/strategii_anaf/proiecte_digitalizare/saf_t/ task-3748978 Forward-Port-Of: odoo/enterprise#95540
This update adds missing language translations for the website appointment and account payment modules in multiple languages. This ensures that Odoo Enterprise is accessible and usable for a wider global audience, improving the user experience for international customers.
Original PR description
Related: https://github.com/odoo/odoo/pull/254667 Forward-Port-Of: odoo/enterprise#112909 Forward-Port-Of: odoo/enterprise#111141
This update adds support for Peppol Business Level Responses (BLR) for invoices and credit notes, ensuring compliance with Peppol standards. It allows Odoo to correctly respond to documents received through Peppol, improving integration with international trade partners. This change also incorporates responses for Nemhandel, a related system, with simplified response types.
Original PR description
Peppol offers a response system to the document received through it. These are called Business Level Responses, and their documentation can be found here:…
Peppol offers a response system to the document received through it. These are called Business Level Responses, and their documentation can be found here: https://docs.peppol.eu/poacc/upgrade-3/profiles/63-invoiceresponse/#introduction-to-openpeppol-and-bis The specific BLR implemented in this commit is targeted to invoices and credit notes. 3 types of responses are mandatory for a Peppol participant to correctly adhere to the BLR service: acknowledgement (different to the transport ack), confirmation and rejection. More response's types are available but were not implemented as they're not mandatory/needed (for now). For rejection, a list of at least one reason must be given, and actions can be suggested to the sender of the document for the eventual next invoice shipment. Same principle goes for Nemhandel, with some differences: only 2 responses, BusinessAccept and BusinessReject (no Acknowledgement, and no reasons are needed in case of rejection. Instead, the user can send a string message. iap PR: https://github.com/odoo/iap-apps/pull/1364 task-5237698 Forward-Port-Of: odoo/odoo#243191
This update incorporates missing language files (.po files) for various Odoo modules, improving the software's support for multiple languages. This ensures a better user experience for customers and partners who speak languages other than English. The changes are part of ongoing efforts to expand Odoo's global reach and localization.
Original PR description
Related: https://github.com/odoo/enterprise/pull/111141 Forward-Port-Of: odoo/odoo#257415 Forward-Port-Of: odoo/odoo#254667
Enhancements to existing features
This update makes it easier to upsell non-recurring products when the start date aligns with the next invoice date. The change extracts a key constraint, allowing for greater flexibility in subscription upgrades. It also resolves a potential error related to zero prorata ratios, ensuring accurate invoicing and order processing.
Original PR description
Make easy for module that extend sale subscription to allow for some specific case to upsell subscription with start_date = next_invoice
Resolved issues and error corrections
This update fixes an issue where the AI system was logging user-generated errors as system errors, hindering debugging. The change prevents logging `UserError` exceptions, allowing developers to focus on genuine system problems and improving response generation reliability. This ensures more accurate error tracking for AI interactions.
Original PR description
Currently, while generating an AI response, a `UserError` raised due to a `RequestException` from the AI agent request at line [1] is caught and logged as an error. This happens because the exception…
Currently, while generating an AI response, a `UserError` raised due to a `RequestException` from the AI agent request at line [1] is caught and logged as an error. This happens because the exception is raised inside the except block of the `/ai/generate_response` controller at line [2], including `UserError` raised from line [1]. Since this controller is of type `http`, exceptions are not propagated directly; instead, they are logged and the response is returned. This commit ensures that an error is raised only if the exception is not a `UserError`. By using `isinstance`, we prevent logging `UserErrors`, allowing developers to focus on actual system errors rather than expected (user-generated) errors, making debugging more effective. [1]: https://github.com/odoo/enterprise/blob/d2dcdb892ac5dcc1af87d11f32abadbeb8029c3e/ai/utils/llm_api_service.py#L322 [2]: https://github.com/odoo/enterprise/blob/d2dcdb892ac5dcc1af87d11f32abadbeb8029c3e/ai/controllers/thread.py#L104 Sentry-5691330773
This update fixes an issue where rejecting a POS order could trigger duplicate kitchen ticket printing. The fix prevents this by ensuring the print token is properly managed during order rejection, streamlining the process and reducing potential errors. This enhancement improves order fulfillment reliability.
Original PR description
Bug fix: - Prevent duplicate kitchen ticket printing on order rejection. When a user rejects an order, the reject RPC triggers a webhook that calls _fetchPlatformOrder on all devices. This led to deleteOrders being called twice (once by the reject flow, once by the webhook). Fix: claim the print token via mark_platform_prep_order_as_printed in _rejectOrder before sending the reject RPC, so no device gets isReadyToPrint=true from the webhook. - Preparation needs to be sent after PoS accepts the order. ticket-6071740 Forward-Port-Of: odoo/enterprise#112277
This update resolves an issue preventing the export of Profit & Loss reports with footnotes in the Luxembourg localization. The previous export process relied on an outdated model, which has now been corrected to use the current, supported model for footnote references. This ensures reports can be correctly exported to XML format.
Original PR description
**Steps to reproduce:** * Install the **l10n_lu_reports** module. * Go to **Accounting → Reporting → Profit & Loss**. * Add a footnote on a report line (**⋮ → Annotate**). * Click **Export (XML)** to open the export wizard. * Enable **Import notes as references** and export. **Observed behavior:** * Export fails with `KeyError: 'account.report.manager'`. * XML file cannot be generated when references are enabled. **Cause:** * The export logic relied on the deprecated `account.report.manager` model. * This model was removed in v17([commit](https://github.com/odoo/enterprise/pull/33604/changes#diff-5fc5051f5c0211c0eec96b892e7d29e01b68d804417443502d17bccd8333d7ecL41)) and replaced by `account.report.footnote`. * The footnote retrieval code was not migrated accordingly. **Fix:** * Migrate reference retrieval to use `account.report.footnote`. opw-5890630 Forward-Port-Of: odoo/enterprise#112394 Forward-Port-Of: odoo/enterprise#107765
This update ensures that LNA (long polling) is correctly configured for POS printers, regardless of whether an IoT payment terminal is being used. Previously, LNA setup was only automatic for IoT printers. Now, the system intelligently guesses the user's preference for LNA based on printer settings, improving reliability and functionality.
Original PR description
If we use an IoT payment terminal with an ePOS printer and check LNA on the printer record, we never setup LNA for the `longpolling`, as it's only done if we check LNA on the printer model with type "IoT". We now guess the user wants to use LNA with his terminal if he sets it up on any printer type.
This update fixes an error preventing Intervat from properly verifying Odoo's requests. The issue stemmed from outdated JWK keys being hidden from Intervat, causing authentication failures. A simple timeout addition was implemented to ensure Intervat can consistently verify signatures.
Original PR description
When we open a connection in intervat, we initialize a JWK on IAP side,
then we use the private key linked with this JWK to sign our requests.
The problem is on IAP, we have a cron who archive JWK older than a week.
As the archived JWK are hidden in our JWKS endpoint, Intervat is no
longer capable of verifying our signatures, leading to this error:
`{"error_description":"JWT is not valid" "error":"invalid_client"}`.
To fix this, we might need to call IAP first to unarchive the JWK first.
no-task
Forward-Port-Of: odoo/enterprise#112719This update addresses a warning displayed on payslips when GOSI (Government of Saudi Arabia) payroll contributions are zero. The change ensures that a warning message is shown in the correct circumstances, improving payroll accuracy and compliance reporting. This is a minor improvement to the payroll process.
Original PR description
[IMP] l10n_sa_payroll: GOSI integration warning When all of the GOSI contributions are 0, I showed warning in payslip task - 6032714
This update removes a confusing purple pill that appeared on mobile devices when using Web Studio's approval features. This change simplifies the user experience for mobile users, preventing accidental clicks on the pill and ensuring a smoother workflow. It addresses a usability issue reported by users.
Original PR description
Steps: - Install `web_studio` - Add an approval rule to any action in any form view (example preview button) - Open this form view - You will have a purple info pill in every action button in the form view This can be confusing for people wanting to click on the button on mobile but instead, they click on the purple pill + we don't even want this opw-5911667 Forward-Port-Of: odoo/enterprise#111770
A bug causing access errors when creating new stations or visitors within the Frontdesk module for users without employee access rights has been fixed. This update ensures Frontdesk functionality works correctly for all users, regardless of their employee permissions. The fix involved updating the Frontdesk module to align with a recent Odoo update.
Original PR description
Issue: ---------------------------------------- When a user with administrator rights on frontdesk but no rights on employees try to create a new station or visitor, they get an access error. Steps to reproduce: ---------------------------------------- - Have a user with administrator rights on Frontdesk but no rights on Employees - Switch to this user - Open Frontdesk and try to create a new station - Access Error Cause: ---------------------------------------- Since [this commit](https://github.com/odoo/odoo/commit/71f662b827b58c4f8ed1260728dc5194201ec323) models having a many2many field on `hr.employee` must inherit from `hr.mixin` to avoid an access error. The Frontdesk module was not changed. Solution: ---------------------------------------- Make `frontdesk.visitor` and `frontdesk.frontdesk` inherit `hr.mixin` opw-6000417 Forward-Port-Of: odoo/enterprise#110084
This update resolves an issue where the LPP (Labor Pension Plan) was incorrectly applied to employee salaries in the Swiss payroll module when employees were not covered by insurance. The fix ensures that LPP contributions are only applied to insured employees, aligning with Swiss tax regulations and improving payroll accuracy. This change enhances the reliability of the Swiss payroll reporting.
Original PR description
Forward-Port-Of: odoo/enterprise#112824
This update ensures that the Odoo Enterprise system uses the correct method, `get_str`, for retrieving configuration parameters. This change, made during a forward port, resolves an inconsistency and improves the stability of the l10n_be_intervat module. It’s a minor technical adjustment that supports ongoing system updates.
Original PR description
Since 19.1, ir.config_parameter.get_param is replaced by get_str. This commit fix a mistake I made in the forward port of https://github.com/odoo/enterprise/pull/112719 no-task
This update resolves an issue preventing proper product exports from the Web Studio interface. The change involved decoupling a key process, and this commit adds the necessary context to ensure product templates are created correctly. This improves the reliability of product export functionality.
Original PR description
This commit https://github.com/odoo/odoo/pull/254323 changed the way product( template)s are created, which now decouples the logic into two context attributes instead of one. This commit fixes this by adding the second one. Forward-Port-Of: odoo/enterprise#112753
This update corrects a bug where discounts were applied twice to service tasks, resulting in incorrect pricing. The fix ensures discounts are applied correctly based on sales order settings, preventing over-discounting and ensuring accurate pricing for service tasks. This improves the reliability of pricing calculations for field service operations.
Original PR description
Currently, when the user creates a task for a customer with a discount pricelist, the discount is applied twice for the service. <h2>Steps to produce:</h2> * Install `industry_fsm_sale` and enable…
Currently, when the user creates a task for a customer with a discount pricelist, the discount is applied twice for the service. <h2>Steps to produce:</h2> * Install `industry_fsm_sale` and enable `Discounts` and `Pricelists` in settings. * Create a pricelist with a price rule of type discount that applies 10 percent discount to every product. * Go to Customers > Acme Corporation > Sales & Purchase and set the pricelist. * Go to Field Service > Create a Task, and set `Customer` to Acme Corporation. * Add a timesheet with Time Spent 1 > Mark the task as Done > Sale Order <h2>Observed behavior:</h2> The discount is applied twice to the product on SO: **Product**: Service on Timesheets **Unit Price**: `$40` (excluding tax) **First discount:** The 10 percent discount on the unit price of the product. Product unit price is set from `$40 -> $36 ` **Second discount:** The 10 percent discount on the SO line itself. `$36 -> $32.4 ` The untaxed amount is: `$32.40` which should be `$36.00` <h2>Root cause:</h2> This happens because, at line [1], the unit price is already set to the final price from the pricelist when the sale order line is created. Since discounts are enabled, [2] applies an additional discount to that same price, causing the discount to be applied twice. <h2>Solution:</h2> When creating the sales order: * **Discount setting is on:** use list price so the discount is applied from the sales order. * **Discount setting is off:** set the product unit price to the discounted price. [1]- https://github.com/odoo/enterprise/blob/224d2453cc975a3e333825370beaf30d27d89f10/industry_fsm_sale/models/project_task.py#L658 [2]- https://github.com/odoo/odoo/blob/76717e588bfd012b42e859bfc829257d899c6165/addons/sale/models/sale_order_line.py#L788 opw-5432088 Forward-Port-Of: odoo/enterprise#112761 Forward-Port-Of: odoo/enterprise#103950
This update fixes an issue where invoices sent to the Colombian DIAN tax authority were incorrectly flagged as duplicates, leading to rejection. The fix prevents a rollback process from interfering with the correct invoice acceptance status, ensuring invoices are properly recorded by DIAN.
Original PR description
Steps to reproduce:
- Send a Colombian DIAN invoice (SendBillSync flow)
- Simulate a non-200 response from the DIAN GetStatus endpoint during the call of _get_attached_document (see ticket)
Issue:
The invoice is accepted by DIAN but the state is never written. When trying to send the invoice a second time DIAN rejects the invoice as a duplicate (already submitted).
Cause:
`_get_response_history` returns `("", error_msg)` on non-200 status_code and when calling `_get_attached_document`
-> error and rollback and `invoice_accepted` is not written correctly
opw-5919395
Forward-Port-Of: odoo/enterprise#111186This update fixes a limitation in the bank reconciliation process. Previously, tax lines set to 'reconcilable' could not be manually unmatched, even when necessary. Now, users can unmatch these lines if they are successfully reconciled, improving flexibility and accuracy within the bank reconciliation workflow.
Original PR description
In the bank reconciliation widget, tax lines are protected from unreconciliation to maintain tax integrity. However, when the tax account is set as reconcileable the user may need to manually unmatch transactions. Steps to reproduce: - Open the 'Tax Paid' account and enable 'Allow Reconciliation' - Create a bill using a tax and post it - Go to the Bank Reconciliation widget - Select a statement line and match it with the tax line from the bill Issue: The line cannot be unmatched because the related button is missing opw-5871821 Forward-Port-Of: odoo/enterprise#112312 Forward-Port-Of: odoo/enterprise#110186
This update resolves an issue preventing correct translation of appointment details when 'Allow Guests' is enabled. The fix adjusts a regular expression to properly handle newline characters within the translation editor, ensuring accurate translations are displayed. This improves the user experience for appointments with guest options.
Original PR description
When we are at the appointment details page, and have the option allow_guests turned on, and go to the editor for translation, we encounter the issue. Steps To Reproduce: 1. Create an appointment. 2.…
When we are at the appointment details page, and have the option allow_guests turned on, and go to the editor for translation, we encounter the issue. Steps To Reproduce: 1. Create an appointment. 2. Go to the "Options" tab, and click on "Allow Guests". 3. Go to the web page for the appointment, select the data and time. 4. Now, on the details page, go to any other language than the default, and click on edit/translate. 5. The issue occurs. The issue occurs when the regex tries to match the placeholder where the guests are added, which is enabled by the allow_guests. It contains strings with newline characters. The regex fails to take into consideration for these newlines and breaks causing the issue to appear. To fix the issue, we'll use regex to account for the new lines. Also the fix adapts [this commit](https://github.com/odoo/odoo/commit/bc30d2592d4a7913eddf30bac8be2d94b6c22ad4) to work with the [website refactoring](https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2) opw-5412775 Forward-Port-Of: odoo/odoo#249195
This update corrects a visual glitch on mobile devices where the 'Products' snippet would jump unexpectedly when scrolling. The fix removes a setting that caused the snippet to repeatedly re-render, leading to inconsistent display heights. This ensures a smoother and more reliable user experience across different screen sizes.
Original PR description
Scenario: - add the dynamic Products snippet on top of page and save - go to the website with browser address bar that change height when going when going down in the page (hide or change size of it…
Scenario: - add the dynamic Products snippet on top of page and save - go to the website with browser address bar that change height when going when going down in the page (hide or change size of it that is changing the viewport size) - scroll all the way up and down in the page Result: there is some jump that happen when the browser interface change size when scrolling down or up. Cause: When going down the page, the viewport size changes (because the address bar gets bigger / smaller). This causes the dynamic snippet to be re-rendered. Since February 2026 commit 2e5bd409581ddaab28084c42ab51b50b494f4876 to optimize performance, product blocks are only rendered when the are in the viewport (may depends on browser) with "content-visibility: auto". The combination of those two things, causes that if you scroll down, the widget is re-rendeded in owl, but it is only rendered in the page once you scroll in the viewport so the scroll jump up or down with the products snippet being rendered (going from 0 to eg. 300px when scrolling into viewport) or not being rendered (going from eg 300px to 0 when scrolling and the widget not being in viewport). Fix: remove the "content-visibility: auto" when we are in the dynamic "Products" snippet, it was intended for the shop view and not for the case where product block can be re-rendered outside of viewport. opw-6005340 Note: this is mainly happening on mobile browser (eg. safari on iOS) because of the viewport resize when scrolling, but this can somehow be reproduced on chrome desktop: - scroll below a "Products" snippet, change browser window size manually => the should be a jump of the content up - scroll up to go back to the product snippet => the content of product snippet should appear all at once when the 0 pixel heigh get in the viewport Forward-Port-Of: odoo/odoo#256815
This update introduces a setting to disable the automatic delay translation feature for website content. Currently, changes to a website's primary language trigger updates in secondary languages, which can be disruptive for users. This new option provides control to users who don't require this behavior, simplifying website editing.
Original PR description
Delayed translation (draft version from change of main language that needs to be updated on each modified secondary language) on website were added or disabled with: -…
Delayed translation (draft version from change of main language that needs to be updated on each modified secondary language) on website were added or disabled with: - 2d08f97c0778469b409fca23f2be5f5a98ce3df8 (October 2023) in 17.0 added the delay translation feature - 0e0a74f8c5fc9f45311e629a76608c6c986d635d (December 2023) in 17.0 disabled the feature - 03a85b13b2c46ef7174123d902e95d5103031c6c (September 2025) in 19.0 enabled the feature again Some website editor users may not expect the behavior (eg. changing a background image, then needing to edit all secondary language so the drafted change is saved). For now we have not found a satisfying way to prevent delay translation for simple use case that should not break translations: eg. removing a snippet, changing attributes, ... Because if we did special case, it would then become unexpected: - will we need to update translations - if there was a previous change that needed translation update, then we do a change that would not need translation update, what should we do So this PR for now gives the option to create a ir.config_parameter: - key: website.disable_delay_translations - value: 1 That would disable the delay_translations feature for all websites if the user doesn't want the feature. opw-5187670 opw-5240423 opw-5250497 opw-5254832 opw-5344412 opw-5347408 opw-5419427 opw-5424761 opw-5481352 opw-5892371 opw-5931549 Forward-Port-Of: odoo/odoo#243490
This update fixes an issue where Ctrl+A and Delete wouldn't remove all content from editable areas, specifically when the first element was non-editable. Now, text editing works correctly across all editable content, ensuring a smoother and more reliable editing experience. This improves the overall usability of the HTML editor.
Original PR description
Description of the issue this PR addresses: - When an element with `contenteditable="false"` is the first node in the editable, pressing Ctrl+A followed by Delete does not remove the entire selection and instead deletes only the last character. Desired behavior after PR is merged: - Ensure that the selection is anchored to the deepest editable position when performing a select-all operation so that the full editable content is correctly selected and removed. Steps to reproduce: - Insert a toggle list using `/togglelist` in a new todo - Add one or more paragraphs below it and enter some text - Select all content using Ctrl+A - Press Backspace to delete the selection - Observe that only the last character is removed Backport of: 67e6a617def3bf4f9eb6b63b0850f5cfc773bccc task-5363926 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248601 Forward-Port-Of: odoo/odoo#241696
This update fixes a display issue in Odoo's error messages related to VAT validation. Previously, the generic term 'VAT' was used regardless of the country, leading to unclear error messages. Now, the correct VAT label for each country is displayed, improving user understanding and troubleshooting.
Original PR description
Before this **PR**, instead of the VAT label of each country, 'VAT' appeared in the error message. This was due to a mismatch in the matching of country codes. Forward-Port-Of: odoo/odoo#257030
This update corrects a visual issue on the wishlist page where the 'Contact Us' button appeared misaligned across different product designs. The fix ensures a consistent and professional look for all users, regardless of the chosen product display style. This improves the overall user experience and brand consistency.
Original PR description
Steps to produce: --- - Install `website_sale` module. - From the settings, enable `Prevent Sale of Zero-priced Products`. - Create a product with a sale price of `0` and publish it. - From the…
Steps to produce: --- - Install `website_sale` module. - From the settings, enable `Prevent Sale of Zero-priced Products`. - Create a product with a sale price of `0` and publish it. - From the website, open the product page and add the product to the wishlist. - Open the wishlist page. - Enable the editor and change the product design to Chips, Cards, or Grid. Issue: --- - The Contact Us button is displayed incorrectly in some product designs. Root cause: --- - At [1], in the wishlist template, only the Contact Us text is displayed without the icon and label structure used by the Add to Cart button. - Because of this, when different product designs are applied, the layout becomes inconsistent and the button appears misaligned. Solution: --- - Apply the same structure used for the Add to Cart button by adding the icon and label wrapper to the Contact Us button to ensure consistent styling across all product designs. Backport of [commit] [1]https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/website_sale_wishlist/views/website_sale_wishlist_template.xml#L353-L359 [commit]: https://github.com/odoo/odoo/commit/c697217ed0e009bd368617f25b5773c5d6ce3c92 Before: --- <img width="261" height="358" alt="image" src="https://github.com/user-attachments/assets/cf3fe6de-5a7c-4a22-a908-09b8c121cdf4" /> After: --- <img width="263" height="334" alt="image" src="https://github.com/user-attachments/assets/d44c41b9-0b48-41d0-992b-a506ba4428b6" /> opw-5798833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252774
This update resolves an issue where invoices generated with the 'Pay Later' payment method in Switzerland lacked a QR code for payment. The fix ensures that invoices correctly identify a bank partner, allowing for proper QR code generation and payment processing. This improves the user experience for customers using this payment option.
Original PR description
Step to reproduce: - Install l10n_ch_pos and make sure swiss company has tax id filled - Create a swiss customer with an email address and vat, add full address - Open a pos session, and make an invoice for a product with tax, - select payment method, which allows `pay_later`, i.e. payment without journal_id Observation: - the invoiced order, do not have qr for payment, because the invoice do not have `bank_partner_id` Cause: - `_get_partner_bank_id` is recently updated in commit[1], which do not considered `pay_later` option [1] https://github.com/odoo/odoo/commit/7e63991dceb6e443b950e6a1b94454a82d5668c7 Fix: - Fixed the fallback logic for `_get_partner_bank_id` opw-6023060 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254892 Forward-Port-Of: odoo/odoo#254117
This update resolves an issue preventing internal users from accessing overtime data within the employee dashboard. The fix adds a necessary security permission, ensuring all employees can view their overtime hours as intended. This improves usability and data visibility for all users.
Original PR description
Steps to reproduce: 1. Enable "Display Extra Hours" in Attendance settings. 2. Assign an overtime ruleset to an employee. 3. Ensure the employee does not have the "Officer: Manage attendances" group.…
Steps to reproduce: 1. Enable "Display Extra Hours" in Attendance settings. 2. Assign an overtime ruleset to an employee. 3. Ensure the employee does not have the "Officer: Manage attendances" group. 4. Create an attendance that generates extra hours for this employee. 5. Log in as the employee and open the Employees app to view Extra Hours. Issue: An Access Error is raised because `get_overtime_data_by_employee` in `hr_holidays_attendance/models/hr_employee.py` performs a `_read_group` on `hr.attendance.overtime.line`. In 19.0, the only ACL for this model grants access to `group_hr_attendance_officer`: https://github.com/odoo/odoo/blob/95c73aa4dd7433f394799fdaaad57a84d750ec5a/addons/hr_attendance/security/ir.model.access.csv#L1-L11 Users with `group_hr_attendance_own_reader` (implied by `base.group_user`, i.e. all internal users) have no read access to `hr.attendance.overtime.line`. In later versions, this was already fixed by adding a read-only ACL for `group_hr_attendance_own_reader` on this model: https://github.com/odoo/odoo/blob/ad4a2ec11fea2058445e4003099af3a5caa1ef22/addons/hr_attendance/security/ir.model.access.csv#L13 This is why forward-ports are not needed. Solution: Add the missing `access_hr_attendance_overtime_line_own_reader` ACL to grant read-only access to `group_hr_attendance_own_reader` on `hr.attendance.overtime.line`, matching the approach used in later versions. This is preferred over using `.sudo()` as it properly grants the intended access right rather than bypassing security checks entirely. opw-6055081 Forward-Port-Of: odoo/odoo#255576
This update resolves an issue where creating a task from a template after a page refresh would sometimes fail. The fix prevents errors related to virtual controllers, ensuring that task creation works reliably after a page reload. This improves the user experience and prevents data loss.
Original PR description
Steps to reproduce: - Open a project - Create a task and convert it into a template - Open another task (task A) - Reload the page - Create a task from the newly created template Refreshing the page causes `loadState` to rebuild the controller stack from the URL to represent the breadcrumb history. In this case, a virtual form controller is injected for the opened task A, due to the lack of context in the URL to reconstruct it fully. When creating the task from the template, a `switchView` to the new task's form view is triggered. However, only the controller for this new form view is fully populated with the relevant metadata, as the preceding ones are virtual (due to the above). This commit ensures that virtual controllers are excluded from the check on the `multiRecord` field, preventing an error since the `view` is undefined for virtual controllers. task-5876607 Forward-Port-Of: odoo/odoo#246346
This update resolves an error that occurred when rearranging sections within sale order lines. The fix ensures that the system correctly handles changes to order lines, preventing errors during editing and maintaining data integrity. This improves the user experience when managing sales orders.
Original PR description
Moving a section around in sale order lines when there is a line that can be abandoned throws an error Steps to reproduce: 1. Install Sales app 2. Go to Sales and create a new quotation 3. Add any…
Moving a section around in sale order lines when there is a line that can be abandoned throws an error Steps to reproduce: 1. Install Sales app 2. Go to Sales and create a new quotation 3. Add any product, then add a section: enter any name for the section and then immediately press Enter (it should create an empty product line) 4. Without leaving edit mode, drag and drop the section at the top of the sale order lines (the empty product line should still be there) 5. An error is thrown The same issue can be reproduced by moving a section down: 3b. Add any product, then add a section: move it to the top of the order lines then enter any name for the section and immediately press Enter (it should create an empty product line) 4b. Without leaving edit mode, drag and drop the section just between the product line and the empty product line Issue: `sortDrop` calls `leaveEditMode` at https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/web/static/src/views/list/list_renderer.js#L2242 which removes order lines that can be abandoned https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/web/static/src/model/relational_model/static_list.js#L379-L381 This can remove records from the recordMap generated before calling `super.sortDrop` in https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/sale_management/static/src/fields/sale_order_line_field/sale_order_line_field.js#L175-L182 so we end up calling `_handleQuantityAdjustment` with a recordMap that contains record ids that have been deleted, throwing an error when we try to access the deleted record Solution: Call `leaveEditMode` before computing recordMap in order to remove the records that can be abandoned. This prevents `this.props.list.records` from being different when we generate recordMap and when we call `_handleQuantityAdjustment`. We also need to set the record being moved as dirty. This prevents the record from being abandoned when `leaveEditMode` is called. opw-6022538 Forward-Port-Of: odoo/odoo#256662
This update fixes a problem where error messages for inherited views in Odoo contained sensitive development keys. The change now ensures these keys are not translated, resulting in cleaner and more secure error messages for users. This improves the overall user experience and protects against potential information leaks.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Validation Error message is being translated base on user message, including development keys <img width="1092" height="276" alt="image" src="https://github.com/user-attachments/assets/4c58f201-8bc6-4b5e-9510-e52f36e0cf2c" /> Desired behavior after PR is merged: development keys will not be translated <img width="1084" height="307" alt="image" src="https://github.com/user-attachments/assets/0ccbf570-b5a0-46ff-aaef-bc1aaa237371" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256982
This update prevents users from creating checklists within the email marketing editor using a shorthand command. Previously, this shortcut allowed unintended checklist creation, despite other restrictions in place. This fix ensures that checklist creation is fully controlled and prevents potential issues within email marketing campaigns.
Original PR description
In email marketing, checklist creation is disabled via powerbox, toolbar, and shortcut (Ctrl+Shift+9), but it can still be created using the shorthand command ('[] ').
Disable the checklist shorthand command to ensure checklist creation is fully restricted in email marketing.
task-6048027
Forward-Port-Of: odoo/odoo#254816This update corrects a visual glitch where the editable hint would blink when the user updated the content within the field. The fix ensures the hint remains stable during edits, providing a smoother and more reliable user experience. This improves the overall usability of the Todo module.
Original PR description
Problem: When the selection is updating, the hint is blinking in the editable. Cause: After 9df2662cc79c2d8277211f7ce0bdb389f783f933, `triggerDebouncedUpdateHints` clears the hint immediately and adds it back using a debounced version of `updateHints` which runs after a few seconds, thus causing this blink. Solution: We only update hint if the selection inside the editable. Steps to reproduce: - Create a new Todo. - Keep the editable empty. - Update the Todo title. - Observe the editable hint blinking. task-6025534 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253846
This update fixes an issue where the HTML editor toolbar wasn't opening correctly on macOS when using Cmd+Shift+Arrow to select text. The fix utilizes a secondary event listener to ensure the toolbar activates reliably, even when the Cmd key is held down. This improves the user experience for macOS users.
Original PR description
Problem: The toolbar does not open when using Cmd+Shift+Arrow to select text on macOS. Cause: On macOS, when the Cmd key is held down, the `keyup` event is never fired for other keys. The toolbar…
Problem:
The toolbar does not open when using Cmd+Shift+Arrow to select text on macOS.
Cause:
On macOS, when the Cmd key is held down, the `keyup` event is never fired for other keys. The toolbar relies on `keyup` for Arrow keys to re-enable `onSelectionChangeActive` and trigger the toolbar update, so it never opens.
See section ("Issue 3 - keyup event put on hold for other keys"): https://web.archive.org/web/20160304022453/http://bitspushedaround.com/on-a-few-things-you-may-not-know-about-the-hellish-command-key-and-javascript-events/
Solution:
Track when an Arrow key is pressed while Cmd is held (`pendingArrowKey`) and use a `selectionchange` listener as a fallback to re-enable the toolbar. The `selectionchange` event fires reliably on macOS even when `keyup` is suppressed. A `isMouseDown` guard ensures the listener does not interfere with the existing mousedown/mouseup flow.
Steps to reproduce:
1- Type some text
2- Use Cmd+Shift+Arrow (left or right) to select text 3- Observe the toolbar does not appear
task-6013408
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#257166
Forward-Port-Of: odoo/odoo#253293This update fixes an issue where combo prices were incorrectly distributed across items when a combo included free quantities with a zero price. Previously, the system miscalculated prices for combos with both free and paid items. This change ensures accurate pricing for all combo orders, improving the reliability of self-order transactions.
Original PR description
In a specific scenario where a combo had combo choice with free quaitites and combo choice with only extra quantities and the price of the combo choice with free quantities was 0, the price of the combo product was distributed on the "free" lines and on the "extra" lines, which was causing the price to be wrong. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257367
This update fixes an issue where the cursor wasn't updating correctly in Safari when the browser was collapsed on iOS devices. Specifically, the cursor position was misaligned when applying formatting. This ensures a consistent and functional editing experience for all users, particularly those using Safari on smaller screens.
Original PR description
Before this commit: when we applying format on collapsed cursor, we create a formatted element with ZWS, and set the cursor before the ZWS After this commit: we set the cursor after the ZWS, cause otherwise safari doesn't update the cursor properly leading to unformatted input task-4243977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257161 Forward-Port-Of: odoo/odoo#249253
This update corrects a broken view within the l10n_cl (Chilean accounting) module, preventing issues with newer Odoo versions. The fix avoids rolling release failures and eliminates the need for manual database checks, streamlining the upgrade process. This ensures the Chilean accounting functionality continues to operate smoothly.
Original PR description
There is a broken xpath in l10n_cl.report_invoice_document When the l10n_cl module is installed, it results in the faulty view being applied to v18 and later versions. This is particularly annoying because some rolling releases fail because a view with invalid locator is found. The view won't be disabled after a rolling release upgrade and many developers will be spared from checking the databases manually. Forward-Port-Of: odoo/odoo#254369 Forward-Port-Of: odoo/odoo#253588
This update resolves an issue preventing the demo installation of the Romanian EDI stock module. It removes a validation check that interfered with the setup process. Additionally, the update includes a default stock valuation account for Romanian companies, streamlining the initial configuration.
Original PR description
This commit ensures that stock picking carrier validation for Romanian EDI does not block demo data installation. task-3748978 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239870
This update resolves an issue where attempting to cancel a manufacturing order would trigger an error. The fix ensures that logging of 'cancel' activities is only performed when a move is linked to a picking, preventing a common traceback. This improves the reliability of the manufacturing process.
Original PR description
Steps to reproduce the bug: - Unarchive the MTO route - Create a storable product P1: - Route: MTO + Manufacture - BoM: - Component: 1 unit of X1 - Create a storable product X1: - Component: 1 unit…
Steps to reproduce the bug:
- Unarchive the MTO route
- Create a storable product P1:
- Route: MTO + Manufacture
- BoM:
- Component: 1 unit of X1
- Create a storable product X1:
- Component: 1 unit of C1
- Create a manufacturing order for 1 unit of P1
- Confirm the MO -> A child MO is created
- Try to cancel the MO for P1
Problem:
A traceback is triggered:
IndexError: tuple index out of range
'origin_picking': moves.picking_id[0],
Explanation:
When the parent MO is cancelled, all the moves linked to this MO are
cancelled (finished moves and raw moves). While cancelling them, an
activity of type "cancel" is logged on the pickings linked to these
moves (if any), in order to warn the user that actions may be required
on those pickings.
However, we do not check whether the moves actually have a picking
linked before logging the activity. The code directly tries to access
the first picking linked to the move, which triggers the traceback when
there is none:
https://github.com/odoo/odoo/blob/796316c341c4346152ad9610c30679f47aaa2ff8/addons/mrp/models/stock_move.py#L442
When cancelling an MO, the method `_log_manufacture_exception` is already
called and logs an exception activity on the child MO.
Bug introduced by:
https://github.com/odoo/odoo/pull/254636/changes/7c68c3dbb29eaad4e09d59ef7c86bd525969caec
Forward-Port-Of: odoo/odoo#257011This fix resolves a crash that occurred when deleting certain fields used in website forms. The issue stemmed from the way website forms were parsing fields as XML, leading to parsing errors. This update corrects the parsing process to prevent these crashes.
Original PR description
Steps to reproduce ================== tl;dr: html fields are parsed as xml - Go to Helpdesk > Tickets > Warranty - Open studio - Add a new text field named "TEST" - Remove it from the view - Exit studio - Go to the website - Click on new - Add a new blogpost - Set a title and save - Click on "Contact & Forms" - Click on the first block - Click on the form - Change the form action to "Create a ticket" - Click on "+ Field" - Change the Type selection to "TEST" - Click on save - Enable debug mode - Go to "Settings / Technical / Database Structure / Fields" - Type x_ in the search bar and press enter - Delete the field => lxml.etree.XMLSyntaxError Cause of the issue ================== When deleting a field, `_check_if_used_in_website_form` is called to prevent the deletion if a field is used in an html field. The html fields were parsed with an xml parser.. opw-5946029 Forward-Port-Of: odoo/odoo#256066
This update adjusts the timeout settings for Odoo's automated test suite to better reflect how the tests are now run. Previously, a single, long timeout was used, which wasn't always appropriate. Now, the timeout dynamically adjusts based on whether the tests are running a partial or full suite, ensuring faster test execution and preventing unnecessary delays.
Original PR description
Hoot suites (test_unit_desktop and test_unit_mobile) are now split and run in each sub builds on runbot [1]. As a consequence, the historical timeout isn't accurate anymore (we don't need a 1h timeout when only a part of the suite is run in a sub build). On the other hand, the whole suite is also run at once in nightly builds. There, the 1h timeout is sometimes not enough, as the suite keeps growing. This commit makes the timeout more accurate by taking into account 2 different cases: if the suite is run for a subset of modules, or if it is run for the whole codebase. This allows it to timeout earlier on regular builds if it is deadlocked, and it doesn't timeout anymore on nightly builds. [1] https://github.com/odoo/odoo/pull/234132 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 chatbot restart messages were incorrectly included in new ticket or lead descriptions. Now, only messages sent after the chatbot is restarted are included, ensuring ticket descriptions accurately reflect the conversation's current state. This improves the clarity and accuracy of customer interactions.
Original PR description
Before this commit: When a chatbot conversation is restarted and the script creates a new ticket/lead, the description also includes messages from the previous session. After this commit: Only the messages sent after the chatbot conversation is restarted are included in the ticket/lead description. Task-5118966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256595 Forward-Port-Of: odoo/odoo#253566
This update fixes a validation error that prevented users from being linked to multiple employees within the same company. The issue stemmed from a miscalculation of employee IDs during user creation, particularly in a non-sudo environment. The fix ensures accurate employee assignment by always performing the necessary search operations within a sudo context.
Original PR description
**Steps to reproduce** - Install `pos_hr` with demo data - Open Settings > Manage Users - Validation Error: A user cannot be linked to multiple employees in the same company **Cause** `employee_id`…
**Steps to reproduce** - Install `pos_hr` with demo data - Open Settings > Manage Users - Validation Error: A user cannot be linked to multiple employees in the same company **Cause** `employee_id` for the current user was computed as False here: https://github.com/odoo/odoo/blob/361aa8505506f9686b1cdb244ba1723ee3f06f7b/addons/pos_hr/models/pos_config.py#L27 Despite an employee already existing, which led to the error here: https://github.com/odoo/odoo/blob/361aa8505506f9686b1cdb244ba1723ee3f06f7b/addons/pos_hr/models/pos_config.py#L30 This exposes an issue with `_compute_company_employee`: - the compute is called a first time on multiple users, including the current user, in a non-sudo environment - the `employee_id` field for the current user is accessed in a sudo environment The problem comes from the search in non-sudo, which uses an `ir.rule` that evaluates `user.employee_id` in sudo while we are computing `user.employee_id`. **Fix** We avoid the cache issue by always performing the search in sudo. opw-6046297
This update resolves an issue preventing customers from viewing product ratings on the website. Previously, a technical restriction limited access to rating data for public users. This change ensures all customers can see and interact with product ratings, improving the shopping experience. The fix addresses an AccessError related to product variant permissions.
Original PR description
**Steps to produce:** - Install the `Ecommerce` module. - Create a product. - In the Sales tab, set an alternative product and ensure both are published. - Open the product page on the website and enable `reviews` from the editor. - Open the same product page in incognito mode. **Issue:** ``` AccessError: You do not have enough rights to access the field "rating_avg" on Product Variant (product.product). ``` Root cause: --- - Currently, product records in dynamic snippets to be fetched without superuser privileges. Since the `rating_avg` field is restricted to internal users, public visitors encounter an `AccessError` when viewing snippets with ratings enabled. - Similar approach used [here]. [here]: https://github.com/odoo/odoo/commit/12bb994da4c3222e8c7fb2df95c202a6c45a28b0 opw-6065319 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257400 Forward-Port-Of: odoo/odoo#256570
This update prevents unnecessary calls to IAP (a data service) when users' databases aren't set up to receive VIES updates. Previously, all databases would attempt updates, even without the necessary cron job, leading to wasted resources. Now, the system intelligently sends a placeholder to avoid impacting IAP when updates aren't possible.
Original PR description
If the user contacts us from an unreachable db (localhost, firewall, .. .), we currently rely on a cron on the db to pull updates by calling `vies_check_update`. Currently, all dbs, even those that don't have the cron (i.e. haven't yet upgraded the `iap` module) will send the `client_identifier/token` upon calling `vies_check_validity`. However, since they don't have the cron, they won't be able to pull updates from IAP. Thus, if we detect that the crond does not exist, we will now send dummy `client_identifier/token` to avoid poluting IAP. task-none Forward-Port-Of: odoo/odoo#257493
This update resolves a technical issue where PEPPOL invoice data mapping was failing when the 'Invoice period extra field' was initially empty. The fix ensures the field is correctly initialized as a dictionary, allowing for proper data processing and integration with PEPPOL standards. This improves the reliability of invoice processing for PEPPOL transactions.
Original PR description
When mapping the Invoice period extra field and updating the xml nodes, if the invoice period was originally empty, it would be initialized to an empty list not a dict which was breaking the mapping. task-6076624 Forward-Port-Of: odoo/odoo#256594
This update optimizes the HTML editor's performance by making several key changes to how it processes HTML content. Specifically, it reduces unnecessary calculations and delays certain checks, resulting in faster rendering and a smoother user experience. This improvement focuses on internal optimizations within the HTML editor code.
Original PR description
Description of the issue/feature this PR addresses: This PR improves the performance of several `normalize_handlers` by reducing expensive DOM/style checks, avoiding unnecessary layout recalculations. This PR: 1. Replaces the usage of `fillEmpty` with manual filling of empty blocks. 2. Replaces `isBlock` with `!isPhrasingContent`, which better matches the actual use case and avoids unnecessary work. 3. Optimizes list normalization by reducing checks for `isBlock`. 4. Avoids style recalculations in `normalizeInline` of `qweb_plugin`. 5. Delays the `isBlock` check at certain places so it is only performed when needed. 6. Reduces the number of `isBlock` calls in `selection_placeholder_container_predicates` and `selection_blocker_predicates`. 7. Fixes layout thrashing by separating style reads from style writes. task-5245157 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255310
This update fixes a confusing issue where RFQs sent via the list view's 'Send by mail' action didn't automatically update their status. Now, RFQs are correctly marked as 'Sent' immediately after email delivery, matching the behavior of sending from the form view. This improves user experience and eliminates the need for manual re-sending.
Original PR description
Issue Before This Commit: ======================= When RFQs are sent using the `Send by mail` action from the list view, their state remains draft instead of being updated to sent, so users see them…
Issue Before This Commit: ======================= When RFQs are sent using the `Send by mail` action from the list view, their state remains draft instead of being updated to sent, so users see them as not sent even though they were already emailed and have to send them again using the `Send RFQ` button from the form view to mark rfq as sent, which is inconsistent with the form view behavior and confusing for users. Steps to Reproduce: ======================= - Install the `Purchase` app. - Go to Purchase and select multiple RFQs in the list view. - Click `Send by mail` from the actions menu. - Select the RFQ email template and send the email. - Observe that the RFQs remain in state RFQ instead of being set to RFQ Sent, unlike when using the `Send RFQ` button in the form view. Cause of the issue: ======================= The `Send by mail` action in the list view does not apply the same state update logic as the `Send RFQ` button from the form view, where the RFQ state is updated when the email is posted on the purchase order. As a result, when emails are sent from the list view (mass mailing flow), the RFQ state is not updated After This Commit: ======================= When emails are sent using Send by mail, purchase orders in state draft are updated to sent in `_message_mail_after_hook` after the email is sent. This keeps the list view flow consistent with the form view behavior and prevents users from having to resend RFQs just to update the state. TaskID-5443248
This update ensures that the price of a combo order is accurately applied to any additional items added as extras. Previously, when all sub-items were ordered without free quantities, the system incorrectly priced these extra items at the base price, leading to inaccurate order totals. This fix corrects this issue by distributing the parent combo's list price proportionally to the extra items.
Original PR description
When all sub-combos have qty_free=0, no child lines were classified as free, leaving remaining_total (= parent list price) undistributed. Extra lines were priced at base_price only, silently dropping the parent combo price. Fix by mirroring the JS computeComboItems logic: before processing extra lines, compute their proportional denominator and allocate remaining_total to each extra line as a share of parent_lst_price, with a per-unit rounding correction on the last line. opw-6045562 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254665
This change fixes an issue where new projects created from CRM leads using templates incorrectly inherited the template's company. Now, the project automatically uses the lead's company, ensuring accurate company information and preventing user errors. This improves data consistency and the user experience.
Original PR description
When creating a project from a CRM lead using a template, the `default_company_id` set by `_get_project_create_from_lead_context` is ignored because `company_id` is not in the template default context whitelist. This causes the new project to inherit the template's company instead of the lead's company, resulting in a company mismatch with the partner and a UserError. https://github.com/odoo/odoo/blob/2b89db4af2265e5cec8feb11853364e293de203e/addons/crm_sale_project/models/crm_lead.py#L37-L45 https://github.com/odoo/odoo/blob/2b89db4af2265e5cec8feb11853364e293de203e/addons/project/models/project_project.py#L1413-L1419 Steps To Reproduce: 1. Go to CRM, create or open a lead. 2. Clear the contact field and save. 3. Click the gear icon → Create Project. 4. Select any project template (not empty) and submit. Ticket [link](https://www.odoo.com/odoo/project.task/5933253) opw-5933253 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where deleting a public holiday incorrectly created timesheets for all related leave requests, even those that were refused. Now, deleting or modifying a holiday only generates timesheets for valid, approved leaves, streamlining the timesheet process and preventing unnecessary entries.
Original PR description
…d leaves Description of the issue/feature this PR addresses: When a public holiday is edited or deleted, the timesheet re-creation is erroneously done for *all* leaves, even those which are canceled or still in draft. Steps to Reproduce: 1. Create a Time Off request for a timesheet-creating leave type (i.e. `timesheet_generate = True`) that overlaps with a public holiday. 2. Refuse the Time Off request. 3. Delete the public holiday the request overlaps with. Current behavior before PR: The deletion of the holiday causes timesheet entries to be created, even though it's a refused request. Desired behavior after PR is merged: The deletion or editing of the public holiday only re-creates the timesheets for the leaves that are actually valid and thus need timesheet entries. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255155 Forward-Port-Of: odoo/odoo#250372
This update resolves an issue where multi-day 'Half Day' time off requests were incorrectly generating a single timesheet entry. The fix ensures that requests for multiple days now create individual timesheet entries for each day of the leave, accurately reflecting employee hours. This improves the accuracy of timesheet reporting.
Original PR description
Steps to reproduce: ------------------- 1. Install Timesheets and Time Off. 2. Create a new Time Off type with duration type "Half Day" (disable "Require allocation" to skip allocations). 3. Enable…
Steps to reproduce: ------------------- 1. Install Timesheets and Time Off. 2. Create a new Time Off type with duration type "Half Day" (disable "Require allocation" to skip allocations). 3. Enable "Timesheets" in Timesheets > Configuration. 4. Ensure the employee is configured with a "Flexible" working schedule. 5. Create a multi-day Time Off request (2 days) using this type and approve it. 6. Check the timesheet entries for the employee. Issue: ------ When a multi-day time off request is submitted for a "Half Day" time off type, the system fails to generate individual daily timesheet entries. Instead, it generates a single timesheet entry with a duration calculated as calendar.hours_per_day / 2, regardless of the actual number of days requested. (e.g., if hours_per_day is 8, it generates one entry of 4 hours for a 2-day leave), Cause: ------ After this commit 9512832, multi-day requests were allowed for time off types where the **request_unit** is "half day" or "hours". However, the logic in `_generate_timesheets` for flexible calendars was not updated to account for this. Previously, `request_unit_half` was computed as: https://github.com/odoo/odoo/blob/feb3cd520d7a736996621f7765184edca6ac390c/addons/hr_holidays/models/hr_leave.py#L319-L323 But now, the condition is: https://github.com/odoo/odoo/blob/14ccd1f54e21c07ac68593c8dec7682371f8663c/addons/hr_holidays/models/hr_leave.py#L467-L470 Since `request_unit_half` now stays **True** regardless of the request duration (as long as the Type is 'half_day'), the following condition in `_generate_timesheets`: https://github.com/odoo/odoo/blob/14ccd1f54e21c07ac68593c8dec7682371f8663c/addons/project_timesheet_holidays/models/hr_leave.py#L39 always evaluates to **True**. This traps multi-day requests in the "single-day" logic, preventing the code from reaching `_list_work_time_per_day`. Solution: --------- Update the condition to strictly check if the request is a single day before applying the simplified single-entry logic. If the request spans multiple days, it will now correctly fall into the else block, utilizing `_list_work_time_per_day` to generate one timesheet entry per day of the leave. opw-5715197 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248605
This update fixes a potential issue in how Odoo calculates taxes on invoices. Previously, invoices with a zero-priced exclusion would incorrectly trigger a fallback to excluded tax mode. This change ensures accurate tax calculations regardless of whether a price exclusion is present, improving invoice accuracy and financial reporting.
Original PR description
…xes_data Suppose an invoice with price-included taxes but with a zero price excluded one. We don't want to fallback on the excluded mode just for that. opw-6060486 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257495
This update improves how charges are handled on invoices generated using UBL/BIS3. Instead of creating a new invoice line for charges, the charge amount is now directly added to the price unit of the original invoice line. This ensures accurate and consistent reporting of charges on invoices.
Original PR description
Before this commit: A charge in an InvoiceLine was creating a new invoice line with the amount of the charge. After this commit: The charge is added in the price unit of the original line --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255828 Forward-Port-Of: odoo/odoo#254111
Documentation and clarification updates
This pull request updates the legal documentation related to the Quartile license agreement. The change ensures compliance with Odoo's submission guidelines and reflects the latest terms and conditions. This is a standard legal update to maintain the integrity of Odoo's open-source project.
Original PR description
@qrtl --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256803
This pull request incorporates the individual contributor license agreement (CLA) signature for Eric Rieve, a developer contributing to Odoo. This ensures compliance with Odoo's open-source licensing process and allows RieveFireProt's code to be integrated into the Odoo project.
Original PR description
Adds the individual contributor license agreement signature file for GitHub user `RieveFireProt` as described in Odoo's CLA contribution process. Contributor details: - Name: Eric Rieve - Email: eric@rievefire.com - GitHub: https://github.com/RieveFireProt Forward-Port-Of: odoo/odoo#256509