Daily updates from Odoo
Navigate
Branch
Saturday, January 24, 2026
80 changes
39 changes
New functionality added to Odoo
This update introduces a new Know Your Customer (KYC) process for Belgian users registering through the Peppol network. It leverages the Itsme service to streamline identity verification, improving compliance and security for our Peppol customers. This enhancement simplifies the onboarding experience and ensures adherence to regulatory requirements.
Original PR description
Add KYC for Belgian Peppol users through Itsme. task-5478657 Forward-Port-Of: odoo/odoo#239520
Enhancements to existing features
This change updates the source of lead mining data within the IAP module from Clearbit to Dun & Bradstreet. This aligns with existing data usage for partner autocomplete and ensures we're leveraging a reliable provider for improved lead insights. This update is part of a broader migration to the IAP discovery service.
Original PR description
Before this commit: - Lead mining data was fetched from `clearbit` provider on IAP which is now going to be removed for discovery service After this Commit: - Data will now be fetched from `dun_and_bradstreet` provider on IAP which we are already using for the `partner_autocomplete` IAP PR: https://github.com/odoo/iap-apps/pull/1274 task-4873238 Forward-Port-Of: odoo/odoo#244437 Forward-Port-Of: odoo/odoo#235521
This update enhances the testing process for paying invoices with bank statement lines within the Odoo accounting module. The change introduces a reusable test helper, streamlining testing and improving the reliability of invoice payment scenarios. This ensures accurate and consistent invoice payment processing.
Original PR description
Forward-Port-Of: odoo/odoo#244377 Forward-Port-Of: odoo/odoo#244281
This update ensures Odoo correctly handles the new 11% and 21% VAT rates introduced in Romania. By adding missing tax mappings, the system now accurately reflects the latest Romanian VAT regulations and ensures proper fiscal position calculations.
Original PR description
The new 11% and 21% taxes introduced with the updated Romanian VAT law were added with this commit https://github.com/odoo/odoo/commit/2026212d0f7ffc217be3c6a2ff2abe5288c18afb , but some tax mappings were missing. This commit completes the setup by adding the required tax mappings, ensuring the new rates work correctly with fiscal positions. task-5480159 Forward-Port-Of: odoo/odoo#245050 Forward-Port-Of: odoo/odoo#243452
Resolved issues and error corrections
This update fixes an issue where invoice costs weren't accurately calculated when linked to stock moves. Now, the cogs price unit uses the standard price and FIFO calculations are based on actual stock levels. This ensures more precise cost reporting for invoices.
Original PR description
This commit makes the cogs computation correct again. In case the invoice has some linked stock move, the cogs price unit will be the standard price in 'standard' and 'avco'. The fifo computation will be the based on the stack. Computing cogs value will ignore the potential owner_id set in the stock move related to the invoice being posted when computing the cogs price unit in `_get_price_unit()`. This commit looks up related stock move of the invoice for all cost method to compute the cost based on the valued stock move line. This commit also re-enable the anglosaxon tests related to outgoing flow opw: 5266208 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243586
This update corrects a bug that prevented users from adding inputs to payslips. The fix ensures that the correct salary input domains are applied across all relevant models, allowing for accurate payslip creation. This resolves an issue where only employee-specific salary inputs were displayed.
Original PR description
When trying to add Inputs for a payslips none appear as the domain was incorrect and only showed salary inputs for use in the employee. This is fixed in this commit by adding to the domain en each specific model. task-5486091 Forward-Port-Of: odoo/enterprise#103986
This update corrects a bug preventing the system from consistently updating the source location when changing it during delivery processing. Previously, changes weren't saved, requiring users to re-scan. Additionally, the fix ensures only relevant lines are active when scanning a source location, improving efficiency and accuracy.
Original PR description
This PR fixes the bug of not making the source location persistent when changing it from the form view. To reproduce the bug: 1- Create a product tracked by lot. 2- Create 3 different lot locations…
This PR fixes the bug of not making the source location persistent when changing it from the form view. To reproduce the bug: 1- Create a product tracked by lot. 2- Create 3 different lot locations with each having a quantity of 100. 3- Create an out delivery of 140 and notice 100 are assigned from the first lot and 40 are assigned from the second lot. 4- Set the scanning source location to be mandatory in Barcode for deliveries. 5- Go to Barcode app, navigate to the delivery, you find it mandatory to scan a source location. 6- Scan the source location for the first lot location, choose the product and click on the edit pen icon. 7- Choose another lot location as your source location, let it be the third lot location and confirm. 8- Choose to assign the qty by clicking on the +100 button. = See that the new chosen source location is not persistent. The fix: After this PR, if you follow the steps up to step 7 and after you confirm your new source location, the Barcode makes the lines inactive again and asks you to scan the source location (since it's mandatory) and it also shows the new source location on the line. Another fix this commit addresses is that when you scan a source location, only the lines with this location are active to choose/edit not all the lines. Task-4809491 Forward-Port-Of: odoo/enterprise#97777
This update resolves an issue where session information was lost during scale operations with IoT drivers. By correctly passing the session ID, the Odoo server now properly acknowledges requests from these drivers, ensuring reliable communication and data processing. This improves the stability and functionality of the IoT integration.
Original PR description
[FIX] iot_drivers: propagate session_id in scale and generic drivers Before this commit, `session_id` was lost during scale operations because `ScaleDriver` overwrote `self.data` instead of updating it, erasing the context. Additionally, the generic Driver class stored the ID as "owner", causing a TypeError on the server which expects "session_id". After this commit, `ScaleDriver` uses `.update()` to preserve the session context, and `Driver.action` correctly uses the key `session_id` in the response payload. This ensures requests are properly acknowledged by the Odoo server. opw-5485278 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses a technical adjustment to the checksum within the l10n_eu_iot_scale_cert module. This change was necessary due to a recent code update to resolve a bug. Updating the checksum ensures the integrity of the module's data and maintains system stability.
Original PR description
Checksum needs to be updated as the code of the scale changed for a bugfix Cummunity PR: https://github.com/odoo/odoo/pull/245048
This update corrects a technical issue within the l10n_tr_nilvera_einvoice module. The previous method calls ('get_param' and 'set_param') were removed, and this change ensures they are replaced with the correct, specific types as defined in the Odoo codebase. This ensures the module functions correctly and avoids potential errors.
Original PR description
The methods don't exist anymore. They should be replaced by the specific types. --- 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 VoIP demo mode, ensuring a helpful tooltip is displayed when hovering over the 'Demo Mode' indicator. Previously, the tooltip wasn't correctly shown, causing confusion for users. This change clarifies the demo mode functionality and improves the user experience.
Original PR description
## Context There are two modes in VoIP: _Production Mode_ and _Demo Mode_. Demo Mode enables you to simulate a call in the UI without actually calling someone. This is useful for showing customers…
## Context There are two modes in VoIP: _Production Mode_ and _Demo Mode_. Demo Mode enables you to simulate a call in the UI without actually calling someone. This is useful for showing customers the features and for developers to test the UI 💡 Though useful, this feature can be confusing. Users may not realize they aren't in Production Mode, and developers may forget to switch back to Demo Mode when testing the UI. 535a7aef3e410d997baa093cc111527814c29253 improved the situation by displaying "Demo Mode" in the Softphone header when Demo Mode is enabled. It was intended to include a tooltip explaining how to configure Production Mode when hovering over it. However, although the tooltip text is present in the code, it was not correctly mapped to the "demo indicator" ¯\\\_(ツ)\_/¯ ## In this PR After this commit, - the tooltip text is correctly provided to the "demo indicator", enabling it to be displayed on hover; - the tooltip text is slightly reworded in the hope of making it clearer. [Task-5804537](https://www.odoo.com/odoo/project/5778/tasks/5804537) Fix https://github.com/odoo/enterprise/pull/95742
This update fixes an issue where VAT import taxes were incorrectly mapping to accounts in the Odoo system. The change in a key account number required updating the default account used for taxes like purchase import VAT. This ensures accurate journal entries and proper financial reporting for VAT transactions.
Original PR description
Due to the change of account 33312 from liability to payable, the journal entries generated when creating bills with VAT import taxes were incorrect. This fix updates the default account on the following taxes: - tax_purchase_import_10 - tax_purchase_import_8 - tax_purchase_import_5 task-5695253 Forward-Port-Of: odoo/odoo#245082 Forward-Port-Of: odoo/odoo#244434
This update resolves a potential infinite loop issue that could occur when generating product attribute combinations, specifically with multi-checkbox attributes. The fix prevents redundant calculations by excluding lines with no values, ensuring stable and reliable product configuration.
Original PR description
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end…
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end of the list.
Suppose the order was arbitrary and we are generating combinations for two lines (the order here is important):
- Line (A) -> [] (multi checkbox type)
- Line (B) -> [attr_1, attr_2]
- The possible combinations are {(attr_1), (attr_2)}.
After generating the second combination the following 2 procedures happen.
- The value_index_per_line[1] will be resetted to -1,
- The line_index will decrement from 1 to 0.
Now, since the first line doesn't have any values, it will be skipped and the line_index will be incremented to 1.
This results in the redundant generation of the same combination, triggering an infinite loop.
Since this method yields a recordset of `product.template.attribute.value` model and the **multi-checkbox** attribute doesn't have a value being passed to the method anyways, we can exclude the lines that doesn't have values for the algorthim not to be stuck in an infinite loop.
opw-5267179
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#241557This update corrects a technical issue preventing invoices (specifically credit notes) from being properly validated for export to the Danish tax system (Nemhandel). The previous system incorrectly assumed the 'PrepaidAmount' field was always empty, leading to validation failures. Now, the system only removes this field when its value is actually zero, ensuring accurate invoice export.
Original PR description
To reproduce: create an invoice that is reconciled (typically a credit note) before Send&Print. Check the validity of the xml with a schematron => it fails due to the value of the PrepaidAmount The node PrepaidAmount gets removed because it was wrongly thought to be always empty. We now only remove it if the value is at 0. 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#242497 Forward-Port-Of: odoo/odoo#242008
This update corrects a bug where multiple calls to a loyalty program processing function (postProcessLoyalty) would overwrite previously set coupon information. This ensured that loyalty discounts and promotions were correctly applied to orders, preventing revenue loss and improving the customer experience. The change was made as part of a standard bug fix process.
Original PR description
Before this commit, when syncAllOrders was called more than once, for example when there were a preparation display, the second call to postProcessLoyalty would override the new_coupon_info set by the first call, resulting in the loss of information. The second call to confirm_coupon_programs is not an issue, as it's already handled. opw-5440543 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242087
This update fixes an issue where the user interface became unusable when the PIN modal appeared during clock-in. The change ensures the UI remains responsive and functional, providing a smoother experience for employees.
Original PR description
We now unblock the UI when the PIN modal appears, as it was unusable behind the loader telling "clocking in". Forward-Port-Of: odoo/enterprise#105039
This update fixes a critical issue where the Moroccan tax report XML export incorrectly handled cash basis accounting. The change ensures bills are accurately reflected in the export, aligning with Moroccan tax regulations. This improves data consistency and report reliability.
Original PR description
[FIX] l10n_ma_reports: tax report: properly consider cash basis taxes in the XML export Moroccan taxes are cash basis by default. The former version of the XML generation completely disregarded that,…
[FIX] l10n_ma_reports: tax report: properly consider cash basis taxes in the XML export Moroccan taxes are cash basis by default. The former version of the XML generation completely disregarded that, and always reported all bills in the period. Solving this requires using an SQL query so that cash basis can be properly computed, like in the report. This also makes the export much more efficient, and resilient to bigger amount of data. Steps to reproduce: - Install `l10n_ma_reports` and switch to the MA company - Create and confirm a bill: Bill Date: 10/01/2025 Vendor: Azure Interior Invoice Lines: Price 100, Taxes 20% (S 140) - Go to `Bank Reconciliation` - Add a transaction (Vendor: Azure Interior, Amount: -120 DH, any Memo) - Select the transaction and the invoice, then click Validate - Open the Tax Return for November. Section D should show data linked to the created invoice - Export the XML using the Gear → XML The created bill is missing in the XML and others may be present, showing inconsistent data opw-5002779 [IMP] l10n_ma_reports: call the report to compute the prorata value Searching explicitly for external values is a bad practice ; calling the report ensures consistency between the data displayed, and the one exported into the file. Forward-Port-Of: odoo/enterprise#104996 Forward-Port-Of: odoo/enterprise#104619
This update corrects a timezone discrepancy that was preventing invoices sent to ZATCA (Saudi Arabia's tax authority) from being processed correctly. The fix ensures the invoice time is formatted as Asia/Riyadh, aligning with ZATCA's requirements. This resolves a potential issue impacting invoice processing and compliance.
Original PR description
The time information added to the date of the invoice post for ZATCA in iso format which adds +03:00. However ZATCA expects the time to be sent as is in Asia/Riyadh timezone. - Set up a ZATCA company and onboard a journal - To simulate the timezone issue, replace the hour value with 23h in the following line: vals['l10n_sa_confirmation_datetime'] = datetime.combine(move.invoice_date, fields.Datetime.now().time()). (use .replace(hour=23))) - Create, confirm, and send an invoice to ZATCA opw-5373067 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#245366 Forward-Port-Of: odoo/odoo#243961
This update re-enables key test tours within the MRP Workorder module, ensuring proper functionality testing after recent changes. A dedicated test company has been created to isolate these tests from demo data, and a helper method has been added for easier test setup. This improves the reliability of our testing process.
Original PR description
This PR does 2 things: ## Create a test company Add a company dedicated to TestShopFloor's tests so those tests won't be affected by demo data anymore. ## Enable tours Until then, 10 tours related to Shop Floor were skipped after [a refactor of the Shop Floor](https://github.com/odoo/enterprise/pull/80469) design and functionality. This PR re-enables 7 of these 10 tests tour (3 remaining need more work to pass when demo data are installed.) Also it adds a test helper method, `_enable_settings`, to enable wanted setting(s) easily. [task-5365014](https://www.odoo.com/odoo/966/tasks/5365014) Forward-Port-Of: odoo/enterprise#105117 Forward-Port-Of: odoo/enterprise#88338
This update corrects a bug that caused incorrect valuation calculations for products in the AVCO category after a stock valuation adjustment. Specifically, the system was misinterpreting the valuation value, leading to inflated unit costs and total values. This fix ensures accurate inventory reporting for AVCO products.
Original PR description
**Steps to reproduce:** - Create a storable product "P1" - Product category: AVCO - Create a purchase order with 100 units of P1 at $10 - Confirm the PO and validate the receipt - Go to Inventory ->…
**Steps to reproduce:**
- Create a storable product "P1"
- Product category: AVCO
- Create a purchase order with 100 units of P1 at $10
- Confirm the PO and validate the receipt
- Go to Inventory -> Reporting -> Stock
- P1 unit cost is $10 and total value is $1000
- Click on $1000
- Select the first stock move
- Action -> Adjust valuation
- New value: $2000 -> Save
- Go back to Inventory -> Reporting -> Stock
**Problem:**
- The unit cost becomes $2,000 and the total value $200,000
When a valuation adjustment is made on an AVCO product, a `product.value`
record is created with the new total valuation value.
However, `product.value.value` can represent two different things:
- for a standard price update, `value` contains the new unit cost
- for a stock move valuation, `value` contains the total value of the move
When `run_avco` processes a `product.value` coming from a move valuation,
it incorrectly treats the value as a unit price and multiplies it by
the quantity
opw-5460829
Forward-Port-Of: odoo/odoo#244957This update corrects a display issue where the inventory count badge in the Barcode app incorrectly showed a request count for one company even when no count existed for another. The fix ensures the badge accurately reflects the current inventory count for the company the user is currently operating within, improving data accuracy and reporting.
Original PR description
Steps to reproduce: - Create two companies (A and B) - Create a storable product "P1" - Log in with company A - Update the on-hand quantity of P1 in company A only - From Physical Inventory, request an inventory count for P1 - Switch to company B - Open the Barcode application Problem: The inventory count badge in the Barcode main menu displays a request count created for company A, even though no inventory count exists for company B. The badge incorrectly shows "1" instead of "0". opw-[5472031](https://www.odoo.com/web#id=5472031&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#104065
This update fixes an issue where the reward line price was incorrectly reset to zero after multiple reward actions. The change ensures the reward line price remains accurate, reflecting the original product's sale price and discount, even after claiming the reward multiple times. This prevents incorrect calculations and ensures accurate order totals.
Original PR description
### Issue: Due to this issue, by clicking twice on `Reward` button on SO, reward line unit price will be reset to zero. #### To reproduce: 1- Create a `Buy X Get Y` program: rule: minimum quantity:…
### Issue: Due to this issue, by clicking twice on `Reward` button on SO, reward line unit price will be reset to zero. #### To reproduce: 1- Create a `Buy X Get Y` program: rule: minimum quantity: 3, product: `Large Desk Wood` reward: 1 `Large Desk Wood` for free 2- Create a SO, and add a line with 3 `Large Desk Wood` 3- Click on `Reward` button. A new line should be automatically created. The unit price should be the product sale price and line `Amount` should be 0. 4- Re-click on reward. The reward line price unit is set to zero. Expected: The reward line price unit should remain as product sale price with a discount of 100 and line.amount of 0. ### Cause and Fix: In `_reset_loyalty`, price_unit is set to zero. The method `compute_amount` depends on `price_unit`, which means setting `price_unit` will make amount to be recomputed: https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/sale/models/sale_order_line.py#L843-L844 https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/sale/models/sale_order_line.py#L848 https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/account/models/account_tax.py#L1613 Which leads to `_compute_price_unit`. In this compute, the unit price will not be recomputed if `technical_price_unit` and `price_unit` differ. https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/sale/models/sale_order_line.py#L606-L611 https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/sale/models/sale_order_line.py#L588-L595 So IMO if we want to recompute `price_unit`, we need to also reset `technical_price_unit` in `_reset_loyalty`. opw-5467623 Forward-Port-Of: odoo/odoo#244290
This update resolves a technical issue preventing grouping within the planning module's slot templates. The fix ensures parameters are passed to the correct order during data processing, enabling proper grouping functionality. This improves the reliability and usability of the planning feature.
Original PR description
Before this commit, it was impossible to group by on any field in `planning.slot.template` model, because the parameters given to the parent method of `formatted_read_group` method were not given into the right order. This commit makes sure the order is respected. Forward-Port-Of: odoo/enterprise#105211
This update removes the Sign menu item from Odoo's Discuss channels. Previously, this menu was incorrectly displayed, which was confusing for users. This change ensures Discuss channels function as intended, focusing on mail threads instead of offering the Sign feature.
Original PR description
Currently, the Sign menu item is displayed in discuss channels, which is not making sense. This was due to an incomplete check in the isDisplayed method of the SignRequestCogMenu component. To fix this, we enhance the condition to ensure that the menu item is not displayed when the current model is 'discuss.channel'. Discuss channels inherently support mail threads, but should not have the Sign menu item. task-5494751 Forward-Port-Of: odoo/enterprise#105201
This update prevents the OCR from automatically overwriting a user's address information when processing QR-bills. Previously, the system would incorrectly update addresses, leading to confusion and inaccurate vendor billing. This fix ensures address data is only populated if the QR-bill was the source of the information, improving data accuracy and user experience.
Original PR description
When the OCR detects that the document is a QR-bill, it will always overwrite the address information from the partner currently set on the record. We shouldn't do that if the partner wasn't created by the OCR. In the following scenario, it's pretty obvious why it is a bad idea: - User receives his QR-bills on his personnal email address. - He forwards it to the email alias set up for vendor bills. - A vendor bill is created with himself set as the supplier (already a bit annoying for him) - The OCR automatically analyses the document and updates the user's record with the address found in the QR-bill (really annoying). The same issue can arise if the user manually sets a supplier before sending the QR-bill for digitization. task-none Forward-Port-Of: odoo/enterprise#104902
This update resolves an issue where the l10n_cl_edi module was incorrectly creating duplicate vendor bills when receiving identical XML invoices via the incoming mail server. The fix prevents these duplicates from being generated, ensuring accurate billing records and avoiding potential accounting errors. This was triggered by a configuration setting within the Vendor Bills journal.
Original PR description
Steps to reproduce: - With a CL Company setup - Configure an incoming mail server with DTE server option enabled - In Vendor Bills journal, enable 'Use Documents?' - Receive the same XML twice via the incoming mail server - Check created vendor bills Issue: There will be duplicated bills. Each duplicate will show the message 'E-invoice already exist: nnnnn' However, the system should avoid duplicates from being created. opw-5362664 opw-5409700 Forward-Port-Of: odoo/enterprise#103211
This update resolves an issue where shared subfolders accessed via a link weren't initially displayed correctly for some users. The fix ensures that subfolders are immediately accessible after a shared link is used, eliminating the need for a manual refresh. This improves the user experience when sharing documents.
Original PR description
**Steps to reproduce:** - Create a portal user - Go to the documents app - Click on the marketing folder - Share the marketing folder through a link (Anyone with a link = viewer + discoverable) -…
**Steps to reproduce:** - Create a portal user - Go to the documents app - Click on the marketing folder - Share the marketing folder through a link (Anyone with a link = viewer + discoverable) - Copy the share link - Login with the portal user in an incognito window - Paste the share link in an incognito browser - Click on "brand 1" folder, result nothing is showing while there should be a folder and a picture - Click on "brand 2" - Click back on "brand 1" and now the folder and picture are visible - If you click on a subfolder of "brand 1" you also get an error **Issue:** Discoverable subfolders accessed using `accessToken` are not available on the first read of a user and this happens for each level of the hierarchy (refresh is needed each time). When using sharing link to display folders with a user, the subfolder document access is created on `/documents/touch/` using `_from_access_token`. But on the js side the call is delayed (with debounce) and occurs after the `web_search_read`. This means that subfolders are only accessible after a refresh or by switching back and forth between folders. Also, even after the folder is displayed, if there are other subfolders in it, going deeper in the hierarchy won't work as well without a refresh due to the `search_panel_select_range` missing the new folder. **Fix:** Not sure on the best way to fix this, the issue will always be related to performance. Current fix checks if a reload is needed by sending a flag in the `/documents/touch/<access_token>` request result when a new document access was created. opw-5156297 Forward-Port-Of: odoo/enterprise#104845 Forward-Port-Of: odoo/enterprise#99820
This update addresses a correction in the import of Swiss payroll tax rates for the 2026 tax year. Specifically, it adapts the process to handle single canton reporting requirements, ensuring accurate tax calculations for businesses operating in Switzerland. This change improves the reliability of payroll reporting.
Original PR description
Forward-Port-Of: odoo/enterprise#104991 Forward-Port-Of: odoo/enterprise#104333
This update fixes a potential issue in the Swiss payroll reporting process. Previously, a snapshot was always created, even if one already existed, leading to unnecessary data duplication. This change ensures snapshots are only created when needed, improving efficiency and accuracy of reporting.
Original PR description
Forward-Port-Of: odoo/enterprise#105258 Forward-Port-Of: odoo/enterprise#105135
This update fixes an issue where email layouts would break with multiple columns, specifically when column sizes didn't align properly. The change prioritizes using 'md' column variants for desktop email layouts, ensuring consistent and visually correct email formatting. This improves the overall presentation of marketing emails.
Original PR description
### [FIX] mail: properly handle col overflow in bootstrap row Problem: The grid conversion logic only finalized a row when iterating through the last column in the input list. If a row reached…
### [FIX] mail: properly handle col overflow in bootstrap row Problem: The grid conversion logic only finalized a row when iterating through the last column in the input list. If a row reached exactly 12 grid spans while more columns remained (e.g., a `col-12` in the middle), the logic did not start a new row. As a result, remaining columns overflowed the current row visually. Cause: In a single row, if a column had a size 12 and was followed by another column of any size, it would crash because the algorithm did not reset the index to the start of the next row. Steps to reproduce: - Add a Marketing block. - Reduce the size of the left card from the left side.<img width="719" height="580" alt="image" src="https://github.com/user-attachments/assets/1e62eaf7-6ab1-4120-b643-62427ce3ec3a" /> - Save. - Traceback. ### [FIX] mail: ensure -md variant of col and offsets are prioritized Prior to this commit, if an element had a mix of `col-x` and `col-md-y` classes, the regexes used in `convert_inline` would not guarantee that they would be used consistently. How to reproduce: - create a new mailing and add the "three columns" snippet - resize from the right the middle column (reduce the size and revert back to the original size) Issue: - when sending the email, the columns are not aligned horizontally in a desktop layout Solution: Prioritize usage of `-md` variants to compute the size of a column/offset, when available (these are the one used by the mass_mailing editor for desktop mode), and use any otherwise. opw-5439481 Co-authored-by: Damien Abeloos <abd@odoo.com> Co-authored-by: Thomas Josse <thjo@odoo.com> Co-authored-by: Walid Sahli <wasa@odoo.com> Forward-Port-Of: odoo/odoo#241851
This update resolves a problem where a test tour incorrectly failed when using the US tax report. The fix ensures the tour doesn't rely on outdated date assumptions and handles different localization configurations correctly, particularly when the 'Tax Report' localization isn't installed. This ensures consistent test results across various Odoo environments.
Original PR description
- The tour shouldn't run if a localization with 'Tax Report' for the country is not installed (i.e. l10n_us_account) - Dynamic Javascript dates calculation don't mix well with Python's freeze_time running in the "No future" 2026 preparation build, so I froze the time in the Python test but resorted to hardcode the Javascript dates. - No need to check the position of the column "Column 1". In debug mode for the tour, there will be the "Debug" column where the info about the computations are shown, so it won't be the last. We just need to see that it shows, after all. Runbot error [link](https://runbot.odoo.com/odoo/error/234624) runbot-234624 Forward-Port-Of: odoo/enterprise#101689
This update resolves a bug where loyalty trigger products wouldn't load correctly into the Point of Sale (PoS) when assigned to a different company. The fix ensures that all associated products are now properly loaded, preventing lost sales and improving the functionality of the loyalty program. This change was made after confirming legal compliance and adhering to Odoo's pull request guidelines.
Original PR description
Before this commit, if a loyalty trigger product was assigned to another company, non of the products would be loaded in the PoS. opw-5499108 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243993
This update resolves an issue where the 'Pending' button in manufacturing orders incorrectly stopped productivity records for all employees involved, instead of just the current one. The fix ensures that only the productivity record associated with the currently logged-in employee is stopped when the 'Pending' button is clicked, improving order management accuracy.
Original PR description
Steps to reproduce the bug:
- Create a storable product P1 with the following BoM:
- Create a new operation OP1
- Create a manufacturing order to produce one unit of P1
- Confirm the manufacturing order
- Log in as Mitchel (admin) and start OP1
- Log in as Marc (demo) and also start OP1
- Click on Pending
Problem:
Both “mrp.workcenter.productivity” records are stopped, instead of stopping only the one linked to
The `button_pending` method was stopping productivity records for all employees linked to the work order.
opw-5453752
Forward-Port-Of: odoo/enterprise#105238
Forward-Port-Of: odoo/enterprise#103553This update allows users to modify fields within the 'stock.quant' view through Odoo's Studio interface, even if those fields weren't initially configured with an XML ID. Previously, this wasn't possible, but now Studio-generated or customized fields are correctly recognized and permitted.
Original PR description
In versions prior to 18.3, the “stock.quant” view did not have an “xml_id”, which prevented it from being modified through Studio. However, starting from version 18.3 and specifically since this commit: https://github.com/odoo/enterprise/commit/f4a4d54d45392c2ba46a123d4951f8b4468c5cba it is now possible to modify views through Studio even if they don't have an xml_id. But in the 'stock.quant' view, we perform a check at creation time to ensure that the field is among the allowed fields. Fields coming from Studio or from a customized view should, however, be ignored by this check and allowed. opw-5107591 Forward-Port-Of: odoo/odoo#230126
This update fixes a problem where Stripe payments were failing due to incorrect currency decimal handling. The fix ensures accurate calculations and prevents payment errors when dealing with prices like $200.7647. This improves the reliability of our Stripe payment processing.
Original PR description
### Issue: The stripe payments are failing to due setting currency decimals. #### Steps to reproduce: 1- In USD currency form in developer mode, set the rounding factor to `0.001000`, so we have 3…
### Issue: The stripe payments are failing to due setting currency decimals. #### Steps to reproduce: 1- In USD currency form in developer mode, set the rounding factor to `0.001000`, so we have 3 decimal places. 2- From `Decimal Accuracy` set Price Unit to 4 digits. 3- Refresh the page. 4- Create a SO and add a line. Set the price to `200.7647`. 5- Refresh the page again and generate a payment link. 6- Pay through stripe. As you see payments fail. ### Cause: This is due to rounding the amount before sending to stripe: https://github.com/odoo/odoo/blob/824e0c42c62de7f570f106860e7dcbf1f7344c14/addons/payment_stripe/models/payment_transaction.py#L160-L165 We are rounding the amount to the minor currency unit. However, we make a compare between `tx_amount` and the amount paid through stripe: https://github.com/odoo/odoo/blob/824e0c42c62de7f570f106860e7dcbf1f7344c14/addons/payment/models/payment_transaction.py#L726-L732 Which are not equal. We should use minor current unit as `precision_digits` to fix this issue. opw-5496825 Forward-Port-Of: odoo/odoo#245593 Forward-Port-Of: odoo/odoo#245059
This update resolves an issue where the system incorrectly attempted to export self-billing invoices when using the oioubl_21 eInvoice format. The fix ensures the system uses the correct method for determining export eligibility, preventing UI access failures and allowing bills to be processed correctly.
Original PR description
While computing the self-billing export eligibility, the system called ```_can_export_selfbilling()``` on the EDI builder. However, this method is only implemented for the…
While computing the self-billing export eligibility, the system called ```_can_export_selfbilling()``` on the EDI builder. However, this method is only implemented for the ```account.edi.xml.ubl_bis3``` builder and is not available on other EDI formats such as ```oioubl_21```,
```oioubl_201```.
When a partner is configured to use the ```oioubl_21``` eInvoice format,
this resulted in an ```AttributeError``` during record reads, causing menu crawl and
UI access failures (e.g., Accounting → Vendors → Bills/Refunds).
```sql
Traceback (most recent call last):
File "/tmp/tmpznsful5y/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpznsful5y/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpznsful5y/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpznsful5y/migrations/base/tests/test_mock_crawl.py", line 539, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3858, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4089, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7078, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1311, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1493, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 442, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5297, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
return needle(*args)
File "/home/odoo/src/odoo/18.0/addons/account_peppol_selfbilling/models/account_move.py", line 13, in _compute_can_send_as_self_invoice
if move._is_exportable_as_self_invoice():
File "/home/odoo/src/odoo/18.0/addons/account_peppol_selfbilling/models/account_move.py", line 31, in _is_exportable_as_self_invoice
and edi_builder._can_export_selfbilling()
AttributeError: 'account.edi.xml.oioubl_21' object has no attribute '_can_export_selfbilling'
```
**Steps to reproduce**
1) Install l10n_dk_nemhandel module
2) Set the eInvoice format to oioubl_21 for the partner
3) Create Bill for that partner
3) Confirm the bill
OPW - 5863081
UPG - 3846482
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#245391This update removes a restriction that previously limited the use of journal accounts for reconciliation. Previously, certain accounts couldn't be used as default debit or credit accounts within journals. This change provides greater flexibility for users to manage their accounting data, simplifying reconciliation processes.
Original PR description
Previously, a constraint prevented accounts from being non-reconcilable if they were used as default debit/credit accounts involved in journals. This behavior is too restrictive. This commit removes the constraint. task-5254202 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245508 Forward-Port-Of: odoo/odoo#244398
This update resolves a customer complaint regarding test data containing the name "Deco Addict". The system has been updated to consistently use "Acme Corporation" in demo and test environments, preventing user confusion. This ensures a cleaner and more accurate demonstration of our software.
Original PR description
A company that happens to be named "Deco Addict" has complained some of our users thought they had business with them due to test and demo data containing that name. It will now be named Acme Corporation. task-5865502 Forward-Port-Of: odoo/odoo#245658 Forward-Port-Of: odoo/odoo#245205
This update resolves a customer complaint regarding test data. The name "Deco Addict" has been replaced with "Acme Corporation" in demo and test environments to ensure accurate representation and avoid confusion for users. This change improves the user experience and data integrity.
Original PR description
A company that happens to be named "Deco Addict" has complained some of our users thought they had business with them due to test and demo data containing that name. It will now be named Acme Corporation. task-5865502 Forward-Port-Of: odoo/enterprise#105446 Forward-Port-Of: odoo/enterprise#105151
1 change
Resolved issues and error corrections
This pull request resolves a customer complaint regarding demo data. The name "Deco Addict" was replaced with "Acme Corporation" to prevent users from mistakenly believing they had a business relationship with this company. This ensures a cleaner and more accurate demo experience.
Original PR description
A company that happens to be named "Deco Addict" has complained some of our users thought they had business with them due to test and demo data containing that name. It will now be named Acme Corporation. task-5865502 Forward-Port-Of: odoo/enterprise#105440 Forward-Port-Of: odoo/enterprise#105151
4 changes
Enhancements to existing features
This update removes unnecessary fields from CRM email templates, streamlining data collection and ensuring more information is captured in chatter. This enhancement avoids duplicate entries and allows for data gathering without requiring users to upgrade their systems. It’s a small improvement that boosts the efficiency of our CRM processes.
Original PR description
- Remove newly added fields that can be replaced by existing keys present in `iap_mail.enrich_company` template to ensure we get more data in chatter without upgrade and avoid duplicate entries IAP PR: https://github.com/odoo/iap-apps/pull/1390 Forward-Port-Of: odoo/odoo#245068
Resolved issues and error corrections
This update fixes issues related to error handling when processing HR tax documents, particularly those formatted as UBL invoices. It ensures compatibility with a related UBL tax extension module and provides clearer warnings for import issues instead of silently skipping documents.
Original PR description
- Improving error handling for various requests - Adjusting XML generation to not conflict with `account_edi_ubl_cii_tax_extension` if it is installed - Adding a separate test for HR:E category taxes - Replacing skipping import of not successfully fiscalized document with warnings displayed on the moves after import task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245028
This update resolves a customer complaint regarding test data using the name "Deco Addict". All instances of "Deco Addict" have been replaced with "Acme Corporation" across various Odoo modules to ensure accurate demo and test environments. This improves the user experience and avoids potential confusion.
Original PR description
A company that happens to be named "Deco Addict" has complained some of our users thought they had business with them due to test and demo data containing that name. It will now be named Acme Corporation. task-5865502 Forward-Port-Of: odoo/odoo#245623 Forward-Port-Of: odoo/odoo#245205
This pull request resolves a customer complaint regarding demo data. The name "Deco Addict" was replaced with "Acme Corporation" to avoid confusion among users. This ensures a cleaner and more accurate demo experience.
Original PR description
A company that happens to be named "Deco Addict" has complained some of our users thought they had business with them due to test and demo data containing that name. It will now be named Acme Corporation. task-5865502 Forward-Port-Of: odoo/enterprise#105421 Forward-Port-Of: odoo/enterprise#105151
2 changes
Resolved issues and error corrections
This pull request resolves a customer complaint regarding test data. The name "Deco Addict" was replaced with "Acme Corporation" in demo and test environments to avoid confusion and ensure a better user experience. This change improves data clarity and aligns with our standards for demo data.
Original PR description
A company that happens to be named "Deco Addict" has complained some of our users thought they had business with them due to test and demo data containing that name. It will now be named Acme Corporation. task-5865502 Forward-Port-Of: odoo/enterprise#105330 Forward-Port-Of: odoo/enterprise#105151
This update resolves a bug that occurred when generating reports for German-speaking customers. Specifically, a division-by-zero error was triggered when currency exchange differences (where the amount was zero) were present on move lines. The fix ensures these lines are now handled correctly, preventing report generation issues.
Original PR description
On move lines with zero `amount_currency` ( ex. currency exchange difference ), `_get_product_base_line_currency_rate` returns 0 currency rate which causes a division by zero error. Ignore the rate for lines with zero `amount_currency` opt-5358954 Forward-Port-Of: odoo/enterprise#105360
27 changes
New functionality added to Odoo
This update enhances the display of property values within list views in Odoo. It automatically creates new columns to show property data, making it easier for users to see relevant information. However, sorting and editing of these columns are currently not supported.
Original PR description
Adds columns in the list view for properties. Dynamically create 'fields' for list views that copy the characteristics of their 'properties' field. Allows for seamless display of property values in the list view. ## Notes These columns cannot be sorted (requires python ORM modifications) These columns cannot be edited (not easily achievable) task #2980121 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
This update expands payroll options for Indian businesses, allowing them to use various pay frequencies like daily, weekly, or monthly. Previously, the system was limited to monthly cycles, which is now removed to better accommodate diverse payroll practices and consultant requirements.
Original PR description
Version-master **Purpose**: Currently, many requirements are coming from the consultant side. Several small companies manage payroll on different cycles such as Daily, Weekly, Bi-Weekly, Half-Monthly, Monthly, Quarterly, and Half-Yearly. Therefore, the system should support flexible payslip frequencies to accommodate these varied payroll practices. ### What this PR does - Reintroduces the Wage Type configuration on the employee payroll form. - Allows defining the wage frequency (daily, weekly, bi-weekly, half-monthly, monthly, quarterly, half-yearly, etc.). - Reflects the selected schedule_pay option as a read-only field in salary computation fields, ensuring clarity and consistency in payroll calculations. - Improves usability for consultants and payroll administrators managing multiple payroll cycles. task-5438112
This update expands the availability of the 'Sign' action to several standard company folders, including Employees, Finance, Legal, and Sign. This ensures that users can easily sign documents within these frequently used areas, streamlining document management processes. The change was made to improve consistency and usability across key business areas.
Original PR description
Extend the availability of the Sign embedded action to a set of precreated document folders (Employees, Projects, Finance, Legal, Sign, Admin) and their precreated subfolders. Previously, the Sign action was available only on Inbox and Admin. This update ensures consistent behavior across all relevant predefined folders without affecting user-created folders. ref: [Upgrade PR](https://github.com/odoo/upgrade/pull/9058) task: 5379871
This update allows users to easily share filtered views by copying a URL containing the search criteria. Previously, shared links didn't accurately reflect the user's filters. Now, a new command creates a URL with the current filters, ensuring colleagues see the same search results when they paste the link.
Original PR description
Description of the issue/feature this PR addresses: When teams collaborate, it is often useful to share a page by keeping the searches, (custom) filters and groups. Currently, when the user copies then pastes then URL somewhere, the colleague who clicks on it could not see the same things as the user who shared the link. This can be misleading. Current behavior before PR: The search model does not parse the url query string for search model parameters. Desired behavior after PR is merged: - Command to copy the current filters with the url into the clipboard (from the command pallette) - - > ONLY for stored action, we prevent sharing dynamic actions on purpose. - Activating individual filters / GroupBys from the url params if present. task#5391304 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update changes how binary data is stored in the Odoo database. Previously, data was encoded in base64, which used more space. Now, binary data is stored directly as bytes, optimizing storage and preparing for future cache changes. This improves database efficiency.
Original PR description
Since we are going to move to a raw bytes representation in the cache, let's store binary fields that are not attachments as raw bytes in the database instead of storing them in base64-encoded raw bytes (which just use more space). task-4251301 https://github.com/odoo/upgrade/pull/8995 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures accurate accounting for branches with different GST numbers. When a branch is created and its GST number doesn't match the parent company's, separate accounting journals are automatically generated for sales and purchases, aligning with GST regulations and maintaining independent financial records.
Original PR description
Currently, when a branch is created, no separate accounting journals are created by default. As per `Section 25(4) of the CGST Act`, a person having more than one GST registration—whether in the same State/UT or in different States/UTs—is treated as a distinct person under GST law. With this change, the GST number of the branch is compared with that of the parent company at the time of branch creation. If the GST numbers differ, separate accounting journals for `sale` and `purchase` are created for the branch to ensure that independent books of accounts are maintained. task-5417349 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update simplifies the naming of a key view within the Sale CRM module. Specifically, the external ID '123' has been removed from the inherited view. This change improves the organization and clarity of the Odoo codebase, without impacting any user-facing functionality.
Original PR description
Before this commit, the inherited view is not named in a good way. After this commit, 123 will be removed from the external id of the inherited view. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances email confirmation messages sent after resource bookings. Now, multiple confirmation emails are sent for bookings involving multiple resources, and the final email includes a note linking it to the other related emails. This improves clarity and reduces confusion for users.
Original PR description
A change in the data structure to represent resource bookings requires we update the mail template that uses them. As bookings for multiple resources will now send multiple confirmations we add a note in the last email to specify the other emails are linked. task-338900
This update enhances the event track experience by adding the ability to collapse tracks in the list view and significantly improves the agenda view, particularly for multi-day events. Previously, users struggled to manage and view event schedules effectively. This change provides a cleaner and more organized event experience.
Original PR description
Prior to this PR, usability in the `tracks view` and in the `agenda view` was not good. To collapse the tracks, you had to click on the arrow (and only there) There was no collapsing possible in the `agenda view` task-3599197 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves activity views by ensuring users only see activities related to companies they have access to. Previously, users could view activities for companies they weren't connected to, leading to potential confusion. Adding a company ID to activities now correctly associates them with the relevant company record.
Original PR description
Currently, the views "All Activities" and "My Activities" will display every activity belonging to a user, even if they belong to record tied to companies on which the user has no access. This commit adds a company_id fields to activities, which will bind them to the company which own their record, if any. task-4800833
This update automatically installs the Microsoft Outlook module, aligning it with the existing Google Gmail integration. It also addresses a security issue by restricting users from utilizing other users' mail servers, ensuring emails are sent from authorized accounts and preventing unauthorized access.
Resolved issues and error corrections
This update resolves a problem where image transformations were incorrectly applying translations, leading to misaligned images. Removing the translate feature during image transformation ensures accurate resizing and rotation, improving image display quality. The change also updates icons to reflect the removal of translation functionality.
Original PR description
*: `html_builder` In website, the translate feature while transforming an image can occur issues or misleading. This PR aims to remove translate feature from image transformation. task-5190342 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the portal user experience by automatically scrolling to the specific message when a linked message is opened. Previously, clicking a message link only opened the record, making it harder to quickly view the content. This change improves usability and efficiency for portal users.
Original PR description
*= website_slides, website_sale, test_mail_full **Current behavior before PR:** Opening a copied message link does not automatically scroll to the message for portal users, it only opens the record. **Desired behavior after PR is merged:** Opening the copied link now automatically scrolls to the specific message within the record instead of just opening the record. task-id:[4518058](https://www.odoo.com/odoo/project/1519/tasks/4518058) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue that was causing tests to fail due to dynamic date usage. The test now utilizes a freeze-time mechanism, ensuring consistent and reliable test results. This change improves the stability and reliability of the employee version timeline feature.
Original PR description
As runbot faketimes test fail because the usage of dynamic dates now the test uses freeze_time Task#5717031 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244540
This update adds a 'Reload Data' button to error dialogs in the Point of Sale system, providing users with a simple way to resolve common issues. This reduces downtime and frustration by allowing quick data recovery, especially for Restaurant orders which now attempt to sync before reloading.
Original PR description
Purpose: ------------ - On Error dialogs, users only had "Ok" or could close the dialog, with no guidance on what to do next. - Many blocking issues are resolved simply by reloading POS data. Before this commit: ----------- - Error dialogs only had an "Ok" button. After this commit: ------------------ - Added a "Reload Data" button for quick recovery of common blocking issues. - Added a warning message in the reload data popup - For POS Restaurant, orders will attempt to sync before reloading data, reducing the risk of data loss. Task-5353590 Forward-Port-Of: odoo/odoo#244321 Forward-Port-Of: odoo/odoo#238112
This update fixes an issue where clicking links within the Odoo chat window on mobile devices caused the chat window to remain open and block the new page from appearing. The change now automatically folds the chat window after a link click, ensuring users can easily view the linked page. This enhances usability and prevents frustration for mobile users.
Original PR description
Clicking on an odoo link in the chat window will take the user to the related page in odoo. However, in mobile view, the chat window remains unfolded and covers the entire page, so the user can't see the newly opened page below the chat window unless they fold the chat window. This change fixes this by folding the chat window in mobile view when clicking an odoo link inside the chat window. task-4762503 Forward-Port-Of: odoo/odoo#244905 Forward-Port-Of: odoo/odoo#208440
This update fixes an issue where employee names were being incorrectly formatted in payroll reports (specifically, last name before first name). The code has been corrected to ensure names are consistently displayed as 'FirstName LastName,' aligning with Swiss regulations and improving report accuracy. Test data has also been updated to reflect this change.
Original PR description
* Fix _compute_l10n_ch_legal_name method to correctly assign first_name and last_name from employee name (was previously reversed) * Update all SwissDEC test data to use correct "FirstName LastName" format instead of "LastName FirstName" to match the corrected computation logic task-5102851 Forward-Port-Of: odoo/enterprise#105044 Forward-Port-Of: odoo/enterprise#95252
This update strengthens Odoo's database safety by ensuring that queries against PostgreSQL always use the correct schema. This prevents potential errors and data corruption that could occur when multiple schemas are used simultaneously, addressing a previously reported issue. It's a proactive measure to maintain data integrity and stability.
Original PR description
Safety measure to prevent hidden bugs and data corruption which can happen when multiple schema are used in PostgreSQL. Description of the issue/feature this PR addresses: Related to: - PR #243833 - OPW [opw-5495025](https://www.odoo.com/my/tasks/5495025) - issue reported earlier: #97891 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243967
This update resolves an issue where the map component wasn't displaying correctly within the Odoo Studio. The fix addressed a missing size constraint, allowing the map to render. However, the map remains non-interactive, indicating a separate problem that needs attention.
Original PR description
Before this commit, the map did not render in studio. This was because the container did not have a size. After this commit, the map renders correctly, but it is still not clickable or interactable. task-5432169 Forward-Port-Of: odoo/enterprise#104968 Forward-Port-Of: odoo/enterprise#104114
This update corrects a bug in the Master Production Schedule (MPS) that caused excessive component reordering for kit products. Specifically, a calculation error resulted in the system ordering components in exponential amounts. This fix ensures accurate replenishment and prevents overstocking of components when ordering kits through the MPS.
Original PR description
***Behavior:*** In a setting with a second warehouse that is supplied by the first one. Creating a product that uses that ressuply route, and then adding it to the bom of a kit product will make it…
***Behavior:*** In a setting with a second warehouse that is supplied by the first one. Creating a product that uses that ressuply route, and then adding it to the bom of a kit product will make it so that when ordering the kit product to the second warehouse from the MPS, the system will create an order for an exponential amount of components. When calling action_replenish, kit products for which the components don't have an MPS entry will have their product_ratio computed to know how many components to reorder. However the current formula is wrong or outdated and ends up returning the squared amount. ***Steps to reproduce:*** - Create a second warehouse. - Check Resuply From 'First Warehouse' (this will unarchive a route) - Create a product that uses that route for reordering. - Create a second product - Create a kit for that product BOM composed of the first product make sure the amount of component is more than 1 - In the Master Production Schedule: Add the kit product and make sure it is produced in the second warehouse with the unarchived route. - Add any amount to reorder in 'Replenishment' then click the Order button. - If you go to deliveries and look for your component, you'll see the amount of component per kit squared multiplied by the reordered kit amount. opw-5351460 Forward-Port-Of: odoo/enterprise#101462
This update fixes a display issue in the spreadsheet filter side panel. Field matching is now only shown after a model and field have been selected, aligning with other filter types. This ensures a more intuitive and consistent user experience for configuring spreadsheet filters.
Original PR description
## Description Before this commit: - In the selection global filter side panel, field matching was shown immediately, even when the model and field were not selected. - Without a model, field matching cannot be configured correctly, so showing it early had no meaning. - This behavior was inconsistent with relational global filters. After this commit: - Field matching is displayed only after the user selects both model and field. - Once configured, users can set up field matching as expected, similar to the relational global filter side panel. Task: [5477251](https://www.odoo.com/odoo/project/2328/tasks/5477251) Forward-Port-Of: odoo/enterprise#104545
This update resolves an issue where tables inserted into the To-Do editor appeared after the existing text instead of before it. The fix streamlined the table insertion process, ensuring tables are now correctly placed at the beginning of the block where the user intended. This improves the overall user experience and consistency within the editor.
Original PR description
### Steps to Reproduce : - Open To-Do and type some text. - Place the cursor at the start of the block. - Insert a table. (e.g.: /table) - The table appears after the text instead of before it. ### Purpose of this PR: - Table insertion logic was previously duplicated inside TablePlugin, where it tried to manually split text and inline nodes before inserting the table. However, this responsibility is now correctly handled by `DomPlugin.insert()`, which already: - deletes the current selection if needed. - splits text and inline nodes safely. - handles block boundaries and unsplittable elements. - normalizes the DOM after insertion. - places the cursor at a valid position. task-5480759 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244689 Forward-Port-Of: odoo/odoo#243242
This update corrects a test failure related to how dates and times are displayed in Chrome. A recent change introduced a regular space instead of a non-breaking space, causing compatibility issues. This fix ensures consistent date and time formatting across different Chrome versions.
Original PR description
Apparently somewhere in the datetime patterns the space between time and A/P mark has been updated from a narrow non-breaking space to a regular space. Make the code cross-version compatible. Forward-Port-Of: odoo/odoo#244961
Features or functions removed from Odoo
This update streamlines the Odoo Enterprise codebase by removing a set of tests specifically for rental wishlists and comparisons. With the rental functionality now integrated into the main website sale module, these separate tests are no longer needed, simplifying the development process and reducing maintenance overhead.
Code cleanup and technical improvements
This update streamlines the handling of manual measurements related to Adam scales by moving the `manual_measurement` field to a dedicated module, `pos_iot_adam_scale`. This improves organization and reduces complexity within the core IoT system.
Original PR description
As the `manual_measurement` field is only specific to adam scales, we moved it to the `pos_iot_adam_scale` module. see odoo/upgrade#9210
This update consolidates the wishlist and comparison features into the base website sale module, simplifying the codebase and improving maintainability. This change streamlines the eCommerce experience by removing redundant modules and optimizing data processing for product pages.
Original PR description
`website_sale_wishlist` & `website_sale_comparison` were holding the 'Wishlist' & 'Comparison' eCommerce features. In the past, they were optional and installed through the eCommerce settings, since 19.0 they are auto-installed (features are enabled/disabled through the website editor). For code simplification and maintainability, those two features are considered part of a standard eCommerce flow and are now moved into the base `website_sale` module. This allows to remove multiple bridge modules too (and centralize some logic). task-5089613
This update simplifies the process of creating Spanish BOE reports for models 111, 115, and 303. By removing unnecessary encoding and streamlining the generation logic, we've made the process more efficient and easier to maintain, addressing previous issues with complexity and error-proneness.
Original PR description
In Spain, the BOE is a text file generated for each modelo (aka report). It is a .txt file in which the index of the character is the sole indicator of its content. The generation of those text files…
In Spain, the BOE is a text file generated for each modelo (aka report). It is a .txt file in which the index of the character is the sole indicator of its content. The generation of those text files is over-engineered, contains way too much verbose, is error-prone and not change friendly, although the rules tend to change quite often. First, added tests to ensure that the BOE are unaffected by the refactor. Then, simplified the BOE generation for modelos 111, 115 and 303: * Removed the byte-encoding: the only purpose of this was to allow for an easy removal of accentuated characters. This however implied a byte-conversion in every single function. Normalised instead using the character's ascii position. * Added helper functions for common operations (adding X blank spaces, formatting currency...) * United all time-bound legal changes in the beginning of the boe's computation, so legal requirements are clear and isolated, * Streamed the BOE generation in a single simple array. * (+ other minor case-by-case improvement) This is a proof of concept which is why other modelos are yet unaffected. They should be ASAP though ; when it is done, the more complicated functions should be removed. task-5213590
2 changes
Resolved issues and error corrections
This update resolves a problem with a test tour for tax reports. The tour previously failed when a specific US localization wasn't installed, due to mismatched date calculations. The fix ensures the tour runs correctly regardless of the installed localization, improving test reliability.
Original PR description
- The tour shouldn't run if a localization with 'Tax Report' for the country is not installed (i.e. l10n_us_account) - Dynamic Javascript dates calculation don't mix well with Python's freeze_time running in the "No future" 2026 preparation build, so I froze the time in the Python test but resorted to hardcode the Javascript dates. - No need to check the position of the column "Column 1". In debug mode for the tour, there will be the "Debug" column where the info about the computations are shown, so it won't be the last. We just need to see that it shows, after all. Runbot error [link](https://runbot.odoo.com/odoo/error/234624) runbot-234624 Forward-Port-Of: odoo/enterprise#101689
This pull request resolves a customer complaint regarding demo data. The name "Deco Addict" was replaced with "Acme Corporation" to avoid confusion with actual business transactions. This ensures a cleaner and more accurate demo experience for our users.
Original PR description
A company that happens to be named "Deco Addict" has complained some of our users thought they had business with them due to test and demo data containing that name. It will now be named Acme Corporation. task-5865502 Forward-Port-Of: odoo/enterprise#105445 Forward-Port-Of: odoo/enterprise#105151
5 changes
Resolved issues and error corrections
This update resolves a bug that occurred when generating reports for German-speaking customers. Specifically, a division-by-zero error was triggered when currency exchange differences (zero amount_currency) were present on move lines. The fix ensures these lines are now handled correctly, preventing report generation issues.
Original PR description
On move lines with zero `amount_currency` ( ex. currency exchange difference ), `_get_product_base_line_currency_rate` returns 0 currency rate which causes a division by zero error. Ignore the rate for lines with zero `amount_currency` opt-5358954
This update fixes an issue where the tax code (9) was missing from Datev exports for expense journal entries using 19%I tax. The problem occurred due to how payment amounts were aggregated during the export process. This ensures accurate tax reporting to Datev, aligning with accounting regulations.
Original PR description
Currently, when using 19%I tax in vendor bills, the tax code (9) is shown correctly in the BU-Schlüssel section of the datev export. This however is not the case for expense journal entries. Steps to reproduce: - With DE Company setup - Create an Expense as follows: - Included taxes: 19% I - Paid by: Company - Create report > Submit to Manager > Approve > Post Journal entries - Open General Ledger and export Datev Data Issue: Tax code will be missing from the exported entry. This occurs because, when processing payment move lines, amounts and accounts are aggregated, losing track of the source tax. opw-5388791 Forward-Port-Of: odoo/enterprise#102548
This update simplifies CRM mail templates to capture more information in chatter, particularly without requiring users to upgrade. By removing redundant fields and leveraging existing data sources, we ensure consistent and complete data collection for our CRM processes. This change was driven by a need to optimize data capture and avoid duplicate entries.
Original PR description
- Remove newly added fields that can be replaced by existing keys present in `iap_mail.enrich_company` template to ensure we get more data in chatter without upgrade and avoid duplicate entries IAP PR: https://github.com/odoo/iap-apps/pull/1390 Forward-Port-Of: odoo/odoo#245068
This update addresses inconsistencies in invoice totals, particularly for Peppol transactions, caused by rounding of product prices. The system now displays 'Product Price' with a minimum precision, ensuring totals align more closely with original documents. This improves data accuracy and compliance.
Original PR description
Imported invoices can show different totals than what the original document show. This especially an issue for Peppol. Because `price_unit` is rounded, by computing the total of a line with `quantity * price_unit`, it may not be possible to obtain the same total as the one from the original document. To face this issue, the float fields related to "Product Price" don't have a decimal precision set anymore. To keep the UI clean, the precision set on "Product Price" is now interpreted as a "minimal precision". So if it set to 3, we'll see at least 3 digits. If there's more, all the digits are shown. As so: `4.0` -> `'4.000'` `4.23` -> `'4.230'` `4.235` -> `'4.235'` `4.2358` -> `'4.23458'` task-4895014
This update adjusts how product prices are stored within Odoo, ensuring greater data accuracy and consistency. The change involves setting a minimum precision for product prices, which helps prevent rounding errors and improves financial reporting. This update is a technical fix related to a previous issue.
Original PR description
Fix tests, related to https://github.com/odoo/odoo/pull/243987 task-4895014