Daily updates from Odoo
Friday, March 20, 2026
36 changes · 18.0
New functionality added to Odoo
This pull request updates the .weblate.json files to include translations for additional modules within the Odoo Enterprise system. This ensures that all user-facing content is accurately localized for different languages, improving the user experience for international customers. It's a routine maintenance task to maintain the quality of our translations.
Original PR description
Related: https://github.com/odoo/odoo/pull/254667 Forward-Port-Of: odoo/enterprise#111141
This pull request adds missing language translations for several Odoo modules, specifically within the 'pos_restaurant_stripe' add-on. These translations ensure the add-on is correctly localized for Arabic, Azerbaijani, Bulgarian, Croatian, Estonian, Farsi, Finnish, French, Hebrew, Hindi, Hungarian, and Spanish-speaking users. Completing these translations improves the user experience and expands Odoo's global reach.
Original PR description
Related: https://github.com/odoo/enterprise/pull/111141 Forward-Port-Of: odoo/odoo#254667
This update incorporates a new rule (SE-R-005) from the PEPPOL BIS3 standard for electronic invoices. This ensures Odoo complies with European regulations for invoice billing, specifically related to the SE-R-005 rule, improving our compliance and accuracy in handling international invoices.
Original PR description
Rule information: https://docs.peppol.eu/poacc/billing/3.0/2025-Q4/rules/ubl-peppol/SE-R-005/ OPW-5881918 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250657
Enhancements to existing features
This update simplifies how Odoo ranks leads based on confidence, making it easier for developers to customize the ranking without needing to overhaul the entire sorting process. By creating a dedicated helper function, this change reduces complexity and improves the maintainability of lead prioritization logic, particularly for merging leads.
Original PR description
The lead confidence ranking used by `_sort_by_confidence_level()` is currently defined inline in the sorting method itself. This makes implementation-specific customizations harder than necessary, as custom modules need to override the whole method even when they only want to adjust the ranking criteria. Extracting the sort key computation into a dedicated helper keeps the default behavior unchanged while providing a smaller and clearer extension point for deployment customizations. This reduces override complexity and makes future adaptations of lead merge priority easier to implement and maintain. 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
Resolved issues and error corrections
This update corrects a bug where changes to view ordering within the Odoo Studio interface weren't consistently applied. The fix involved updating the default order setting on the relevant database model, ensuring that view order changes made through the Studio are now correctly reflected. This improves user experience and simplifies view customization.
Original PR description
Bug === When changing the order of the views using studio, it wasn't applied. The reason is that we add a default order at the wrong place in JS, it should be done with the attribute made for that, `defaultOrderBy` on the relational model. Task-6047024
This update corrects a bug in the Sendcloud delivery service that was caused by incorrect Python slicing. The fix ensures that the intended first element is retrieved, preventing an error. The issue was not caught during testing due to missing CI test runs.
Original PR description
Slicing in Python returns a sub-list, even for a single element. Doing `res[:1]` does not return the first element so doing `.get` causes an error. This was not caught because the tests do not run in CI due to the tags on the class.
This update fixes a visual problem where the map view in the "My Dashboard" sometimes collapsed or didn't display correctly. The changes removed conflicting height settings and added a minimum height to the map, ensuring it always occupies the appropriate space and displays reliably.
Original PR description
This commit fixes rendering height issues when the map view is displayed inside "My Dashboard". * Removed `height: 100%` from the map and pin list containers. This conflicting rule interfered with the flexbox layout, often causing the map to collapse entirely since it couldn't compute its own height. * Added a `min-height` to the map renderer. This ensures the map always occupies a reasonable amount of space in the dashboard, even when there are few or no records to display. task-6022958 Forward-Port-Of: odoo/enterprise#110968 Forward-Port-Of: odoo/enterprise#110790
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 'All' folder uploads 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
This update resolves an issue preventing invoices with discounts and decimal values from being correctly formatted for ARCA (Argentine Electronic Invoice). The fix uses a truncated unit price for discount calculations to ensure accurate decimal precision, avoiding errors related to WSFEX 1812.
Original PR description
After changes made in Odoo of how the decimal precision works some of the code we use to prepare the data to create EDI invoices now fails. We already adapt the code to fix the data depending of the expected webserive format but we miss a case related to when invovice has discounts. The problem is that any invoice with lines that has more than 2 decimals and also have a discount will fail when trying send it to ARCA because the computed amount has differences in the decimals. Now we use the truncated unit price to compute the discount instead of the full amount with decimal of the `line.price_unit` value.
This update corrects a bug that caused the Odoo purchase order data fetching process to fail when the last fetch date was reset to 'False' on a company. The fix ensures that cron jobs run smoothly and reliably, preventing data synchronization issues. This improves the accuracy of purchase order information.
Original PR description
In case the purchase last fetch data is resetted to `False` on the company, the next cron run will crash with: `type object 'datetime.datetime' has no attribute 'datetime'` This commit fix the wrong default date fallback. opw-5220129 Forward-Port-Of: odoo/enterprise#111124
This update fixes an issue in our tax reporting module where calculations for previous tax periods were inaccurate, particularly with trimester-based tax periods. The change ensures correct period boundaries are used, preventing incorrect report values and improving the reliability of tax reporting data. This impacts financial reporting accuracy.
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#110504
This update corrects a visual issue where the company header in accounting reports appeared grayed out in dark mode. The change ensures the header uses a consistent muted color scheme across all Odoo environments, improving the user experience and visual appeal.
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#110108
This update fixes a discrepancy in the French Profit & Loss report. The report was incorrectly double-counting account 649, leading to inaccurate financial totals. The fix ensures that account 649 is correctly categorized within the 'Wages and Salaries' section, aligning with French accounting standards and improving report accuracy.
Original PR description
**Steps to reproduce:** 1. Install module `l10n_fr_reports`. 2. Switch the company to a French localization. 3. Go to Accounting > Reporting > Profit and Loss. 4. Open the section **Operating Expenses**. 5. Check amounts in *Social security charges* and *Wages and salaries* from info. **Issue:** Account 649 was included in two sections of the Profit and Loss report: *Salaires et traitements* (Wages and salaries) *Charges sociales* (Social security charges) Because of this duplication, the total amount in the P&L report does not match the expected accounting values. **Solution:** Remove accounts *649%* from the *Social security charges* section so they are only counted in *Wages and salaries*, which aligns with the expected French accounting structure. Confirmed with PO opw-5976865
This update ensures that changes to a subscription's salesperson are automatically reflected for all associated contacts. Previously, updates only applied to the main company partner, leading to inconsistencies. This change improves data accuracy and reduces the need for manual updates.
Original PR description
Before this commit, changing the salesperson on a subscription only updated the company partner, leaving child contacts with outdated salesperson info. After this commit, updating the subscription's salesperson also updates all child contacts of the company, ensuring consistency across the portal and reducing manual work. An unit test was added to ensure this behavior. task-5917271
This update resolves an issue where cross-origin requests with the Range header would fail due to preflight checks. The fix adds the necessary header to allow these requests to succeed, improving compatibility with external systems. While future customization of preflight responses is considered, this change 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.
This update corrects a bug where a down payment line was incorrectly added twice to POS order settlement. When automatic invoicing is enabled and online payments are processed, this fix ensures that down payment lines are only created once, streamlining the order settlement process and preventing data discrepancies. This improves the accuracy 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
This update fixes an issue where purchase order descriptions weren't accurately displaying the correct vendor code and name after a product was switched from a PO to a sales order. The fix ensures that the description always reflects the current vendor information, improving data accuracy and order clarity. This resolves a discrepancy in how the system generates descriptions based on PO and SO changes.
Original PR description
How to reproduce : - Create a product - Create an attribute with a value set to "free text" - Add 2 different vendors to the purchase tab of the product with different Vendor Code and/or Vendor Name…
How to reproduce : - Create a product - Create an attribute with a value set to "free text" - Add 2 different vendors to the purchase tab of the product with different Vendor Code and/or Vendor Name - Put Dropship as the route for the product to create a PO on a SO confirmation - Create a SO with that product - Confirm the SO and go to the PO - Change the vendor in the SO The problem : The Vendor Code and/or Vendor Name does not change correctly in the product description Why : The way the description generation for a change in a purchase order line works as follows : Create a collection of default descriptions based on the product and the different vendors. If the collection contains the current description, it means the description was not changed by the user and it can be modified. This is done to prevent resetting a custom description made by an user. This logic is pretty broken because the code that generate the description when going from a PO to a SO and the code that generate the description when changing the PO partner are different. This makes it so the current description is almost never found in the list of default descriptions. It looks tempting to try to "resynchronize" those part of the code so the description generation is the same in both cases. This would be done by overriding the _get_product_purchase_description method in the purchase_stock module and using the product_description_variants field. Sadly, this does not work because it conflicts with the purchase_product_matrix module and its own override of that method. The fix that I implemented checks that the Vendor Code and Name are the right one every time the description is computed following a change. opw-5888233 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update optimizes how Odoo loads its registry, significantly reducing the time it takes to start up, especially for systems with a large number of installed applications. By avoiding unnecessary file system scans, the change dramatically improves performance and responsiveness, particularly for high-traffic scenarios.
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 where the 'Recipient Bank' field on credit notes wouldn't display partner bank accounts. The system now correctly filters bank accounts based on the expected recipient, enabling users to properly record credit notes with partner bank details. This ensures accurate financial reporting.
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#252961
This update fixes a bug where users could accidentally confirm popups with empty fields. Now, the 'Confirm' button is disabled if the input is blank or contains only spaces, ensuring data integrity for key processes like adding floors, generating gift cards, and managing discount codes. This improves the overall user experience and prevents incorrect data entry.
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#253307
This update resolves issues related to payment processing within Odoo's Point of Sale system. Specifically, it corrects an error caused by multiple payment methods on a single order and ensures that a customer is required when using certain payment methods (like receivable or cash exceeding 10,000 JOD).
Original PR description
This commit fixes the following issues 1) Having more than one payment method on a pos.order led to an error 2) Customer should be required if payment method is receivable, or cash with amount > 10,000 JOD task-6005832
This update fixes an issue where users with limited access to the accounting module couldn't successfully import vendor bills in XML format. The change ensures that these restricted users receive a traceback when attempting to import, preventing incorrect processing. This improves data integrity and security.
Original PR description
[FIX] account_edi_ubl_cii: restricted access user cannot import bill To reproduce: - create a user that has readonly access in Accounting - try to import a XML in vendor bills -> should traceback This commit modifies the `res_field` assignation by setting both `res_model` and `res_id` at the same time Forward-Port-Of: odoo/odoo#254698
This update ensures that e-invoices include complete seller address information, specifically street2, city, zip, state, and country, as required by Viettel EDI regulations. Previously, missing address fields caused potential compliance issues. This change ensures accurate invoicing and avoids potential delays or rejections.
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
This update fixes a display issue where the 'Pick Up in Store' option was incorrectly shown for products with excluded tags. The change ensures that unavailable delivery options are hidden from the product page, providing a consistent and accurate customer experience. This aligns with the existing checkout behavior.
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-prA bug in the Odoo 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 duplicate processing and ensuring tests complete successfully. This improves the stability of the Odoo platform.
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
This update corrects a bug that was causing incorrect leave calculations within the holiday accrual process. The issue stemmed from an inconsistent data field being used, which could lead to an infinite loop. This fix ensures accurate leave tracking and prevents potential errors in holiday accruals.
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
This update corrects issues with the XML structure generated for Spanish electronic invoices (l10n_es_edi_facturae). Specifically, it ensures tax calculations are accurate and rounded correctly, addressing a previous bug. This improves the reliability of invoice data transmission.
Original PR description
- Adjusting invoice-level `<TaxesOutputs>` nodes to be generated per tax rather than per line - Enabling rounding for invoice-level tax data aggregation - Adding a second rounding test derived from bug ticket task-6009108 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where PDF merging errors didn't consistently display user-friendly error messages. The fix adjusts the internal function call to ensure the correct error handling mechanism is triggered, improving the user experience when PDF merging fails. This ensures a more robust and informative error display.
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-prThis update corrects a validation error in the ZATCA XML generation process for Saudi Arabia companies. The change ensures that invoice cash rounding amounts are included in the payable calculation, resolving a mismatch that caused validation failures. This ensures accurate invoice data for ZATCA reporting.
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#253555
This update makes Odoo's timesheet system more efficient by only refreshing public holiday timesheets when an employee's calendar changes. Previously, updates were triggered unnecessarily, leading to wasted processing. This change improves performance and reduces the load on the system.
Original PR description
Reference: opw-5938425 …imesheet regen When hr.employee.write receives resource_calendar_id, we now compare old and new calendar IDs per employee and only refresh public-holiday timesheets for employees whose calendar actually changed. This avoids needless delete/recreate churn on no-op writes while preserving the same behavior for real calendar changes. 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#253349
This update corrects a display issue where removed form fields were still appearing in newly created project tasks. The change prevents the automatic addition of default values for missing fields, ensuring task descriptions are clean and accurate. This improves the user experience when reviewing tasks created through the website contact form.
Original PR description
# How to reproduce - Add a contact form to your website - Make it so the contact form creates a task on submit - Remove some field from the contact form, but no the email (ex: Phone) - Fill in the contact form; the email must be from one of the existing partners - Submit the form and go look at the task in the project application # The problem The fields removed from the form are still present in the task's description (ex: partner_phone: False) # Why This commit (https://github.com/odoo/odoo/commit/7d0660e034f3be1b92869c266dc2cfb0bc6b6941) changed the way the partner's data was added to the description. When adding that data, it does not check if it exists before hand and instead adds a default value if not found. opw-5920816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a visual issue in the Point of Sale payment screen on larger displays. Previously, too many payment methods would cause the screen to break. Now, the layout has been adjusted to handle multiple payment methods gracefully, ensuring a consistent and functional user experience.
Original PR description
Description of the issue/feature this PR Currently, when the number of payment methods exceeds the available space, the payment methods overflow and breaks the UI in large screens. Current behavior before PR: How it looks currently in large screen <img width="50%" alt="image" src="https://github.com/user-attachments/assets/937dec13-50e3-4f7b-b573-4e526f683617" /> Desired behavior after PR is merged: <img width="50%" alt="image" src="https://github.com/user-attachments/assets/09f01d39-700d-47a7-86aa-3451ac77e553" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures the Odoo spreadsheet component is running the latest version (18.0.60). It addresses a bug related to pasting values into spreadsheets, improving the user experience. Multiple developers collaborated on this fix.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/562645fb97 [REL] 18.0.60 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/1198bbd7b1 [FIX] clipboard : paste as value [Task: 5936382](https://www.odoo.com/odoo/2328/tasks/5936382) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update corrects a formatting issue in Odoo's XML files related to Danish Nemhandel invoices. The 'DK' prefix was missing, which is now added to the PartyIdentification text. This ensures proper compliance with Danish tax regulations and improves the accuracy of invoice data exchange.
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
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 editing 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#250372
This update resolves a crash that occasionally occurred when users attempted to print from the Odoo dashboard. The fix ensures the dashboard's print function operates reliably, preventing disruptions to users' workflows. This improvement enhances the overall stability and usability of the dashboard for all users.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254815