Friday, June 5, 2026
33 changes · saas-19.3
New functionality added to Odoo
This update incorporates official ISO 3166-2 standards for Azerbaijan, specifically adding the country's states. The address format has also been updated to display state names instead of country codes, improving data accuracy and user experience. This change ensures consistent and reliable location data within the system.
Original PR description
Added the states of Azerbaijan to align with official ISO 3166-2 standards. Also changed the address format of the country to show state name instead of state code. task-6236667 Forward-Port-Of: odoo/odoo#265959
Enhancements to existing features
This update adjusts the Obox application's position within the main menu. The app is now listed after 'Apps' and before 'Settings,' improving discoverability for users. This change streamlines the user experience by placing a key application in a more intuitive location.
Original PR description
This commit changes the Obox menu sequence so that the app appears at the end of the apps list by default (just before Apps and Settings). task-6275407 Forward-Port-Of: odoo/enterprise#119337
Resolved issues and error corrections
This update corrects a minor issue in the Odoo Enterprise spreadsheet edition by ensuring the correct naming convention (kebab-case) is used for cell corner properties. This change aligns with a recent update in the underlying o-spreadsheet library, preventing potential compatibility problems. It ensures the spreadsheet functionality continues to operate smoothly.
Original PR description
Since https://github.com/odoo/o-spreadsheet/pull/6063, the props name for cellCorner have been changed to use kebab-case. Forward-Port-Of: odoo/enterprise#119329
This update resolves an issue where the color picker wouldn't consistently apply color when selecting text in a collapsed state on mobile. The fix adjusts the selection offset to prevent browser normalization, ensuring the color is correctly displayed. This improves the user experience when editing text.
Original PR description
Steps to Reproduce: - Apply color on a collapsed selection in mobile - Type some text - Change color from the color picker Description of the issue: - The color picker closes, but the selected color is not applied. Cause: - The color was being applied correctly, but the selection was positioned at offset 0 of the newly created font node. As a result, the browser normalized the selection back to the previous font node, making it appear as though the color was not applied. Solution: - When applying color on a collapsed selection, set the selection offset to 1 instead of 0. This prevents browser normalization and keeps the cursor inside the newly created font tag, ensuring the color is applied correctly. task-6201171 Forward-Port-Of: odoo/odoo#267807 Forward-Port-Of: odoo/odoo#265438
This update resolves an issue where users without employee access rights couldn't search for timesheet versions. The fix removes a restriction on accessing version fields, ensuring broader search functionality while maintaining security through a previously implemented bypass mechanism. This improves usability for all users.
Original PR description
Issue: ---------------------------------------- When searching for a field from `hr.version` without any rights on Employees, we get an access error. Steps to reproduce:…
Issue: ---------------------------------------- When searching for a field from `hr.version` without any rights on Employees, we get an access error. Steps to reproduce: ---------------------------------------- - Timesheet > To Validate > All timesheet - Filter on Employee > Department (is set for example) - An error pops up Cause: ---------------------------------------- The field `department_id` of `hr.employee` belongs to `hr.version` and is accessible through the `_inherits` and the field `version_id`. When doing the search above, during the optimization of the domain, we end up trying to read `department_id` on `hr.employee.version_id`. But the field `hr.employee.version_id` is not accessible to users without Employee access rights. They only have rights on the field `hr.employee.current_version_id`. This occurs from version saas-19.1 because the access check was added in this version. ([commit](https://github.com/odoo/odoo/commit/aa58663a271e24a1fcb3f59e6bddfac50054703c)) Solution: ---------------------------------------- We remove the group restriction on `version_id`. The group restrictions are done with the fields of `hr.version`. As `version_id` is only a computed field from `current_version_id` which has `bypass_search_access=True`, this should not expose any field that wasn't already. `bypass_search_access=True` was added on `current_version_id` for the same reason. ([src](https://github.com/odoo/odoo/commit/94bb4a29189400d6bd0c2ca97eba271601262e1b)) opw-6149198 opw-6251866 Forward-Port-Of: odoo/odoo#264953
This update resolves an issue where setting a non-numeric value for the 'next check number' in bank journals caused an error. The fix ensures the system validates that the number is numeric before attempting to convert it, preventing the error and allowing users to correctly set check numbers.
Original PR description
Currently, an error occurs when a user sets a non-numeric value as the journal's next check number. **Steps to Reproduce:** - Install the `account_check_printing` module with demo data. - Go to…
Currently, an error occurs when a user sets a non-numeric value as the journal's next check number. **Steps to Reproduce:** - Install the `account_check_printing` module with demo data. - Go to `Invoicing` > `Configuration` > `Accounting` > `Journals`. - Open the `bank journal`. - In the `Outgoing Payments` tab > Enable `Manual Numbering`. - Set the `next check number` to a `non-numeric` value `(e.g. FA1234)` and `save`. `ValueError: invalid literal for int() with base 10: 'FA1234'` After [this commit], the next check number is converted to an integer without first validating that it contains only numeric characters [1]. Since the value can be non-numeric, converting it directly to an integer raises the error. This commit ensures that the next check number is converted to an integer only after verifying that it contains numeric characters only. [this commit]: https://github.com/odoo/odoo/commit/cc2004404462ecb523f7877569ce6a06b05341b4 [1]- https://github.com/odoo/odoo/blob/00dd75f345d7f5ddb04cecf52eca07e5a22c7d3c/addons/account_check_printing/models/account_journal.py#L57-L61 sentry-7498755988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266280
This update fixes a minor issue within the Odoo HTML editor where the shortcut for removing formatting in the tooltip wasn't functioning correctly. The change ensures users can consistently remove formatting from selected text using the intended keyboard shortcut. This improves the overall user experience and efficiency when working with rich text content.
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#267950
This update resolves a minor issue where the invoice creation process occasionally failed due to the invoice line not being fully added before the next step in a guided tour. Adding a brief delay after product selection ensures the invoice line is created correctly, preventing the tour from failing.
Original PR description
When a product is selected from the kanban view, the tour sometimes returns to the invoice form before the product is fully added. As a result, the invoice line is not created and the `.o_field_product_label_section_and_note_cell` element is missing from the table, causing the next tour step to fail. Add a short delay after selecting a product to ensure it is fully added to the invoice before proceeding with the following steps. runbot-238400 Forward-Port-Of: odoo/odoo#261295
This update resolves an issue where the system incorrectly blocked sending invoices to 0225 Peppol EAS partners. Previously, this was only allowed when the French localization module (`l10n_fr_pdp`) was installed. Now, it's enabled by default, resolving a problem with demo data installation and ensuring broader Peppol integration.
Original PR description
Previously we blocked the 0225 peppol_eas when `l10n_fr_pdp` is not installed. But you should still be able to send to 0225 partners with just peppol. Since the PDP module is auto installed with the French localization and we block the 0225 EAS server side on the peppol (non-PDP) server it should be fine to just allow it for everyone. It also caused an issue when installing the demo data for the `hair_salon` industry in a French company on trial. opw-6268629 Forward-Port-Of: odoo/odoo#268146 Forward-Port-Of: odoo/odoo#267993
This update corrects a bug where new appointments created through the Gantt view were defaulting to midnight instead of the intended booking time. The team fixed an error in the Gantt view override, ensuring bookings now use the correct time derived from the custom logic. This resolves a potential issue with inaccurate appointment scheduling.
Original PR description
The [commit] replaced the `onAddClicked` method with `_onNewClicked`, and updated all related calls and overrides accordingly. However, the appointment Gantt view override was mistakenly changed to override a non-existent `_onAddClicked` method, leaving the custom logic unused. As a result, bookings created through the `New` button in the Gantt view used midnight (12:00 AM) instead of the time derived from the custom logic as the default start datetime. This commit fixes the issue by correctly overriding `_onNewClicked`. [commit]: https://github.com/odoo/enterprise/commit/bc779c9ec5295f8d1fe06e8432c518c78c606ea2 Forward-Port-Of: odoo/enterprise#118799
This update resolves an issue where Mollie payments would fail if a customer's billing address was incomplete. Mollie now requires all necessary address fields (street, postal code, city, and country) to process payments, ensuring accurate transactions and preventing payment rejections. This improves the reliability of our Mollie payment integration.
Original PR description
Steps to reproduce: 1. Setup a Mollie online payment method. 2. Make a payment with a customer that has an incomplete* billing address. Expected behaviour: The payment request is initiated. Actual behaviour: Mollie rejects the payment request. *: Mollie will either accept no billing address, or a full address (must include street, postal code, city and country). If only some of these fields are present, Mollie will reject the payment request. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268188
This update resolves an issue where checkboxes within task descriptions in shared projects were incorrectly displayed as bullet points. The fix ensures the necessary styling for the 'html_editor' component is loaded, resulting in checkboxes rendering as intended. This improves the user experience for portal users accessing shared projects.
Original PR description
**Steps to reproduce:**
- Create a project
- Create a task and add a checkbox in the task description
- Share the project with a portal user
- Login as the portal user and open the task description
**Issue:**
In project sharing, checkboxes in the task description are displayed as bullet points.
**Cause:**
The required styles from `html_editor` were not loaded in the project sharing assets, so the related SCSS was not applied.
**Fix:**
Load the following missing SCSS files in the project sharing assets:
- html_editor/static/src/scss/html_editor.common.scss
- html_editor/static/src/scss/base_style.scss
Forward-Port-Of: odoo/odoo#267945This update resolves an issue where the website builder's column creation tool was incorrectly enabled, even when it shouldn't have been. The fix ensures that column creation is only allowed when appropriate, preventing users from creating columns in areas that aren't editable. This improves the stability and usability of the website builder.
Original PR description
When using the website builder, the tool in the powerbox to create columns is available, even when the node modified to create the columns is not `contenteditable`. This commit adds a condition for the availability of "columnize" tools: when there is no existing columns, check if the closest block ancestor (which will be replaced by the created node containing columns) is in a content editable node. Steps to reproduce: - Open website builder - Click in "Copyright" at the bottom of the footer - Type `/column` - Select "2 columns" in the powerbox - Bug: the created columns can be edited but will not be saved task-6247071 Forward-Port-Of: odoo/odoo#266420
This update fixes a technical error that prevented refunds in the Colombian Point of Sale (PoS) system. The issue stemmed from outdated code referencing an old function name, which caused a traceback during the refund process. This change ensures refunds are processed correctly for Colombian customers.
Original PR description
**Steps to reproduce:** - Setup a columbian company, DIAN should be in demo mode - Go to the PoS and make a sale with a columbian customer - Refund it - A traceback appears **Why the fix:** Some legacy code was left untouched when we changed the old **get_partner()** to the new **getPartner()** so we got a traceback as this function does not exist anymore. We also change the **set_partner(partner)** to **setPartner(partner)** as it was also forgotten. opw-6231856 Forward-Port-Of: odoo/enterprise#118651 Forward-Port-Of: odoo/enterprise#118054
This update resolves an issue where Instagram videos weren't displaying correctly as background images in Odoo's website builder. The problem stemmed from an unnecessary addition of a URL parameter that Instagram's system rejected. This change removes that addition, ensuring Instagram videos function as expected.
Original PR description
Steps to reproduce: =================== 1. Edit a page, add a Cover/Banner block. 2. Set its background to a video, paste an Instagram URL 3. Save and open the published page. => Instagram embed is…
Steps to reproduce: =================== 1. Edit a page, add a Cover/Banner block. 2. Set its background to a video, paste an Instagram URL 3. Save and open the published page. => Instagram embed is broken (iframe shows nothing / error). Cause: ======= Background videos broke for Instagram because the BackgroundVideo interaction unconditionally appends "&enablejsapi=1" to the iframe URL on start. Instagram embed URLs have no query string (`//www.instagram.com/p/<id>/embed/`), so the append produces `//www.instagram.com/p/<id>/embed/&enablejsapi=1` the `&` ends up in the path and Instagram refuses to render. The unconditional append is itself a regression from the public-widget → interaction refactor in [2]. The original code in 18.0 only added the param when `isYoutubeVideo && isMobileEnv`, as a workaround for old YouTube records that lacked it. Since [1], `enablejsapi=1` is already injected server-side in `html_editor/tools.py` / `web_editor/tools.py` when building YouTube autoplay embed URLs, so any YouTube background saved via the media dialog from 17.0 onward already has it. The JS append is redundant for YouTube and harmful for Instagram. Solution: ========= remove the unconditional append of `&enablejsapi=1` in the BackgroundVideo interaction [1]: https://github.com/odoo/odoo/commit/ca60af9dadc25adbc9eb159870ce1233a2886492 [2]: https://github.com/odoo/odoo/commit/b9b3a605e0f4 opw-6233081 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267016
This update resolves an issue where the system failed to correctly process tax percentages from Peppol XML invoices. The fix ensures that invoices with tax information are now properly imported and processed, preventing empty bill creation and related errors. This improves the reliability of invoice data import.
Original PR description
Steps to reproduce: - Upload a Peppol XML bill having the tax percent reported under "TaxTotal/TaxSubtotal/Percent" Issue: Bill will be created empty. The chatter will report the error ``` Error importing attachment 'bill.xml' (type=account.edi.xml.ubl_bis3): This specific error occurred during the import: float() argument must be a string or a real number, not 'lxml.etree._Element' ``` opw-6227637 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/6227637) Forward-Port-Of: odoo/odoo#266307
This update fixes an issue where a recurring activity would be unnecessarily recreated after being marked as 'done'. The change prevents the system from re-creating the activity if it's already marked as completed, streamlining the process and improving efficiency. This ensures accurate scheduling and reduces potential errors.
Original PR description
When a next activity is set to done, the record is archived. So once the next activity set on the contract is set to done, the cron will re-create it the next day as it won't see it. So we add active_test=False, to be sure that one has not already been set to done --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268206
This update fixes an issue where check amounts weren't being properly rounded in the Philippines (PH) version of Odoo. Previously, the check amount in words displayed with an incorrect decimal format, including 'ONLY'. This change ensures that check amounts are rounded to the nearest cent, presenting a more accurate and professional representation of payments.
Original PR description
Current behaviour: --- When paying with checks, the amount is not rounded in the check amount in words string. Steps to reproduce: --- 1. Switch to PH company 2. Set setting Check Layout as "Print Check - PH" 3. Create a new vendor bill 4. Add a product with a specific price like 91490.15 5. Confirm the bill, click on Register Payment 6. Select Payment Method "Checks", Create Payment 7. Go to the payment, Amount in Words is wrong 8. Ninety-One Thousand Four Hundred Ninety And 15000000001/100 ONLY Expected behaviour: --- The decimal amount should be rounded, and "ONLY" shouldn't appear. Fix: --- Rounded the pay amount And backported: https://github.com/odoo/enterprise/commit/bb6c9848665709c14c5113b2c98976f869cd473b opw-6058344 Forward-Port-Of: odoo/enterprise#117679 Forward-Port-Of: odoo/enterprise#116717
This update corrects a flaw in the interval inversion function, ensuring it accurately handles various edge cases. The fix includes new test cases to guarantee correct behavior across a wider range of inputs, preventing potential errors in calculations.
Original PR description
The [commit] introduced the method for inverting the interval inside the given limits. The method was failing for the following edge cases: ```python >>> invert_intervals([(1, 2), (4, 5)], 0, 10)…
The [commit] introduced the method for inverting the interval inside the given limits. The method was failing for the following edge cases: ```python >>> invert_intervals([(1, 2), (4, 5)], 0, 10) result - [(2, 4), (5, 10)] expected - [(0, 1), (2, 4), (5, 10)]? >>> invert_intervals([(-2, -1)], 0, 10) result - [(0, 10)] expected - same >>> invert_intervals([(11, 12)], 0, 10) result - [] expected - [(0, 10)] >>> invert_intervals([(-1, 1), (2, 5), (8, 12)], 0, 10) result - [(1, 2), (5, 8)] expected - same >>> invert_intervals([(2, 5), (8, 12)], 0, 10) result - [(5, 8)] expected - [(0, 2), (5, 8)] >>> invert_intervals([(2, 5), (11, 12)], 0, 10) result - [] expected - [(0, 2), (5, 10)] ``` This commit fixes the function to correctly handle all the cases. The test cases are also added to test all the edge cases. [commit]: https://github.com/odoo/enterprise/commit/53450065be0c3ec9d648d4fd39ec3a9a912bd06c Forward-Port-Of: odoo/odoo#268161 Forward-Port-Of: odoo/odoo#267917
This update resolves an issue in the Lithuanian tax reporting module (l10n_lt) where certain calculations were incorrectly presented. The code has been adjusted to negate specific lines, ensuring accurate tax reporting for Lithuanian businesses. This fix improves the reliability of financial data.
Original PR description
Lines 29 to 34 in the tax report should be negated opw-5985774 Forward-Port-Of: odoo/odoo#259147
This update resolves an issue where the forum toolbar wasn't consistently visible or repositioning correctly within website forums, specifically when the forum was displayed inside an iframe. The fix ensures scroll events are properly detected within the iframe's view, guaranteeing the toolbar appears and adjusts correctly for all users.
Original PR description
Description of the issue: - In website forums, the toolbar was either not visible or did not reposition correctly after scrolling. Cause: - This issue occurred only in forums when an iframe was present. In that case, scroll events were not triggered on the window visual viewport, preventing toolbar repositioning. Solution: - Attached scroll events to the iframe’s visual viewport instead of the window visual viewport when an iframe is present. task-6201171 Forward-Port-Of: odoo/odoo#265221
This update ensures the 'New' button in Kanban views functions correctly when Odoo is operating offline. Previously, the button was always disabled, even when offline. Now, the system correctly checks for the availability of a full creation form view, allowing users to create new records seamlessly.
Original PR description
Before this commit, when working offline, the "New" button in a Kanban view was always disabled if quick create was not enabled. This occurred because the code incorrectly checked whether the quick create view had been previously visited online, rather than looking for the full fallback creation form view. This commit resolves the issue by correctly verifying if the creation form view itself was previously visited. Additionally, it ensures that if a custom action is specified for `on_create` (other than opening a standard form view or quick create), the button will remain disabled while offline.
This update fixes a technical issue where changing POS configurations within Odoo Enterprise caused a traceback error when opening preparation displays. The fix ensures that orders linked to old POS configurations are no longer processed, preventing this error and improving stability for users managing kitchen displays and order workflows.
Original PR description
Steps: = - Create a kitchen display linked to any one Point of Sale. - Open the POS, create a draft order, and send it to the kitchen display. - Open the kitchen display configuration from the backend and change the POS configuration to a different one. - Open the kitchen display again. Issue: = - A traceback occurs when opening the preparation display after changing the POS configuration while orders from the old configuration are still open and linked to selected kitchen display. Fix: = - Apply a POS config domain while fetching open orders for the preparation display to avoid processing orders from old configurations, eliminating the traceback. task-6196096
This update corrects an issue with the data sent to UrbanPiper for store updates, ensuring accurate store information is transmitted. Additionally, a previously removed test case has been restored, and the delivery provider is now hidden from payment method views. These changes improve the reliability and presentation of UrbanPiper integration.
Original PR description
Fixes the UrbanPiper store timings payload used in store update requests. Also restores the preparation display assertion in `test_01_order_flow`, which was accidentally removed during refactoring. Additionally, hides the delivery provider in the payment method view. Task-6065459 Runbot Err-[242023](https://runbot.odoo.com/odoo/error/242023)
This update resolves an issue where users were blocked from uploading documents to requests linked to records they didn't have full access to. By adding a special permission bypass, users can now upload documents regardless of their access level to the related record, improving usability and workflow efficiency.
Original PR description
Issue: Users are currently blocked from uploading requested documents if the request is linked to a record they do not have access to (e.g., User A links Record X to a request assigned to User B, but User B lacks read/write access to Record X). The system throws an error because the user cannot create an attachment for that record. Fix: Add .sudo() on the attachment creation process. task-6107099 Forward-Port-Of: odoo/enterprise#113698
This update prevents incorrect tax calculations on COGS lines generated from vendor bills. Previously, manual tax adjustments were overwritten due to the system applying product taxes to these internal operations. This change ensures COGS lines accurately reflect internal costs without tax implications.
Original PR description
Issue: After manually modifying the taxes on a vendor bill that generates COGS lines, confirming the vendor bill causes the taxes to revert to their original values before the manual edit. This…
Issue: After manually modifying the taxes on a vendor bill that generates COGS lines, confirming the vendor bill causes the taxes to revert to their original values before the manual edit. This happens because the product’s purchase taxes are applied to the generated COGS lines, which triggers the tax recomputation logic and overwrites the manually adjusted tax amounts. However, COGS lines represent internal operations and should not have taxes applied to them Steps to reproduce: 1. Turn on Anglo-Saxon accounting 2. Turn on automatic accounting 3. Make a FIFO product category and make the valuation automatic 4. Make a new product and set the FIFO product category on it 5. Make sure the product has a vendor tax set 6. Make a purchase order for 10 of the FIFO product category at $10 7. Create and validate the receipt for 10 8. Make a sales order for 6 of the FIFO product category at $10 9. Create and validate the delivery for 6 10. Create the vendor bill for 10 the purchase order created above (make sure that there is a tax set on the vendor bill; the vendor tax that was set on the product). Make this vendor bill set for 10 at $20 11. Edit the tax at the bottom of the total 12. Confirm the vendor bill 13. Notice that the tax at the bottom of the total changes 14. Reset the vendor bill 15. Remove the purchase tax from the product 16. Confirm the vendor bill again and notice that the tax at the bottom of the total does not change this time Cause: On confirmation, the COGS lines on the vendor bill will be generated and “_compute_tax_ids” will be triggered on those lines. Since COGS lines have a “product_id” set on them, those lines will receive the purchase tax set on the product. Setting the “tax_ids” on those COGS lines will cause tax computation to trigger again, which will reset the manually edited tax amount to the new computed amount. However, since COGS lines come in pairs that are equal and opposite in amount, the taxes from both COGS lines will cancel out, and the new computed tax amount does not change Solution: Skip setting the purchase taxes of the product onto COGS lines in “_compute_tax_ids” opw-6110692 Forward-Port-Of: odoo/odoo#268434 Forward-Port-Of: odoo/odoo#265352
This update resolves a potential error that could occur when creating new PDP reporting flows. Previously, the system would crash if it tried to compare dates when the due period dates were initially empty. This fix ensures the system handles missing dates gracefully, improving the stability and reliability of the reporting process.
Original PR description
PDP reporting flows compute their period status from the due period dates. On a new or incomplete flow record, those dates can still be empty during form/onchange initialization. The compute then tried to compare today's date with `False`, which could crash generic form creation. This patch makes the compute handle missing period dates before doing date comparisons. runbot.build.error-939459 Forward-Port-Of: odoo/odoo#268002
This update prevents Odoo from crashing when the Barcode Lookup API returns a broken image URL. Previously, an invalid URL would cause an error. Now, the system gracefully handles these errors, safely ignoring the bad URL and continuing to function correctly.
Original PR description
[FIX] product_barcodelookup: avoid crash on invalid image URLs **Steps to Reproduce:** - Install Sales module. - Configure a valid Barcode Lookup API key. - Create a product without an image. - Set a…
[FIX] product_barcodelookup: avoid crash on invalid image URLs
**Steps to Reproduce:**
- Install Sales module.
- Configure a valid Barcode Lookup API key.
- Create a product without an image.
- Set a barcode whose returned image URL is broken or returns HTTP 404
(e.g. `8426904171073`).
- Select the product and trigger the server action:
`Action -> Get Pictures from Barcode Lookup`
Issue:
**During image fetching:**
- Barcode Lookup API successfully returns product data and image URLs.
- `_get_image_from_url()` attempts to download the image.
- The image URL responds with HTTP 404.
- `barcode_lookup_request()` returns a dict for non-200 responses.
- `_get_image_from_url()` assumes the response is always a `requests.Response`
object and directly accesses: `response.status_code`
- This causes: `AttributeError: 'dict' object has no attribute 'status_code'`
**Root Cause:**
- `barcode_lookup_request()` returns inconsistent response types:
- `requests.Response` for successful requests
- `dict` for failed requests
- _get_image_from_url() does not handle the dict response before accessing
response attributes.
**Solution:**
- Make barcode_lookup_request() always return a One Response
object.
- Move the response validation to the callers instead of returning custom
dict objects.
**Result:**
- No RPC crash when image URLs are invalid or return 404.
- Broken image URLs are safely ignored.
**OPW-6200749**
Forward-Port-Of: odoo/enterprise#116925This update resolves a bug where reports with sections would always revert to the first section after a soft reload. The fix ensures that the last opened section is correctly restored, improving the user experience when refreshing reports with multiple sections. This prevents user frustration and ensures accurate report viewing.
Original PR description
When opening a report with sections, we dont save the last opened section. So following a soft-reload, it always redirect to the first section. To reproduce: - Install l10n_fr_reports - Set up the Tax Returns - Open the Tax Report from the Fiscal Declaration - Open the 2069 RCI - Click on the line "Add new section" which trigger a soft reload *or find another way to trigger a soft reload from a report with sections*
This update resolves an issue where invoicing users were unable to access related reporting data within invoices. By allowing invoicing users to read PDP flow relations, this change enables them to properly utilize e-reporting fields and buttons, improving invoice processing efficiency. This fix was triggered by a build error and aligns with existing workflows.
Original PR description
Allow invoicing users to read PDP reporting flows. Invoice views can read PDP flow relations to evaluate e-reporting-related fields or buttons. Users with invoicing access could open the invoice but were blocked when Odoo tried to read the linked PDP flow. runbot.build.error-939457 Forward-Port-Of: odoo/odoo#268462
This update fixes an issue where a bank transaction creation process would unexpectedly crash when encountering an error. The fix ensures the quick create form is properly closed and the error is displayed, improving the user experience and preventing data loss. This resolves a technical glitch impacting bank transaction functionality.
Original PR description
**Problem:** When an error is thrown upon creating a bank transaction in the kanban view, a traceback occurs due to trying to access the quickCreateState which does not exist in this context (`this` = BankRecQuickCreateController). **Steps to Reproduce:** - Force the suspense account of the bank journal to be False - Go to bank transactions of that journal in kanban view and try to create a new transaction -> Traceback **Solution:** The expected behavior is for the quick create to be closed, then throw the error. Therefore, onCancel() can be called before throwing the error. opw-6186901 Forward-Port-Of: odoo/enterprise#118842
This update prevents eLearning challenge participants from being listed in the email headers, enhancing privacy and data security. The previous system inadvertently revealed participant details, which has now been corrected through a refined approach to email header configuration.
Original PR description
**Steps to reproduce:** - Install eLearning app with gamification - Go to Settings > Gamification Tools > Challenges - Set a challenge with multiple participants (portals / internals) - Set its state…
**Steps to reproduce:** - Install eLearning app with gamification - Go to Settings > Gamification Tools > Challenges - Set a challenge with multiple participants (portals / internals) - Set its state to Done - Notification email is sent to every participants - They can see each other in the mail header (portal user can see all other portal users, internal user can see all portal users) **Issue:** Since [1] external recipients are added in the mail header, but this is not adequate for every flows (here there is no need for the participants to be aware of each other). **Fix:** In [2] this issue was mitigated by removing the `'X-Msg-To-Add'` from the header for models which don't need it. Then in [3] the solution was replaced by a more generic approach using `_CUSTOMER_HEADERS_LIMIT_COUNT = 0`. [1] https://github.com/odoo/odoo/commit/42aaaef59d21558438c767c6dd8a21674e5df9df [2] https://github.com/odoo/odoo/commit/e6c13ce4436b3c8b3a2058d2ccf65a7da1b256b2 [3] https://github.com/odoo/odoo/commit/c4dbd868b9c7e26f11db4d2cacef7ffce6c87082 opw-6099745 Forward-Port-Of: odoo/odoo#267192
This update simplifies how Odoo determines user locations. Previously, the system relied on a complex database lookup. Now, if a country cannot be identified, it defaults to using the user's recorded city, providing a more reliable and straightforward solution. This change enhances location accuracy and reduces potential issues.
Original PR description
This reverts commit fd7e3393158fc637c555f612a54f3e8c7c72bd96. Then we provide a simpler fix by defaulting to the city record if a country cannot be resolved. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267866