Daily updates from Odoo
Sunday, May 10, 2026
21 changes
6 changes
Resolved issues and error corrections
This update fixes an issue where tax reports for GSTR2B in Russia displayed incorrect amounts due to a problem with how tax tags were applied to negative repartition lines. Now, bills are shown with positive amounts, and credit notes with negative amounts, ensuring accurate tax reporting.
Original PR description
In reverse charge taxes, tax tags are added on negative repartition lines, causing the amounts to appear with the opposite sign in reports. Due to this, credit notes were shown as positive amounts and bills as negative amounts. This commit fixes the sign handling so that: - bills are shown with positive amounts - credit notes are shown with negative amounts Forward-Port-Of: odoo/enterprise#116828 Forward-Port-Of: odoo/enterprise#116740
This update fixes a reporting issue related to Goods and Services Tax (GST) filings in India (GSTR-3B). Previously, reverse charge tax entries were incorrectly placed in a specific table. Now, these entries are correctly reported in the appropriate table, ensuring accurate tax reporting and compliance.
Original PR description
Previously, journal items for import of services with reverse charge tax were shown only in table 4(A)(2) and not in table 3.1(d). However, since table 3.1(d) is meant for supplies liable to reverse charge, those entries should also be reported there. With this commit, import of service reverse charge entries are now correctly included in table 3.1(d) as well. Forward-Port-Of: odoo/enterprise#116827 Forward-Port-Of: odoo/enterprise#116708
This update fixes an issue where the image cropper in the HTML editor didn't correctly apply style settings like rounded corners. Now, users will see a precise preview of how their images will look after cropping, ensuring consistent results and a better user experience. This was previously addressed and temporarily lost during a website builder update.
Original PR description
When cropping images with style option applied (e.g., circle), the cropper ignored these styles, causing a mismatch between the preview and the final rendered image.This made the issue especially noticeable for rounded styles. This commit ensures the cropper reflects the applied style, allowing users to preview the final result more accurately. This behavior was previously fixed in https://github.com/odoo/odoo/pull/197374 but was lost during the website builder refactoring (see commit https://github.com/odoo-dev/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2). This change restores the expected behavior. task-6088098 Forward-Port-Of: odoo/odoo#263432 Forward-Port-Of: odoo/odoo#256966
This update corrects a flaw in how online statements are populated, ensuring users can retrieve a more complete history of transactions. Previously, the system only fetched transactions up to the last sync date, even if a user specified a starting date. Now, the system prioritizes the user-provided start date, combined with the last sync date, to accurately retrieve all relevant transactions.
Original PR description
When you want to find missing transactions, you have to put a starting date. But we don't use this starting date to find the last statement line, we only use the last sync date, which is wrong, because if the last sync date is after the starting date, the online transaction identifier will have the wrong date. It means we will only fetch the transactions from last sync date to today. This commit makes sure we take the start date first if it exists, then the last sync date. task-6197277 Forward-Port-Of: odoo/enterprise#116624
This update addresses a bug where the mobile app could unexpectedly log users out due to session rotation timing with webview requests (like attachments). The fix introduces a temporary flag to skip session rotation for specific requests, ensuring a smoother user experience. This doesn't pose a security risk as it simply adjusts rotation timing.
Original PR description
The session id rotates softly every 3 hours For some features, the mobile app sometimes does requests "outside" of the mobile app, through a webview for instance, and if the session rotation interval…
The session id rotates softly every 3 hours For some features, the mobile app sometimes does requests "outside" of the mobile app, through a webview for instance, and if the session rotation interval is reached at that moment, it rotates the session and the `set-cookie` instruction setting the new session cookie is received by the webview only, it's not propagated back to the mobile app. Then, this could lead for the user to be logged out of the mobile app if the soft automatic session rotation happens at the very unfortunate moment the request through that webview happens. For instance, the mobile app uses a webview to download attachments. If the session rotation happened during that request, the mobile app doesn't receive the `set-cookie` header and doesn't receive the new session id, leading for the user to be logged out of the mobile app. This revision aims to provide an option for the mobile app to temporary skip the session rotation for a specific request, such as the requests done through the webview during downloads. This option to be able to disable the rotation is not a security threat: If an attacker passes that header to disable the interval session rotation, he would avoid the session to be changed every 3 hours, but if he wouldn't he would still receive the new session id every 3 hours. The session rotation is for legitimate user / computer to rotate their session every 3 hours so that in case of data leak of their browser cookies, there is a chance the session cookie is already no longer valid when published on the public web. Legitimate users have no benefit using this option header to disable the rotation. Forward-Port-Of: odoo/odoo#263456 Forward-Port-Of: odoo/odoo#263325
This update enhances the logging process during cloud storage migration, providing more detailed information about the progress and any potential issues. Previously, migration logs were limited, making it harder to track and troubleshoot problems. Now, the logs will offer greater clarity, allowing our support team to quickly identify and resolve migration challenges for our customers.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263669 Forward-Port-Of: odoo/odoo#263557
4 changes
Resolved issues and error corrections
This update resolves an issue where tax reports for Russian VAT (GSTR2B) displayed incorrect amounts due to a sign discrepancy with reverse charge transactions. Now, bills are shown with positive amounts and credit notes with negative amounts, ensuring accurate financial reporting.
Original PR description
In reverse charge taxes, tax tags are added on negative repartition lines, causing the amounts to appear with the opposite sign in reports. Due to this, credit notes were shown as positive amounts and bills as negative amounts. This commit fixes the sign handling so that: - bills are shown with positive amounts - credit notes are shown with negative amounts Forward-Port-Of: odoo/enterprise#116828 Forward-Port-Of: odoo/enterprise#116740
This update fixes an issue where the COGS calculation was incorrectly inflated when multiple lines of the same product were invoiced separately from a single Sale Order. The change ensures accurate COGS reporting by isolating COGS calculations to the specific invoice line, preventing overestimation of costs and maintaining accurate profitability reports. This improves the reliability of financial data.
Original PR description
### Issue: When a Sale Order has multiple lines for the same FIFO-costed product and each line is invoiced separately, the COGS posted on the second (and any subsequent) invoice is incorrectly…
### Issue: When a Sale Order has multiple lines for the same FIFO-costed product and each line is invoiced separately, the COGS posted on the second (and any subsequent) invoice is incorrectly inflated, causing the sale to appear less profitable or even at a loss in the accounting records. ### Steps to reproduce: 1. Set a product as storable with FIFO costing and real-time valuation. 2. Create a Sale Order with two lines for the same product at different prices. 3. Confirm the SO and validate the two deliveries (each consumes a different FIFO layer). 4. Invoice the first SO line and post the invoice. 5. Invoice the second SO line and post the invoice. 6. Observe that the COGS on the second invoice is higher than the actual cost of the stock move linked to that line. ### Root Cause: _get_cogs_qty() and _get_posted_cogs_value() in sale_stock filtered already-posted COGS lines by product_id. This caused them to aggregate quantities and values across ALL SO lines sharing the same product. However, _get_cogs_price_unit() derives the unit cost only from the current line's stock move. The mismatch results in: (unit_cost_of_line_2 * total_qty_of_both_lines) - cogs_already_posted ### Fix: Replace the product_id filter with a sale-line-scoped filter using cogs_origin_id. By checking cogs_origin_id.sale_line_ids & sale_lines, only COGS originating from the same SO line(s) as the current invoice line are considered, correctly isolating each line's COGS from the others. opw-6004810 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257868
This update fixes an issue where the image cropper in the HTML editor didn't correctly display style options like rounded corners. The change ensures users see a precise preview of how the final image will look, improving the user experience and reducing errors when customizing images. This was previously addressed and temporarily lost during a website builder update.
Original PR description
When cropping images with style option applied (e.g., circle), the cropper ignored these styles, causing a mismatch between the preview and the final rendered image.This made the issue especially noticeable for rounded styles. This commit ensures the cropper reflects the applied style, allowing users to preview the final result more accurately. This behavior was previously fixed in https://github.com/odoo/odoo/pull/197374 but was lost during the website builder refactoring (see commit https://github.com/odoo-dev/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2). This change restores the expected behavior. task-6088098 Forward-Port-Of: odoo/odoo#263432 Forward-Port-Of: odoo/odoo#256966
This update corrects a flaw in how missing transactions are identified for online accounts. Previously, the system only checked transactions from the last sync date, leading to missed records. Now, the system prioritizes the provided start date, ensuring a more complete and accurate retrieval of online transaction data.
Original PR description
When you want to find missing transactions, you have to put a starting date. But we don't use this starting date to find the last statement line, we only use the last sync date, which is wrong, because if the last sync date is after the starting date, the online transaction identifier will have the wrong date. It means we will only fetch the transactions from last sync date to today. This commit makes sure we take the start date first if it exists, then the last sync date. task-6197277 Forward-Port-Of: odoo/enterprise#116624
5 changes
Resolved issues and error corrections
This update fixes a visual discrepancy in the image cropping preview. Previously, styles like 'circle' weren't correctly applied, leading to inaccurate previews. Now, the cropper accurately reflects the chosen style, ensuring users see the final image result more precisely.
Original PR description
When cropping images with style option applied (e.g., circle), the cropper ignored these styles, causing a mismatch between the preview and the final rendered image.This made the issue especially noticeable for rounded styles. This commit ensures the cropper reflects the applied style, allowing users to preview the final result more accurately. This behavior was previously fixed in https://github.com/odoo/odoo/pull/197374 but was lost during the website builder refactoring (see commit https://github.com/odoo-dev/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2). This change restores the expected behavior. task-6088098 Forward-Port-Of: odoo/odoo#263432 Forward-Port-Of: odoo/odoo#256966
This update enhances the logging process during cloud storage migration, providing more detailed information about the progress and any potential issues. Previously, migration logs were limited, making it harder to track and troubleshoot problems. Now, the logs will offer clearer insights, allowing our team to quickly identify and resolve any challenges related to migrating data to the cloud.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263669 Forward-Port-Of: odoo/odoo#263557
This update resolves a crash that could occur when attempting to unassign items from stock reception reports if the associated source document (like an MO) was empty. The fix prevents the system from attempting to remove references to empty source documents, making the report more reliable and robust. This primarily impacts clients with specific configurations.
Original PR description
#### Issue: Clicking `Unassign` from the stock reception report could raise a traceback when the outgoing move source document was empty. ``ValueError: Expected singleton: mrp.production()`` Please…
#### Issue: Clicking `Unassign` from the stock reception report could raise a traceback when the outgoing move source document was empty. ``ValueError: Expected singleton: mrp.production()`` Please note that this is not expected in standard Odoo, where reception report moves should normally be linked to a source document, such as an MO, SO, or picking. This case seems specific to the client database and may be due to a customization, but handling it makes the reception report more robust. #### Cause: The reception report built report lines from `source = (move._get_source_document(),)` and checked `if not source`. Since the tuple itself is truthy, moves whose `_get_source_document()` returned an empty recordset were not filtered out. For example if `out_move._get_source_document()` returns `mrp.production()`, then `source = (mrp.production(),)` is still truthy, so the report keeps the line even though the source document is empty. later `action_unassign()` called `_remove_reference()` on that empty source document, which crashed on `ensure_one()`. #### Fix: Added a helper function that skips moves where `_get_source_document()` is empty. Also skip reference synchronization in `_action_assign()` and `_action_unassign()` when the source document is empty just for more protection. opw-6174870 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263366
This update fixes an issue where images in Odoo still contained unnecessary data after being modified (shapes removed). The change cleans up this data, resulting in faster and more efficient image loading and display. This improves the overall user experience and website performance.
Original PR description
Steps to see the issue: - Add a shape to an image - Remove it => Image element in the DOM still has some data related to the shape. This commits adds a shared method to `ImageShapeOptionPlugin` to…
Steps to see the issue: - Add a shape to an image - Remove it => Image element in the DOM still has some data related to the shape. This commits adds a shared method to `ImageShapeOptionPlugin` to clean shape-related data when we apply a shape, or remove it, the method mirrors the behavior we had before the [html builder refactoring]. Also, commit [1] fixed the issue when the builder transfered shape or hover related data to incompatible images, when replacing an image with a shape/hover on it. However if these data attributes had already been saved prior to that commit, it would stay there indefinitely. The same could happen with hover effects attributes. Therefore, we add a resource that we call before saving data to clean any stale image data. Example of a CORS protected image: [2] [1]: https://github.com/odoo-dev/odoo/commit/137a6d7e59e1d788745c3b796a14839e52a8c5bc [2]: https://tinyjpg.com/images/social/website.jpg [html builder refactoring]: github.com/odoo/odoo/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-5172640 Forward-Port-Of: odoo/odoo#263433 Forward-Port-Of: odoo/odoo#259226
This update corrects a flaw in how Odoo retrieves online transaction data. Previously, users were limited to seeing transactions from the last sync date, even if a specific date range was requested. Now, the system prioritizes the user-provided start date, ensuring a more complete and accurate view of online statements.
Original PR description
When you want to find missing transactions, you have to put a starting date. But we don't use this starting date to find the last statement line, we only use the last sync date, which is wrong, because if the last sync date is after the starting date, the online transaction identifier will have the wrong date. It means we will only fetch the transactions from last sync date to today. This commit makes sure we take the start date first if it exists, then the last sync date. task-6197277 Forward-Port-Of: odoo/enterprise#116624
1 change
Resolved issues and error corrections
This update corrects a flaw in how Odoo retrieves online accounting transactions. Previously, users were limited to seeing transactions from the last sync date, even if a specific date range was requested. Now, the system prioritizes the user-provided start date, ensuring a more complete and accurate view of online transactions.
Original PR description
When you want to find missing transactions, you have to put a starting date. But we don't use this starting date to find the last statement line, we only use the last sync date, which is wrong, because if the last sync date is after the starting date, the online transaction identifier will have the wrong date. It means we will only fetch the transactions from last sync date to today. This commit makes sure we take the start date first if it exists, then the last sync date. task-6197277 Forward-Port-Of: odoo/enterprise#116624
3 changes
Resolved issues and error corrections
This update resolves an issue where tax reports (specifically for GSTR2B in India) were displaying incorrect amounts due to a problem with how negative tax lines were handled. Now, bills are shown with positive amounts and credit notes with negative amounts, ensuring accurate tax reporting.
Original PR description
In reverse charge taxes, tax tags are added on negative repartition lines, causing the amounts to appear with the opposite sign in reports. Due to this, credit notes were shown as positive amounts and bills as negative amounts. This commit fixes the sign handling so that: - bills are shown with positive amounts - credit notes are shown with negative amounts Forward-Port-Of: odoo/enterprise#116828 Forward-Port-Of: odoo/enterprise#116740
This update corrects an issue where users weren't able to retrieve all transactions when specifying a starting date. The system now correctly prioritizes the provided date, ensuring a more complete and accurate display of online statements. This improves the reliability of financial reporting.
Original PR description
When you want to find missing transactions, you have to put a starting date. But we don't use this starting date to find the last statement line, we only use the last sync date, which is wrong, because if the last sync date is after the starting date, the online transaction identifier will have the wrong date. It means we will only fetch the transactions from last sync date to today. This commit makes sure we take the start date first if it exists, then the last sync date. task-6197277 Forward-Port-Of: odoo/enterprise#116624
This update resolves issues with the WPS report generated for Saudi Arabian payroll, ensuring accurate file creation. Specifically, it now requires the Saudi National ID, simplifies bank field handling, and correctly maps bank details for employees outside of Saudi Arabia. These changes improve the reliability of payroll reporting.
Original PR description
this commit includes the following fixes for the WPS report in SA: - Make the Saudi National / IQAMA ID required for generating the WPS file. - Remove the condition on the field [57 - BANK] and have it always filled if the SARIE code is set. - If the employee bank account is from a different country (other than KSA or null), map the field [57 - BANK] to the swift code. task-6144299 Forward-Port-Of: odoo/enterprise#116725 Forward-Port-Of: odoo/enterprise#116419
1 change
Resolved issues and error corrections
This update corrects an issue where users weren't able to retrieve all online transactions by using a starting date. The system now prioritizes the provided start date, combined with the last sync date, to ensure a more complete and accurate retrieval of statement transactions. This improves the reliability of online financial data.
Original PR description
When you want to find missing transactions, you have to put a starting date. But we don't use this starting date to find the last statement line, we only use the last sync date, which is wrong, because if the last sync date is after the starting date, the online transaction identifier will have the wrong date. It means we will only fetch the transactions from last sync date to today. This commit makes sure we take the start date first if it exists, then the last sync date. task-6197277 Forward-Port-Of: odoo/enterprise#116624
1 change
Resolved issues and error corrections
This update resolves issues preventing the correct export of general ledger data in CSV format. Specifically, it corrects errors related to integer formatting and inactive currency handling, ensuring reliable reporting for financial data. This improves the accuracy and usability of the general ledger reports.
Original PR description
Follow-up to 8dfe4c0, addressing two issues in `_generate_csv_lazy_export`: 1. `AttributeError: 'int' object has no attribute 'id'` when `col['currency']` is a raw integer on aggregate lines returned by `_get_lines` with `no_format=True`. 2. `KeyError` on `decimal_places_per_cur_id` when a foreign currency account uses an inactive currency. The currency lookup was built with the default `active_test=True`, excluding archived currencies. opw-5994050 Forward-Port-Of: odoo/enterprise#112500