Daily updates from Odoo
Thursday, April 30, 2026
37 changes · saas-19.1
New functionality added to Odoo
This update introduces a new 'tare' mode specifically for Toledo scales within the Odoo system. This allows users to accurately measure items by resetting the scale to zero before each measurement, improving data precision for inventory tracking. This enhancement supports a key feature for businesses utilizing Toledo scales.
Original PR description
This PR adds the tare mode for Toledo scales. Related PR: https://github.com/odoo/odoo/pull/253328
Enhancements to existing features
This update adapts the XLSX export reports to align with new Indonesian tax regulations (Act 2025). Previously, reports relied on specific tax sections, but now they utilize report line names and tax tags for accurate reporting, ensuring compliance with the latest requirements.
Original PR description
In this commit, the XLSX export and report warning are adapted to support the newly introduced TDS/TCS reports as per Act 2025. Previously, the XLSX reports depended on TDS/TCS sections. However, with Act 2025, certain taxes no longer have associated sections. This dependency has been removed, and report generation now relies on report line names and tax tags instead. task-6124431 Forward-Port-Of: odoo/enterprise#113916
Resolved issues and error corrections
This update fixes a performance issue where updating a product's lot or serial number in a picking could trigger slow requests due to fetching all stock quantities. The change ensures that the system respects the specified limit when retrieving quantities, resulting in significantly faster update times. This improves the overall responsiveness of the barcode picking process.
Original PR description
## Problem: During an `onchange` call, if a field is defined in the `fields_spec` with a `limit` attribute, the `fetch` method doesn't respect it, and will fetch all records satisfying the domain. In certain circumstances, this leads to slow requests. ## Solution: Enforce the `limit` when fetching if it is present. ## Steps to reproduce: - Have a product with many quant records 1. Open a picking for this product in Barcode 2. Change the lot/serial The frontend will send an `onchange` request that includes `product_stock_quant_ids` in the `fields_spec` (with default `limit` 40). Odoo will fetch all quants for this product regardless of the limit, and the request will take a while to resolve. ## Benchmark: <table> <thead> <tr> <th># of quants</th> <th>Before</th> <th>After</th> </tr> </thead> <tbody> <tr> <td>17193</td> <td>~9s</td> <td>~400ms</td> </tr> </tbody> </table> opw-6041705 Forward-Port-Of: odoo/odoo#259983
This update strengthens the security of Xendit payments by requiring a valid access token linked to the specific transaction. Previously, payments could be processed without this verification, creating a potential risk. Now, payments are restricted to the correct transaction, improving security and preventing unauthorized payments.
Original PR description
**Description of the issue/feature this PR addresses:** The `/payment/xendit/payment` endpoint did not enforce validation of an access token tied to the transaction when processing direct payment requests. **Current behavior before PR:** The endpoint accepted public requests using only the transaction reference, allowing payment execution without verifying that the request was linked to the intended transaction. **Desired behavior after PR is merged:** The endpoint now requires a valid access_token associated with the transaction (reference) before processing. This ensures that payment execution is restricted to the correct transaction. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261912 Forward-Port-Of: odoo/odoo#260258
This update fixes an issue where the IRN (Invoice Reference Number) generated during E-Invoicing EDI submission wasn't correctly saved or displayed on the invoice itself. The fix ensures the IRN number is now present in both the generated PDF invoice and the invoice form view, streamlining invoice tracking for users.
Original PR description
**Steps to reproduce:** * Install module *Indian - GSTR with E-invoice (l10n_in_edi_gstr)*. * Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.). * Save the…
**Steps to reproduce:** * Install module *Indian - GSTR with E-invoice (l10n_in_edi_gstr)*. * Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.). * Save the settings. * Create a *customer invoice*. * Post the invoice. * Send the invoice through *E-Invoicing (EDI)*. * Open the generated *Invoice PDF* and the *form view*. **Observed behavior:** * The *IRN number* is correctly present in the *Invoice PDF*. * However, it is *not saved/displayed* in the invoice form view. **Cause:** * The invoice flow did not store the *IRN number* on the invoice after receiving the EDI response, even though the value was available. **Fix:** * Inherit *_l10n_in_edi_send_invoice*. * Add a condition after the invoice is sent and the JSON response is received. * When the *IRN number* is present in the response, set it on the *l10n_in_irn_number* field of the invoice (in lower case). opw-6097923 Forward-Port-Of: odoo/enterprise#115522 Forward-Port-Of: odoo/enterprise#114350
This update resolves an error that occurred when exporting VSME reports if the base year was invalid. The fix ensures that only valid 4-digit years are used, preventing a data processing error and ensuring accurate report generation. This improves the reliability of VSME reporting.
Original PR description
Currently, an error occurs when exporting VSME reports if the base year is not a valid 4-digit year. **Steps to Reproduce:** 1. Install the `esg_csrd` module with demo data. 2. Create new "**VSME Reports**" with `Base Year = 1`. 3. Now, click on "**Print**". **Error:** `ValueError - Invalid isoformat string: '1-01-01'` **Cause:** The base year is directly used to build a date in [1], resulting in `datetime.date(1, 1, 1)`. In [2], this is formatted to **"1-01-01"** and used in a domain search, which raises a ValueError due to an invalid ISO date format. **Fix:** - Adds a **constraint on base year** to ensure only valid years (1000–9999) are allowed for new VSME Report records. - Adds a **helper validation method** to verify base year before performing computations on existing records. sentry-7419431039 Forward-Port-Of: odoo/enterprise#114453
This update corrects a technical issue preventing users from successfully booking appointments with flexible hour slots. The problem stemmed from an incorrect calculation of appointment durations, leading to a 404 error. The fix ensures accurate slot durations are used when building booking URLs, allowing for seamless appointment scheduling.
Original PR description
Steps to reproduce: 1. Install `appointment` 2. Create an appointment type with the followings 3. Schedule type flexible and a slot of 20 min. 4. Share this appointment and try to book appointment…
Steps to reproduce: 1. Install `appointment` 2. Create an appointment type with the followings 3. Schedule type flexible and a slot of 20 min. 4. Share this appointment and try to book appointment for 20 min. Issue: - 404 Error occurs after selectiong the slot Cause: - In 19.0, commit https://github.com/odoo/enterprise/commit/9bae0e13e7bf5e0db25a60fc2683bc51eccb4447 started using slot.duration when building the booking URL for flexible slots. However, slot.duration is rounded to 2 decimals, so a 20-minute slot is serialized as 0.33 instead of its exact value. During validation, the end datetime is recomputed from this rounded duration, which no longer matches the original slot boundaries. This mismatch causes the slot to be considered invalid and the controller raises NotFound. Solution: - Compute the slot duration directly from slot_start_dt_tz and slot_end_dt_tz when building the URL, preserving the full precision. opw-5924312 Forward-Port-Of: odoo/enterprise#108870
This update resolves an issue where power buttons were incorrectly displayed and overlapping other menu items within the HTML editor, particularly on smaller screens. The fix adjusts the editor's width detection to ensure buttons are hidden when they cause overlap, improving the user experience and visual consistency.
Original PR description
Problem: Power buttons are shown regardless of the editor field's actual rendered width, causing them to overlap other menus when the field is small. Solution: Instead of relying solely on the global…
Problem: Power buttons are shown regardless of the editor field's actual rendered width, causing them to overlap other menus when the field is small. Solution: Instead of relying solely on the global `ui.isSmall` (mobile detection), check the editor field's own width and hide power buttons whenever it falls below the overlap threshold. Before: <img width="576" height="301" alt="image" src="https://github.com/user-attachments/assets/dcebed55-5c80-4fe5-8d33-c320549cf347" /> After: <img width="542" height="336" alt="image" src="https://github.com/user-attachments/assets/34a233bb-9958-43ac-adb9-04702a2e403d" /> Steps to reproduce: - Change languange (French to have a long placeholder). - Settings > Customer Invoices > Default Terms & Conditions. - Check "Add a Note". - Resize the screen to smaller size. - Observe the power buttons overlap with the translate button. task-6117734 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261881 Forward-Port-Of: odoo/odoo#259094
This update corrects a reporting issue where the '18% IGST (IMP-Service)' tax wasn't accurately reflected in the GSTR-3B report. The fix adjusts how tax distributions are handled, ensuring the correct service tax amount is imported. This ensures accurate tax reporting for Indian businesses.
Original PR description
**Steps to reproduce:** - Install l10n_in_reports - Switch to an Indian company (e.g. IN Company) - Create a bill with a Service product and "18% IGST (IMP-Service)" tax - Confirm the bill - Go to "Accounting / Reporting / India / GSTR-3B" **Issue:** In "4. (A) (2) Import of services" section of the report, the bill that has been created is not taken into account. **Cause:** The "18% IGST (IMP-Service)" tax has a distribution of: * 100% of the tax in "100570" account with "IGST" tax tag * -100% of the tax in same account with "IGST" tax tag Therefore, both distribution lines with the tax tag cancel themselves. opw-6116356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260631
This update resolves an issue where multi-company invoices were experiencing errors due to incorrect tax calculations. The change ensures that tax data is handled securely, preventing access errors when products from different companies are involved. This improves invoice processing reliability for businesses using Odoo's multi-company feature.
Original PR description
Description of the issue this commit addresses: In multi-company setups, invoice line tax recomputation could read product or account taxes in user context and trigger an AccessError on account.tax when products carry taxes from another company. Desired behavior after this commit is merged: This patch hardens account.move.line tax recomputation paths by reading tax M2M values in sudo and returning filtered results in normal env, so compute logic no longer crashes on cross-company tax records. Ticket [link](https://www.odoo.com/odoo/project.task/6036638) opw-6036638 Forward-Port-Of: odoo/odoo#260948
This update corrects a formatting issue in the e-waybill document date field. Previously, both date and time were displayed, which is not the required format. This change ensures consistent and accurate date reporting for e-waybills.
Original PR description
The `document_date` field in e-waybill form view previously included both date and time, which is not as per the expected format. This fix ensures that only the date is shown, hiding the time component. Forward-Port-Of: odoo/odoo#261253 Forward-Port-Of: odoo/odoo#259656
This update corrects a bug where the system was incorrectly searching for customers using phone numbers instead of email addresses. The change ensures customers can now be accurately found and retrieved using their email, improving customer data access. This resolves a previous issue preventing correct customer searches.
Original PR description
The email-based lookup was mistakenly checking the phone field (`phone = email`) instead of the email field. Because of this, customers could not be correctly found using their email address. This change fixes the domain to properly match on the email field. Forward-Port-Of: odoo/odoo#260567
This update resolves an issue where backorders created from returns weren't properly associated with the original return. The fix ensures the `return_id` is correctly set during the backorder creation process, allowing for accurate tracking and reporting of returned items. This improves the reliability of our inventory management system.
Original PR description
### Steps to reproduce: - Create, confirm and validate a delivery for 2 units of a product A - Click Return > Return All - Validate the return for 1 unit and backorder #### > The backorder does not belong to the return list of the delivery ### Cause of the issue: Backorder pickings are created by copying the picking to backorder: https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L1580-L1593 https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L1571-L1578 However, the `return_id` is a `copy=False` field that is not manully set during this copy process: https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L558 opw-6111544 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261831 Forward-Port-Of: odoo/odoo#259804
This update resolves an issue preventing the MPESA payment method from correctly processing transactions initiated by Safaricom. Specifically, it disables CSRF checks on callback endpoints and ensures URLs use HTTPS, addressing a common error related to invalid URLs. Additionally, the code now incorporates the till number for transactions, streamlining the process.
Original PR description
1. The `MPESA` payment method needs a callback url where it does a `POST` request with the transaction details. Since the call comes from safaricom, CSRF will block those requests. This commit will…
1. The `MPESA` payment method needs a callback url where it does a `POST` request with the transaction details. Since the call comes from safaricom, CSRF will block those requests. This commit will disable CSRF checks on the callback endpoints which are expected to be called from an external service 2. Sometimes the `web.base.url` parameter is automatically set to http. But safaricom expects https for all the urls. So we need to ensure that the urls we send on `lipa_na_mpesa_register_urls` use https, otherwise the registration fails with an `invalid url` error. Additionally, I added the error message in case of error 4. In addition to the business short code we also need a till number for transactions. Since this is stable, I've added the till number as an extension of the business shortcode field and then parse it before usage. On master there is a new PR which will properly separate the fields Task-[6045833](https://www.odoo.com/odoo/project/1737/tasks/6045833) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254993
This update resolves a technical issue where the payroll amount calculation wasn't consistently triggered when a default value was set for a specific field. The change ensures the calculation is always performed correctly, regardless of the initial default value selected, improving payroll accuracy.
Original PR description
The compute is not triggered when a default value is assigned to a field. So all property inputs default to 'fix' for amount_select. This removes the default parameter from the field and adds the default value to the compute method. task-6126332
This update fixes an issue where the Datev CSV export incorrectly calculated tax amounts for vendor bills with multiple tax repartition lines. The fix ensures accurate tax reporting by correctly summing the tax amounts when multiple lines are associated with a single tax, improving the reliability of financial data exports.
Original PR description
With l10n_de_reports: - Configure a foreign currency with an exchange rate. - Configure a tax with multiple repartition lines. - Create a vendor bill in this foreign currency with this tax. - In the general ledger export the datev csv. In the datev csv the rate is wrong. In the method _l10n_de_datev_get_csv, we build a tax_amount dict. However when one tax has multiple lines, the amount is replaced and not added. opw-6010097 Forward-Port-Of: odoo/enterprise#115535 Forward-Port-Of: odoo/enterprise#110453
This update resolves an issue where incorrect Nemhandel identifiers were generated when Danish company VAT numbers with the 'DK' prefix were entered. The change removes the 'DK' prefix from CVR numbers, ensuring accurate identifier generation and a better experience for Danish businesses using Odoo.
Original PR description
Before this PR: - When a user enters a full VAT number with the 'DK' prefix in the company registry, the Nemhandel identifier becomes incorrect and results in a cryptic error being returned to the client. After this PR: - The prefix is removed if the CVR contains the 'DK' country code, to ensure the correctness of the Nemhandel identifier. task-5449059 Forward-Port-Of: odoo/odoo#261856 Forward-Port-Of: odoo/odoo#261719
This update fixes an issue where test tags containing brackets or backslashes weren't parsed correctly, preventing certain tests from running. The changes ensure that complex tag structures, including nested brackets and escaped characters, are now handled properly, improving test reliability. This resolves a technical detail that ensures consistent test execution.
Original PR description
When using test tags for js tests, some tests are not parsed correctly when containing brackets `[ ]` This is because the tag selector use them to set parameters bounds as in…
When using test tags for js tests, some tests are not parsed correctly when containing brackets `[ ]` This is because the tag selector use them to set parameters bounds as in `.test_method[test_param]` The previous implementation using a regex could generate invalid test tags when the params contains comma, and brackets This commits fixes this two ways: Nested brackets will work, meaning that something like `.test_method[test, witch brackets[]]` will be correctly parsed as a tag `.test_method` with a parameter `test, witch brackets[]`since the brakets are balanced. Before, it was parsed as twho tags, `.test_method[test` and ` witch brackets[]]` the second one being considered invalid and spamming logs with errors Brackets and backslashes can be escaped with a backslash, meaning that something like `.test_method[test, with brackets], and backslash\]` can be escaped as `.test_method[test, with brackets\], and backslash\\]` Note that the parser will make it's best effort to parse non escaped strings, so a \ not followed by and escaped character will remain there in order to make potential copy paste easier. For the previous example `.test_method[test, with brackets\], and backslash\` will work the same way. So in practice, we only really need to escape \ when followed by another backslash or a bracket, and we need to escape brackets when they are not balanced. Comma in hoot tests are also a problem since they are used to separate parameters, this can easily be tested by only splitting on `,@` since all hoot test should start with a @ and parameters of test_unit_* tests should be a list of hoot tests. A followup pr will introduce the params to the canonical tag, and escape it as needed Forward-Port-Of: odoo/odoo#261896 Forward-Port-Of: odoo/odoo#261516
This update corrects a previous issue where all employees could see each other's overtime hours. The root cause was a setting in the system's calculations that granted excessive access. The fix removes this setting and adds new tests to ensure this problem doesn't reoccur.
Original PR description
- Step to reproduce: everyone can see everyones overtimes. - Cause: total_overtime compute method is using `compute_sudo=True`. - Solution: removing compute_sudo and adding tests Task: 6125021 Forward-Port-Of: odoo/odoo#261496
This update resolves an issue where certain expense accounts were incorrectly included in default reporting filters. Specifically, accounts related to exchange differences and early payment discounts are now properly categorized as 'Other Expenses'. This ensures more accurate financial reporting and analysis.
Original PR description
[FIX] account: Default account filter include Other Expense In "Defalut Accounts" setting, adding `expense_other` in the search domain for the following accounts: - Exchange difference entries > Loss - Early payment discounts > Early Discount Gain - Early payment discounts > Early Discount Loss task-6116375 Forward-Port-Of: odoo/odoo#259583
This update resolves a visual bug where the "Add to Cart" button appeared squeezed on product pages in edit mode. Specifically, when the Image Area is set to 33 and the purchase style is Large, the button's size was incorrect. The fix ensures the button displays its intended size across all product page layouts.
Original PR description
This code fixes a bug related to the size of the “Add to Cart” button. To reproduce the bug, you need to be on a product page in edit mode. In this mode, you must set the Image Area to 33 and the purchase style to Large. You will see that the “Add to Cart” button is squeezed. The bug occurs because, in edit mode, a new span container is added around the button to indicate that it can be edited. The fix simply adds CSS on top of this container. find-when-working-on-task-6147939 **Before** <img width="1918" height="552" alt="before" src="https://github.com/user-attachments/assets/f46c78ff-b095-4738-821b-ff52272f160d" /> **After** <img width="1913" height="1054" alt="after" src="https://github.com/user-attachments/assets/ef38a68f-acbb-439b-883d-8e3ee45c5d4a" />
This update corrects a layout problem in the Odoo spreadsheet component. After a recent code change, the spreadsheet was displaying with text flowing from right to left. This fix ensures the spreadsheet displays correctly for users in both left-to-right and right-to-left language environments.
Original PR description
When we switched from scss to a css file in the o_spreadsheet library, we exposed the library style to the automatic convertion of `rtlcss`. This process replaces the explicit `tlr`rules to `rtl`. rtlcss can ignore files/rules with inline instructions but since the library is external to Odoo and is not explicitely aware of `rtlcss`' existence, we add an explicit rule inside Odoo which will not be exposed to `rtlcss` conversion. Task-6170966 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a minor visual issue where icons within thumbnails in the email attachment list were not positioned correctly. The change adjusts the base layout to allow for overrides, ensuring a consistent and professional appearance for users. This improves the overall user experience when viewing attachments.
Original PR description
We modify the base layout to allow a fix of the icon position in an override. Task-5152517 Forward-Port-Of: odoo/odoo#249055
This pull request addresses several minor bugs in the Documents module, primarily related to file uploads and display. Specifically, it fixes issues with scrolling to uploaded files, incorrect icon positioning, and display problems with the 'You' badge under certain conditions. These changes improve the overall usability and reliability of the Documents application.
Original PR description
[FIX] documents: scroll to uploaded record How to reproduce: - install documents - open the "All" folder and ensure there is enough folder to not see any file - open the detail panel - drag&drop file…
[FIX] documents: scroll to uploaded record How to reproduce: - install documents - open the "All" folder and ensure there is enough folder to not see any file - open the detail panel - drag&drop file in that folder The file is uploaded, but you have to scroll to it to see it. Moreover, despite the file being selected, it's not shown the detail panel. We solve the problem here by waiting the record to be rendered before scrolling to it and notify the detail panel. [FIX] documents: fix icon position in thumbnail How to reproduce: - install documents - open the chatter of a document - click on log a note, and upload a file The "trash" icon/button in the thumbnail is weirdly positioned (neither centered, neither on a border). We fix here the position the icon/button. [FIX] documents: fix "you" badge layout How to reproduce: - install documents - change the name of Mitchell Admin to a very long name - open the share panel owned by Mitchell Admin The "You" badge is not correctly displayed (the badge appears as "Y..." instead of "You" and the shape is not correct). We fix here the layout of the badge in such configuration. Task-5152517 Forward-Port-Of: odoo/enterprise#107686
This update fixes a technical issue where a promise created by the Odoo application could hang indefinitely if called multiple times quickly. The fix prevents the creation of new promises, ensuring that all requests are handled correctly and preventing performance problems. This improves overall application stability.
Original PR description
Whenever `isOnMainTab` is called, it creates and returns a new promise that will be resolved once the shared worker sends its response. However, if `isOnMainTab` is called twice in quick succession, before the shared worker answers, only the last promise is resolved, leaving the first one hanging forever. This commit fixes the issue by not recreating a promise if there is already one pending. Forward-Port-Of: odoo/odoo#262021
This update adjusts the checksum calculation for the IoT scale certification module within Odoo Enterprise. This change aligns with recent updates to the underlying IoT drivers, ensuring data integrity and accuracy for certified IoT devices. It’s a routine maintenance update to maintain the module’s functionality.
Original PR description
This PR adapts the expected checksum for the scale certified module corresponding change in iot_drivers module
This update resolves an issue where IoT-connected printers weren't correctly configured within Odoo's Point of Sale (PoS) system. Previously, these printers were unusable. This change ensures all printers, including those connected via IoT, are properly loaded and functional within the PoS environment.
Original PR description
preparation printers were not loaded in PoS as IoT devices making them unusable.
This update resolves an issue causing FEC imports to crash for French association companies in Guadeloupe and Martinique. The fix prevents the import process from incorrectly attempting to link asset models, which were unexpectedly included in the account templates. This ensures smoother and more reliable FEC imports for our French users.
Original PR description
Description of the issue: Importing an FEC on saas-19.1 can crash for French association companies in Guadeloupe or Martinique. During the import, account data is completed from the fr_comp account…
Description of the issue: Importing an FEC on saas-19.1 can crash for French association companies in Guadeloupe or Martinique. During the import, account data is completed from the fr_comp account templates. Since 19.1, those templates may include asset_model_ids, which makes the import try to resolve asset XML IDs that do not exist for that company setup. Steps to reproduce: 1. Create a new company with Guadeloupe or Martinique for country. 2. Set the French associations chart of accounts on it. 3. Go to Accounting -> Configuration -> Chart of Accounts. 4. Import the FEC file linked on the ticket. 5. Import fails with traceback. Desired behavior after fix: FEC import should keep the existing template completion behavior, but it should not copy asset_model_ids onto imported accounts. Importing an FEC for French association companies in Guadeloupe or Martinique should therefore no longer crash because of unrelated asset model references. Ticket [link](https://www.odoo.com/odoo/project.task/6053048) opw-6053048
This update fixes a critical issue where refunds for gift cards and e-wallets could allow their reuse, leading to incorrect accounting and potential fraud. It now prevents refunds, and also ensures that products associated with multiple loyalty programs are correctly separated into distinct order lines. This improves data accuracy and prevents misconfigurations.
Original PR description
Previously, it was possible to refund a gift card or e-wallet after creation. However, the associated code remained usable, allowing the gift card or e-wallet to be reused, which is not the expected behavior. To address this, refunds for gift cards and e-wallets are now prevented. Additionally, when a product is part of the trigger products for multiple gift card or e-wallet programs, it was not possible to create separate order lines for the same product with different programs selected. The second line was merged into the first. A condition has been added to prevent merging when different programs are selected. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6052281 Forward-Port-Of: odoo/odoo#261647 Forward-Port-Of: odoo/odoo#256896
This update corrects a problem that occurred when switching accounting chart templates, specifically when changing from a company to an association localization. The change ensures that old accounting records are properly removed during template updates, preventing errors related to foreign key constraints. This improves stability and prevents disruptions during localization adjustments.
Original PR description
**Issue:** Switching chart template/localization (Belgium Companies -> Belgium Associations) produces an error: ``` The operation cannot be completed: update or delete on table "account_account"…
**Issue:** Switching chart template/localization (Belgium Companies -> Belgium Associations) produces an error: ``` The operation cannot be completed: update or delete on table "account_account" violates RESTRICT setting of foreign key constraint "account_cash_rounding_profit_account_id_fkey" on table "account_cash_rounding" DETAIL: Key (id)=(1919) is referenced from table "account_cash_rounding" ``` **Steps to reproduce:** 1) install l10n_be module 2) make a new belgium company 3) go to accounting > configurations 4) change the fiscal localization package to "Belgium- Associations and Foundations" **Cause:** `account.cash.rounding` was not included in the chart template cleanup models. As a result, old `account.account` records were unlinked while still referenced by cash rounding records with `ondelete='restrict'` **Solution:** Include `account.cash.rounding` in `TEMPLATE_MODELS` so cleanup removes cash rounding records before deleting old accounts. And Add an assertion in `test_change_coa` to ensure old cash rounding records are deleted during COA switch. opw-6165374 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update allows support teams to log data from Point of Sale orders processed through the `sync_from_ui` system. A new configuration setting enables this logging, preventing unnecessary data collection and ensuring only relevant information is recorded. The addition of the `pos_reference` field in logs further aids in identifying specific orders during investigations.
Original PR description
During support investigations, it can be useful to log the data of the orders being processed in `sync_from_ui`. This commit adds a configuration parameter `point_of_sale.log_order_data` that allows to enable this logging. By default, it is disabled to avoid filling the logs with potentially sensitive data. Also, the pos_reference field is added to the order representation in the logs, as it's printed in the receipt and can be useful to identify the order in the logs. opw-6145038 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261792
This update resolves a minor configuration issue within Odoo's settings file (odoo.conf). Specifically, the way the Egyptian token is accessed has been corrected to use 'options' instead of 'default'. This change ensures proper functionality and avoids potential retrieval problems.
Original PR description
This PR fixes the section used to retrieve the egyptian token in odoo.conf file for it to be "options" instead of "default" Related PR: https://github.com/odoo/odoo/pull/255121 Forward-Port-Of: odoo/odoo#262006
This update resolves an issue where the 'PayableRoundingAmount' was incorrectly calculated as a cash rounding. The fix creates the invoice first and then applies post-fix adjustments to the untaxed amount, aligning with standard tax rounding methods. This ensures accurate invoice generation and compliance with UBL standards.
Original PR description
PayableRoundingAmount is not necessarily a cash rounding. It might also be the difference between the untaxed amount per line regarding the global untaxed amount due to the global tax rounding method. The idea in this commit is to create the invoice first and then, just like the code fixing the taxes, to post fix the untaxed amount after. opw-6151984 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260992
This update corrects a bug where changing a task's project would reset its state (done or canceled) unnecessarily. Now, when a task is marked as done or canceled, its state remains consistent even if the project is changed, ensuring accurate task tracking. This improves data reliability and workflow efficiency.
Original PR description
Before this commit, when the project of a task is changed, even if the state of that task is done or cancelled, the state is reset (except if the task is blocked by another one). This behavior is not expected for a task done/cancelled, we should not reconsider that task since it has been done/cancelled and so there is no reason to re-consider it once the project changed. This commit makes sure the state of the task is not reset when the project changed only if the state is a closed state or Waiting state. task-5361864 Forward-Port-Of: odoo/odoo#261648 Forward-Port-Of: odoo/odoo#252752
This update fixes an issue where invoices were incorrectly including non-validated timesheets in sales orders. The change ensures that invoices only reflect the quantity of timesheets that have been fully validated, aligning with the 'only validated TS' invoicing policy. This prevents over-invoicing and maintains accurate financial records.
Original PR description
**Steps to reproduce** - Settings: Timesheets > Invoicing policy = only validated TS. - Have a service product with an invoicing policy based on timesheets. - Create a sales order using this product.…
**Steps to reproduce** - Settings: Timesheets > Invoicing policy = only validated TS. - Have a service product with an invoicing policy based on timesheets. - Create a sales order using this product. - From the SO, click on the "Recorded" smart button and create 2 timesheets. Validate only one of them. - Invoice the SO, using a timesheets period that includes both TS. - Notice that the quantity of the invoice line includes the non-validated timesheet. **Cause** The domain excluding non-validated timesheets provided by `_timesheet_compute_delivered_quantity_domain` is not considered since c3b6053b09222d4bd2237e7de589a63fbef118f1 **Change** Since the purpose of the previous fix was to exclude timesheets linked to an invoice with a date before the "Invoicing Switch Threshold", this can be achieved by tweaking the `timesheet_domain` slightly, similar to the `_timesheet_domain_get_invoiced_lines` domain. opw-6116670 Forward-Port-Of: odoo/odoo#261621 Forward-Port-Of: odoo/odoo#259224
A technical bug was causing the appointment builder to crash when editing appointment types. This update corrects a mistake where unnecessary 'reload' information was being passed, preventing the builder from functioning correctly. This ensures a smoother experience for users editing appointment types.
Original PR description
'Reload' was wrongly passed as a prop to BuilderContext in 'Appointment Type' Option. This ended up in a traceback when user opened the builder on an appointment page. To see the issue: - Create an appointment, and go to its frontend page in debug mode - Start editing - Click anywhere on the page => Traceback We also replace `isReload` with `reload` in order to reload the page when applying the actions. task-6147936 opw-6144915 Forward-Port-Of: odoo/enterprise#115506
A recent issue causing the Enterprise portal's tour to fail has been resolved. The problem stemmed from errors with the worksheet's auto-saving and rendering, which disrupted the tour's functionality. This update ensures the tour operates correctly within the portal.
Original PR description
The worksheet is not auto saving and the worksheet is not rendering properly in portal, which caused the tour to fail. runbot error-242479 Forward-Port-Of: odoo/enterprise#115761