Daily updates from Odoo
Monday, March 23, 2026
31 changes · saas-18.3
Resolved issues and error corrections
This update fixes a visual inconsistency in the accounting reports. Previously, the company header was grayed out only in light mode. Now, it dynamically adjusts to the dark mode theme using a standard muted data color, ensuring a consistent and professional appearance across all viewing modes.
Original PR description
Before this pr: - The company header in the accounting reports is grayed out in the light mode only, not in the dark mode. Reason: - Until now, we have been using the hard-coded 'lightgrey' color for the company header. After this pr: - In this pr, we are changing the color of the company header from hard-coded 'lightgrey' color to the standard variable color '--AccountReport-muted-data-color' used for muted data in account reports. Task-5960592 Forward-Port-Of: odoo/enterprise#111353 Forward-Port-Of: odoo/enterprise#110108
This update corrects a map data issue where Russia was missing from the Asia map. It also includes a new map for Oceania, ensuring more accurate geographic representation. This improves the visual accuracy of location-based data within Odoo.
Original PR description
- Fix Asia map (russia was missing) - Added Oceania map Task-5224009 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#248847
This update resolves a technical issue related to how geographic data (specifically topoJSON) is processed within the Odoo Enterprise spreadsheet reports. The fix ensures accurate display of maps and charts based on location data, improving the reliability of reports that rely on geographic visualizations. This update primarily impacts the spreadsheet functionality.
Original PR description
test adaptation Counterpart of github.com/odoo/odoo/pull/248847 Task-5224009 Forward-Port-Of: odoo/enterprise#107912
This update addresses a technical issue related to the validation of partner country information within the l10n_ec_edi module. The fix ensures that the identification type of a partner aligns with their registered country, resolving two failing tests. This improves the accuracy of EDI processing for Ecuadorian businesses.
Original PR description
In pr https://github.com/odoo/odoo/pull/248585 I added a check that verify if the l10n_latam_identification_type of a partner correspond to the partner country. It breaks two tests which are fixed here. opw-5801824
This update resolves an issue preventing invoices to Åland Island (AX) partners from being correctly sent via PEPPOL. Previously, invoices were generated but not transmitted, resulting in attachments but no chatter notifications. This change enables Peppol functionality for companies in Åland Island.
Original PR description
Before this commit, invoice to a partner in Åland Island can't be sent via Peppol. XML and PDF are generated, linked to the account.move, but are not sent and don't appear in the chatter. Steps to reproduce: - Create a partner in Åland Island - Create an invoice - Send to Peppol Current behavior: - Invoice is not sent, appear in the attachment, but doesn't appear in the chatter. Expected behavior: - invoice is sent and attachments are in the chatter This also allow activating Peppol for companies in Åland Island. Ticket [link](https://www.odoo.com/odoo/project.task/5949439) opw-5949439
This update optimizes how Odoo loads its registry, significantly reducing the time it takes to start up, especially for customers with large addon installations. By avoiding unnecessary file system scans, the change dramatically improves performance and responsiveness, leading to faster request processing.
Original PR description
In `ThreadedServer,` the http daemon will create threads to handle incoming requests. The creation of these threads doesn't wait until the registry is loaded because the request could be serving…
In `ThreadedServer,` the http daemon will create threads to handle incoming requests. The creation of these threads doesn't wait until the registry is loaded because the request could be serving static files. In the WSGI application entry point `__call__`, the threads will be going into `self.get_static_file` and up until this point, there's no locking whatsoever on these threads. Inside `get_static_file`, the `self.statics` lazy_property is evaluated which will walk the addons path. Before this PR, the order of the conditions in the or statement will always evaluate the lazy property regardless of the other parts of the condition. This means that every single request that comes in will do an unnecessary `os.listdir` on all addons paths. For customers with a very large and deeply nested addons path like in opw-5877522 (they had over 93K dirs), this is a tremendous load on the system when there are multiple threads doing that due to the amount of syscalls involved for no reason whatsoever. This is especially worse on SH because disks are not local, so an individual syscall is more expensive. This is slowing down all requests as well as the registry loading time which is a prerequisite for any non-static request. This PR simply reorders this check to only evaluate the self.statics property if all other parts of the condition are False. This means it'll only have to do this expensive `os.list` for a fewer number of requests which are much more unlikely to coincide at the startup of a worker. On top of that it's a better optimization to avoid doing this expensive check for every request. Benchmarks |No. files in addons path| No. concurrent threads | Registry loading time Before PR | Registry loading time After PR | |--------|--------|--------|--------| | 93447 | 5 | 53.23 s | 4 s | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254660
This update corrects a previous issue that prevented users from finding and adding a partner's bank account when creating a credit note. The system now correctly filters bank accounts based on the expected recipient, ensuring credit notes function as intended. This resolves a limitation that was impacting credit note processing.
Original PR description
Description of the issue this commit addresses: The Recipient Bank field in the Other Info tab of the Account Move form view refilters accounts to only show you company's ones. This is expected for invoices but is blocking when doing a credit note. You can't find a partner's bank account to fill that field. --- Steps to reproduce: 1. Install account. 2. Create an Invoice to a partner which has a bank account setup. 3. Create a Credit Note for that Invoice. 4. In the "Other Info" tab, remove the partner's bank account. 5. Try to search for his bank account to add it back. It won't show up. --- Desired behavior after this commit is merged: The Recipient Bank field prefilters bank accounts based on who is expected to be the recipient of the move. --- task-5976951 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254850 Forward-Port-Of: odoo/odoo#252961
This update resolves an issue where CFDI reports incorrectly displayed '99 - False' instead of '99 - Por definir' for payment method 99. The fix ensures accurate reporting of this payment method, addressing a discrepancy in the Mexican tax invoice generation process. This ensures compliance and accurate financial reporting.
Original PR description
**PROBLEM** PR https://github.com/odoo/enterprise/commit/843d57b25f925a5d4f1848b85717adb4d1a9d388 Archives payment method 99, but because it's archived `_l10n_mx_edi_get_extra_invoice_report_values()` doesn't retrieve it. This leads the pdf report to display '99 - False' instead of '99 - Por definir'. **STEP TO REPRODUCE** 1. Create an invoice with the mx company. 2. Set the due date sometime in the month later. (To have the PPD payment policy on the invoice). 3. Send and generate the invoice using cfdi. opw-5927655 Forward-Port-Of: odoo/enterprise#111051 Forward-Port-Of: odoo/enterprise#107267
This update resolves an issue where PDF merging errors didn't consistently display user-friendly error messages. The fix ensures that a clear error message is always shown when PDF merging fails, regardless of the underlying cause. This improves the user experience and helps identify problems with generated reports.
Original PR description
When merging pdfs, if there is an error when meging those pdfs (due to a malformed PDF for example), the UserError that should be shown to the user is not due to an error in the arguments given to the handle_error function.
The aim here is to keep the same function signature and edit the signature of the local function used when a custom_handle_error was defined and edit the function itself.
The error message appeared when I was working on a task to change a
test and tested it on master and got the following stacktrace:
```
...
File "/home/odoo/Desktop/src/odoo/odoo/addons/base/models/ir_actions_report.py", line 788, in _merge_pdfs
handle_error(error=e, error_stream=stream)
TypeError: IrActionsReport._handle_merge_pdfs_error() missing 1 required positional argument: 'self'
```
Discovered during : task-3603619
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#211611This update automatically calculates and transmits the necessary commission information for Swiss payroll declarations (ELM). Previously, this calculation was manual, introducing potential errors and delays. This change ensures accurate and timely reporting to Swiss tax authorities, streamlining the payroll process.
Original PR description
Forward-Port-Of: odoo/enterprise#111143
This update corrects a display issue where the 'Pick Up in Store' option was incorrectly shown for products with excluded tags. The fix ensures that unavailable delivery methods aren't presented to customers, improving the user experience and maintaining consistent behavior across the website.
Original PR description
Currently, when a product has a tag that is configured as an Excluded Tag on the Pick Up in Store delivery method, the method is still shown on the product page. Steps to produce: --- - Install…
Currently, when a product has a tag that is configured as an Excluded Tag on the Pick Up in Store delivery method, the method is still shown on the product page.
Steps to produce:
---
- Install `website_sale` module.
- Enable `Click and Collect` in settings.
- Go to `website > ecommerce > products > product tags.`
- Create a new tag and add a product in product template.
- Go to` website > configuration > ecommerce > delivery method.`
- Open` pick up in store`:
- In the `Stores` tab, set your company warehouse.
- In the `Availability` tab, add the created tag to Excluded Tags.
- Publish the delivery method.
- Open the tagged product on the website.
Issue:
---
- The Pick Up in Store option is still displayed on the product page, even though the product has a tag listed in the carrier’s Excluded Tags.
Root cause:
---
- Here at [1], the method `_get_additional_combination_info ()` does not check whether the product has tags that are excluded by the delivery method.
- However, at [2], during checkout, the exclusion works correctly because `_match_excluded_tags` in `delivery.carrier` filters the carrier based on excluded tags.
Solution:
---
- Hide the Pick Up in Store option when the product has tags excluded
for that delivery method. This keeps the behavior consistent across
the website, avoids showing unavailable delivery options, does not
impact other flows and aligns with the existing behavior during
checkout.
[1]https://github.com/odoo/odoo/blob/1c483c3a8d7d079bd34a378f9f8716551e4bab93/addons/website_sale_collect/models/product_template.py#L17-L21
[2]https://github.com/odoo/odoo/blob/1c483c3a8d7d079bd34a378f9f8716551e4bab93/addons/delivery/models/delivery_carrier.py#L192-L194
opw-5921268
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#255066
Forward-Port-Of: odoo/odoo#250837This update corrects a validation issue in the ZATCA XML generation for Saudi Arabia companies. Previously, the system didn't include cash rounding amounts in the payable calculation, leading to validation errors. This change ensures accurate payable amount calculations for invoice validation, aligning with ZATCA requirements.
Original PR description
Currently the generated ZATCA XML is not accounting for invoice cash rounding, leading to an invoice validation issue due to a mismatch in the calculation of PayableAmount. Steps to reproduce: - Have a SA Company setup - Create a [cash rounding] with strategy 'Add invoice line' and rounding 1.00 (UP) - Create an invoice for 99.55 + 15% Tax - Set Cash Rounding Method to [cash rounding] - Confirm and send xml for validation Issue: Validation will issue the following warning `[202] BR-CO-16 : Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) -Pre-Paid amount (BT-113) + Rounding amount (BT-114).` Analysis: The ZATCA implementation was calculating the payable amount strictly as (TaxInclusiveAmount - PrepaidAmount). This change ensures the rounding amount is fetched and added to the total payable calculation opw-5939550 Forward-Port-Of: odoo/odoo#254450 Forward-Port-Of: odoo/odoo#253555
This update corrects a visual issue where menu items on the website didn't align properly when using mobile view or hamburger menus. The fix adjusts how the menu items are styled, ensuring they align to the right or center based on the user's selection. This improves the overall user experience on mobile devices.
Original PR description
Steps to reproduce: =================== 1- Enter the website editor 2- Enable mobile view 3- Edit the alignment of the mobile menu to be center or right aligned The group labels (e.g. "Shop",…
Steps to reproduce: =================== 1- Enter the website editor 2- Enable mobile view 3- Edit the alignment of the mobile menu to be center or right aligned The group labels (e.g. "Shop", "Forum") stay left-aligned regardless of the chosen alignment. This can also be seen on desktop by switching to the sidebar header template. Cause: ====== The class .accordion-button uses `display:flex` and `text-align:left` and that class is used for the menu groups labels. this prevents the alignment from working. Solution: ========= When right-aligned (`text-end`), reverse the flex direction so the arrow moves to the left and the text stays on the right. When centered (`text-center`), let the text span fill the remaining space and center its content via `text-align: center`, keeping the arrow on its position. The default left-aligned case is unchanged. opw-5494765 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244565
This update fixes a bug where users could confirm popups with empty input fields, such as gift card codes. Now, the confirmation button is disabled if the input is blank or contains only spaces, ensuring data integrity and preventing incorrect transactions. This impacts key features like adding floors and generating gift cards.
Original PR description
*= point_of_sale, pos_loyalty, pos_restaurant Before this commit: =================== - User was able to confirm `TextInputPopup` with an empty input value. Affected functionalities: - Add New Floor - Rename Floor / Table - Enter Code (Gift card or Discount code) - Generate a Gift Card After this commit: ================== - The confirm button will be disabled if the input value is empty or has only spaces so that an empty string will not be accepted. Task-6019160 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254994 Forward-Port-Of: odoo/odoo#253307
This update resolves an issue where cross-origin requests with the Range header were failing due to preflight checks. The change adds the necessary header to allow these requests to succeed, improving the reliability of external integrations. While future customization is considered, this fix addresses a specific, previously undetected problem.
Original PR description
Previously, specifying the Range header in a CORS request would result in a preflight failure even if cors was enabled on the route. It is sometimes desirable to allow querying ranges even in a CORS context. It may be desirable at some point in the future to allow controllers to customize their preflight responses more thoroughly, but considering this hasn't really be an issue before, it seems premature. Instead, this commit just adds the Range header to the Allow-Control-Allow-Headers response header to allow such requests to succeed. Forward-Port-Of: odoo/odoo#254805
This update fixes a technical error that prevented the generation of 281.10 reports for Belgian payroll companies. The issue stemmed from a missing vehicle ID in the payroll data, which was resolved by recalculating vehicle information using pay slip line IDs. This ensures accurate report generation.
Original PR description
[FIX] l10n_be_payroll: fix traceback in 281.10 sheets
Bug reproduction: Go to any version>=17.0 -> select belgium company -> install only belgium payroll (don't install fleet one) -> fill in niss, certification level, address, Time in R&D -> generate payslip and confirm it -> try to generate 281.10 report -> traceback
Bug cause:
1 - In traceback it was saying payslip doesn't have vehicle_id, in 281.10 sheet preparation (in function _get_atn_nature), there is a term like that
2 - Payslip doesn't have it because fleet module is not there.
Bug solution:
1 - Instead of checking the payslip has vehicle like that, we calculated it by using paylsip line_ids
2 - If the code ATN.CAR is there and the total of it is not zero, which means this payslip has a vehicle indeed.
task - 6037206
Forward-Port-Of: odoo/enterprise#110860This update resolves an issue where long tax amounts on invoices were causing display problems. The fix ensures that tax totals are correctly rendered, regardless of the number of digits, improving invoice clarity for users. This impacts the Ke edition of Odoo Enterprise.
Original PR description
This commit aims to: Fix Display issue when the amount is long. task-5162891 Forward-Port-Of: odoo/enterprise#110649 Forward-Port-Of: odoo/enterprise#100319
This update resolves a recurring issue where the Italian POS printer would generate errors when the system was offline. The fix adds a safety mechanism to gracefully handle network disruptions during receipt printing, preventing errors and improving the user experience for Italian businesses using the POS module. This ensures reliable operation even without an internet connection.
Original PR description
When loosing internet connexion a lot of tracebacks appear is the pos if we use the italian fiscal printer. Steps to reproduce: ------------------- * Setup italian fiscal printer for a shop * Open shop * Turn wi-fi off * Add items to cart * Go to payment screen > Traceback * Add a payment and validate > Traceback Why the fix: ------------ Don't try to reach the printer if we're offline regarding the price to pay. We add a try catch block around the call for printing the receipt. If the try block fails when the network is offline we assume it's just because of the offline mode. If it failed while online we raise the error. opw-5432090 Forward-Port-Of: odoo/enterprise#110326 Forward-Port-Of: odoo/enterprise#105515
This update fixes a formatting issue in Odoo's XML files related to Danish VAT returns (OIOUBL21). The 'DK' prefix was missing, which is now added to the PartyIdentification text to ensure compliance with Danish tax regulations. This ensures accurate data transmission and avoids potential processing errors.
Original PR description
In this commit af94099c4d74e9c48251a1c1656e3ad11b9f8a70, we made a fix regarding OIOUBL21 XML files, but we forgot to add the 'DK' prefix for CVR nemhandel identifier. The format should be 'DK' + nemhandel_identifier_value. no-task Forward-Port-Of: odoo/odoo#254430
This update addresses a previous issue where exporting XML from bills resulted in incorrect customer and supplier information. The button has been removed for non-self-bill invoices to prevent customer confusion. This ensures data integrity during import processes.
Original PR description
Problem --------- Currently, in the bills list view, when you select bills > Print > Export XML; not-imported bills gets their customer and supplier party inverted. This is because the XML export of those trigger the XML computation which is not designed for bills but only for invoices or self-bills. For imported bills (coming from Peppols for example), we re-use the imported XML. Since XML export of created bills is not supported anymore. The button leaves customers confused as to why their partner are inverted in the XML. Solution --------- Don't show the "Export XML" if one or more move are selected for the import and don't compute the XML for bills that are not self-bills. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where multi-select rectangles on scaled PDF signature pages were inaccurately drawn, leading to incorrect selections. Additionally, the update resolves a potential error when dropping elements and ensures helper lines align correctly during dragging. This improves the overall usability and reliability of the signature process.
Original PR description
When drawing the multi-select rectangle on scaled PDF pages, the rectangle corner was not properly synchronized with the mouse pointer, leading to inaccurate selection. Additional fixes: - An uncaught error could be triggered when dropping elements on the page. - Helper lines during dragging were not accurately aligned around sign items. task-6049004
A bug in Odoo's testing framework was causing freezes due to an infinite loop. This has been resolved by switching from an array to a set data structure, preventing the framework from repeatedly accessing the same data and avoiding the loop. This ensures the stability of the Odoo system.
Original PR description
Problem: Triggering the `child_of` operator in the testing framework caused an infinite loop that froze Odoo. This occurred because the framework attempted to fetch all children of the root operand without accounting for already visited nodes, resulting in children being added indefinitely. Solution: Switched from using an `array` to `set` to prevent duplicate traversal. Task-6023290 Forward-Port-Of: odoo/odoo#255067 Forward-Port-Of: odoo/odoo#254857
This update resolves an issue where documents uploaded to the 'All' folder in the Documents app were not viewable through the bridge interface. The fix ensures that uploads to 'All' now default to the standard bridge folder, restoring full accessibility for users.
Original PR description
Problem: When a user uploads a document through a bridge to the Documents app, if the destination is set to the `All` folder, the file becomes unviewable from the bridge. It can only be accessed directly via the Documents app. Cause: This occurs because `All` is not an actual folder. Uploads directed to it default to the `My Drive` folder instead. Because `My Drive` is restricted and inaccessible via the bridge, the uploaded documents remain hidden. Solution: To solve this problem, this PR ensures that uploads directed to the `All` folder default to the default bridge folder rather than to `My Drive`. task-6023290 Forward-Port-Of: odoo/enterprise#111439 Forward-Port-Of: odoo/enterprise#111290
This update ensures that all required address fields (street, city, zip, state, and country) are included when generating seller addresses on e-invoices for Viettel. This change is necessary to meet Viettel's EDI requirements and avoid potential invoice rejection issues, ensuring compliance and accurate reporting.
Original PR description
The seller address on e-invoices was missing some fields. This commit updates the logic to include street2, city, zip, state, and country when generating the seller address, ensuring full address details are provided in compliance with Viettel EDI requirements. task-6040875 Forward-Port-Of: odoo/odoo#254564
This update fixes an issue where repositioning PDF sign items caused inconsistent resizing behavior due to multiple event listeners being attached. The change ensures only one resize listener is registered, resulting in a more stable and predictable user experience when working with PDF signatures. This improves the reliability of the sign request process.
Original PR description
Previously, repositioning a sign item inside the PDF iframe would attach multiple resize event listeners. This led to inconsistent and unintuitive resizing behavior. This commit ensures that only a single resize listener is registered per item, avoiding duplicated handlers and restoring stable interaction. task-6048759 Forward-Port-Of: odoo/enterprise#111146
This update corrects a bug where a down payment line was incorrectly added twice to POS order settlements when automatic invoicing was enabled. The fix ensures that only the initial down payment line is processed, preventing data duplication and ensuring accurate order totals. This improves the reliability of POS transactions.
Original PR description
Case 1: --- **Steps to produce:** - Install `pos_sale` module. - Enable `Automatic Invoice` in settings - Create a new SO with product price 1000. - In `Other Info`, set `Online Payment` to 30%. -…
Case 1: --- **Steps to produce:** - Install `pos_sale` module. - Enable `Automatic Invoice` in settings - Create a new SO with product price 1000. - In `Other Info`, set `Online Payment` to 30%. - Preview > make payment > down payment of 300 is created in SO. - In POS, open Furniture Shop register > Actions > Quotation/Order > select the SO > settle order. **Issue:** - The down payment line is added twice in the POS order. **Root cause:** - At [1], `sale_order.amount_paid` = 300, so `addDownPaymentProductOrderlineToOrder` adds the line in order. - At [2], the down payment line from the SO is added again. - Here, when `Automatic invoice` is on and we make the online payment then `amount_paid` is updated and the downpayment invoice is also created. - So, we have also downpayment line in sale order also. **Solution:** - Ensure that if a downpayment line has already been added to the POS order, the first downpayment line matching `amount_paid` is skipped. [1]: https://github.com/odoo/odoo/blob/54a62bdbe927108a7f85374db26787f8ba45f6ac/addons/pos_sale/static/src/overrides/models/pos_store.js#L88-L93 [2]: https://github.com/odoo/odoo/blob/54a62bdbe927108a7f85374db26787f8ba45f6ac/addons/pos_sale/static/src/overrides/models/pos_store.js#L109-L111 Before: <img width="484" height="279" alt="image" src="https://github.com/user-attachments/assets/c803c9bd-0751-4a90-81f4-8fb3da3b393e" /> After: <img width="490" height="235" alt="image" src="https://github.com/user-attachments/assets/2ec4ac43-1db3-4c2e-bfcf-8c52a4830dac" /> Case 2: --- **Steps to produce:** - Install `pos_sale` module. - Enable `Automatic Invoice` in settings - Create a new SO with product price 1000. - In `Other Info`, set `Online Payment` to 30%. - Preview > make payment. **Issue:** -The computed value of amount_unpaid is 400, whereas it should be 700. **Root cause:** - When Automatic Invoice is enabled and an online payment is made, the invoice is automatically created and amount_paid is also updated. - At [3], the logic subtracts both the total invoice amount and amount_paid from the actual total, which results in an incorrect calculation. **Solution:** - When an online payment is made, a transaction is created and linked to an invoice. - While computing the total invoice amount, if the transaction’s invoice ID is encountered again, it should be skipped to avoid double-counting. [3]: https://github.com/odoo/odoo/blob/75f6be6744006ed1a3c0857881822723f90f5d4a/addons/pos_sale/models/sale_order.py#L46-L51 opw-5415404 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254964 Forward-Port-Of: odoo/odoo#242026
This update fixes an issue in our tax reporting calculations, specifically when using 'trimester' tax periods. The previous calculation incorrectly identified date boundaries, leading to inaccurate report values. This change ensures correct reporting for carryover tax scenarios, improving data accuracy for financial reporting.
Original PR description
To reproduce the issue: - Setup tax periodicity to "trimester" - Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly…
To reproduce the issue: - Setup tax periodicity to "trimester" - Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly Italian tax report for an example) - Create the appropriate data so that in the current trimester, the report line evaluates to 42, and to 1 in the previous trimester - Open the report for the second month of the trimester => The line has value 42, while it should have 1. This happens because the date bounds for previous_tax_period were computed too naively, considering the date_from was always the first day of the tax period. The first day of the second month of the trimester, it's not the case, and we return the period boundaries of the day before that day. That day is the last day of the first month of the trimester, but belongs to the same trimester, so it's the same tax period. Therefore, we display the value of the current tax period, which is wrong. Forward-Port-Of: odoo/enterprise#111330 Forward-Port-Of: odoo/enterprise#110504
This update corrects a bug that was causing incorrect leave calculations within the holiday accrual process. The issue stemmed from an inconsistent field being used instead of the correct variable, which could lead to an infinite loop. This fix ensures accurate leave accruals and prevents potential errors.
Original PR description
## Issue Oblivion regarding community-239836 The field `leaves_taken` (which shouldn't be accessed from the `_process_accrual_plans` method because it is inconsistent/can lead to infinite loop, see the related PR explanation) is used instead of the variable `leaves_taken`. robodoo up to saas-18.4 included Forward-Port-Of: odoo/odoo#253076
This update improves how charges are handled on invoices generated for UBL/BIS3 transactions. Instead of creating a new invoice line for charges, the charge amount is now directly added to the original invoice line's price unit. 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#254620 Forward-Port-Of: odoo/odoo#254111
This update ensures the SDWorx payroll report accurately reflects employee attendance by now considering public holidays. Previously, the report didn't account for resource calendar leaves, leading to incorrect attendance calculations. This fix improves the accuracy of payroll reporting for Belgium.
Original PR description
### Steps to reproduce: - Setup a public holiday in a month January for example - Add a leave for an employee for the whole Month of January - Export the SDworx report - Notice for the day of the public holiday, it is shown as a normal attendance ### Cause: When checking leaves for the SDWorx report we only check hr.leave we don't check resource.calendar.leaves ### Fix: We take resource.calendar.leaves now into account to make sure we add public holidays to the report when exporting it opw-5500070 Forward-Port-Of: odoo/enterprise#106065
This update resolves a technical issue causing emails to be rejected by strict email servers. By preventing the folding of subject headers, Odoo ensures emails are properly formatted and delivered, improving email communication reliability. This change aligns with best practices for email delivery.
Original PR description
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554…
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes odoo/odoo#250388 See-also: #243119 Backport: #247057 Forward-Port-Of: odoo/odoo#254670