Monday, May 18, 2026
24 changes · saas-19.1
Resolved issues and error corrections
This update simplifies the process of retrieving transaction data from Codabox for users already connected. Previously, a write access check was required, which was unnecessary. This change removes this restriction, streamlining the process and improving efficiency.
Original PR description
Currently, we use the `_l10n_be_codabox_verify_prerequisites` method before trying to fetch transactions. This method checks if the user has write access rights on res.company model which should not be mandatory to fetch transactions from codabox when the connexion is already created. opw-6108811 Forward-Port-Of: odoo/enterprise#117097
This update resolves an issue where pressing Enter after a styled heading created a new paragraph with the same styling. The fix ensures that newly created paragraphs are empty and without inherited styles, aligning with the expected behavior. This improves the consistency and predictability of the HTML editor.
Original PR description
Problem: Pressing Enter at the end of a styled heading (e.g., with a color) creates a new paragraph that inherits the heading styles. This is no longer the expected behavior. The new paragraph should be empty and without inherited styles. Solution: When splitting a heading at its boundaries and creating a base container, fill it with a `br` instead of carrying over styles. Steps to reproduce: - Add a heading. - Apply a style (e.g., color). - Place the caret at the end of the heading. - Press Enter. - Observe that the new paragraph still has the heading color. task-6147897 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264624 Forward-Port-Of: odoo/odoo#262150
This update resolves an issue that occurred when loading paid orders in the Point of Sale module. The previous process incorrectly loaded account moves, leading to errors. This change streamlines the process by removing redundant loading steps, ensuring paid orders load correctly.
Original PR description
Before this commit, when loading the paid orders it would load the account move with the "account_move" key, but this key is wrong as the account move model is loaded with the "account.move". Also, the account move is already loaded by the "read_pos_data" method in the point_of_sale module, so we can just remove it from here. opw-6218467 Forward-Port-Of: odoo/enterprise#117422
This update aligns report subheaders and numeric data within reports to create a more consistent and professional appearance. Previously, the alignment was inconsistent, making the reports less readable. This change improves the overall presentation of financial reports.
Original PR description
Before this commit, subheaders of numeric columns were centered, while the figures in the columns were aligned to the end. This commit ensures that both the subheader and the figures are aligned the same way (center or end). task-6197223 Forward-Port-Of: odoo/enterprise#116578
This update fixes a minor issue where the FEC file parser would fail when encountering empty lines. The change allows the system to gracefully skip these empty lines, ensuring that all valid FEC files are processed correctly and preventing potential data loss. This improves the reliability of the French localization import process.
Original PR description
It could happens that we have some empty lines in the fec files, the parser was returning an error when that happened. We still want to process the file so we will just skip the empty lines. task-6169168 Forward-Port-Of: odoo/enterprise#115758
This update enhances the reliability of Odoo's safe evaluation feature by catching and handling `IntegrityError` exceptions. This ensures consistent behavior regardless of whether the issue originates in the core business logic or within the safe evaluation environment, preventing unexpected application failures.
Original PR description
It makes sense to bubble up the `psycopg2.IntegrityError` (as well as the subcase `ConcurrencyError`) so that the retry mechanism can handle this exception. In fact, this exception can be triggered without necessarily a problem with the "logic/business code". This ensures consistent behavior between the business logic and the code executed in `safe_eval`. Task-6215886 Forward-Port-Of: odoo/odoo#264266
This update corrects an error occurring when using the Envia delivery method in Chile. The issue stemmed from a mismatch between Odoo's state code mapping and Envia's API requirements, specifically regarding the format of the 'state' field. The update now properly formats the state code to comply with Envia's specifications, enabling successful delivery processing.
Original PR description
### Steps to reproduce: - Install delivery_envia - Website > Configuration > eCommerce > Delivery Methods > Envia - Enable the delivery method, sync the carrier and Publish it - With a portal user >…
### Steps to reproduce:
- Install delivery_envia
- Website > Configuration > eCommerce > Delivery Methods > Envia
- Enable the delivery method, sync the carrier and Publish it
- With a portal user > Shop > Add any product to your cart > Checkout
- Register an address a valid 'Chile' address and confirm say:
'street and Number': Avenida Providencia 1432, Depto 402
'city': Santiago 'zip': 8320000
'country': Chile 'state': Metropolitana
#### > Envia Error: Invalid Option - String is too long at #->properties:destination
### Cause of the issue:
The problem is caused by the fact that Envia's api expects a 2-3 digits to represent state codes: https://docs.envia.com/reference/state-by-code
The mapping from Odoo's code state representation to envia's one is expected ot be performed by this mapping:
https://github.com/odoo/enterprise/blob/75cba6d5a88ebc4e0f35040a173ac1c443638daf/delivery_envia/models/envia_request.py#L27-L43 when the address is converted here:
https://github.com/odoo/enterprise/blob/75cba6d5a88ebc4e0f35040a173ac1c443638daf/delivery_envia/models/envia_request.py#L535-L542 That being said, the `Chile`'s code states of have been changed in [6694a3942c58ff1a56c9e4b36edbe126dd1e66f8](https://github.com/odoo/odoo/commit/6694a3942c58ff1a56c9e4b36edbe126dd1e66f8) to match the official Iso but not in the Envia's mapping leading a failling match keeping the 4 charracter long `CL-RM` of the `Metropolitan` state provided in to the Envia's api as address data.
opw-6210007
Forward-Port-Of: odoo/enterprise#117280This update fixes an issue where the remaining time wasn't being displayed correctly for sales orders linked to project tasks. A previous change removed a necessary context key, preventing the display of this information. The update restores this key, ensuring accurate time remaining information is shown.
Original PR description
Steps to Reproduce: - Open any project linked with a sales order - Open task and click on Sale Oder Item dropdown. Issue: - You can see that SOL's with time remaining don't show the amount of time left Reason: - In this PR https://github.com/odoo/odoo/pull/193079 a record (view_task_form2_inherit_sale_timesheet) has been removed. - So the context key `with_remaining_hours` required to show remaining time is missing. Fix: - Add the record back which updates context task-6170953 Forward-Port-Of: odoo/odoo#262746
This update ensures that donation confirmation emails are sent in the user's preferred language, regardless of their anonymous status. Previously, emails were defaulted to English, even when users selected a different language on the website. This change improves the user experience and ensures accurate communication for all donors.
Original PR description
Steps to reproduce: =================== 1. Configure website with at least 1 language installed different from English. ex: English and French. 2. As anonymous user, change wehbsite language and make…
Steps to reproduce: =================== 1. Configure website with at least 1 language installed different from English. ex: English and French. 2. As anonymous user, change wehbsite language and make a donation via the donation snippet. 3. Check the outgoing confirmation email. => Email body is rendered in English. Cause: ====== The donation confirmation email rendered with `self.partner_id.lang`. For anonymous donors, `partner_id` is the website's shared public user partner, so every anonymous donor received the email in whatever language was set on that partner (or English if unset), regardless of the language they were browsing in. Solution: ========= `payment.transaction` already has a `partner_lang` field auto-filled from `partner.lang` at creation. - override it in the `/donation/transaction` controller with `request.env.lang` when the public partner is used, capturing the request language at donation time (also works later from `_cron_post_process`, which has no request context); - render `_send_donation_email` using `self.partner_lang` instead of `self.partner_id.lang`. opw-5875338 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259351
This update ensures charts accurately display data when users specify custom date ranges, including open start or end dates. Previously, the chart's granularity would shift unnecessarily. Now, the chart maintains its current level of detail, regardless of the user-defined date range, providing a more consistent and reliable visualization of data.
Original PR description
The charts adapt their granularity when a date global filter is updated. But the code didn't handle the cases where the user sets a custom range with an open start or end date (eg. `until 2024-01-01`). In those case picking the best granularity is not practical (because it fully depends on the server data), so we will just keep the current granularity. Task: [6196246](https://www.odoo.com/web#id=6196246&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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#263019
This update resolves a confusing user experience where discount codes wouldn't re-apply after being discarded. Now, users can successfully re-apply a discarded code, ensuring rewards are correctly applied without creating duplicate entries or impacting existing orders. This improves the overall customer experience and simplifies the discount redemption process.
Original PR description
Issue: --- ### Steps to reproduce: 1- Create a `Discount Code` program. 2- In SO, use `Coupon Code` wizard and use the code. 3- After available rewards are shown, discard the wizard. 4- Re-apply the code. Validation Error: The promo code is already applied. As the reward is not applied, this is functionally confusing. At this point We can see the reward only inside the rewards wizard view. If we allow re-apply the code in case no reward line is created for the `rule.program_id`, we can still see the reward by re-applying the same code, without any side effects. opw-6164198 Forward-Port-Of: odoo/odoo#264105 Forward-Port-Of: odoo/odoo#261950
This update corrects a technical issue that prevented accurate payroll calculations when a payrun had no associated payslips. The fix ensures the system handles empty payrun scenarios correctly, preventing errors and maintaining payroll accuracy. This improves the reliability of the Australian HR Payroll module.
Original PR description
If the payrun does not have any payslips, the _get_payslip_stp is called on an empty recordset, which causes the compute to fail. This commit fixes the _get_payslip_stp compute for empty recordset. task-6215823 Forward-Port-Of: odoo/enterprise#117198
This update fixes an issue where the call preview overlay overlapped with call actions on smaller screens, making it difficult to use. The change ensures the preview content remains readable and accessible, improving the user experience for all users. This resolves a previous bug reported in #235707.
Original PR description
Purpose of this PR: Since #235707, the call preview content could overlap the call actions on small screens. This commit prevents the overlap and keeps the preview readable. Before/After: <table> <tr> <td> <img width="398" height="691" alt="image" src="https://github.com/user-attachments/assets/da7eaf5b-387e-439f-80bb-cb6dd8c07454" /> <td> <img width="391" height="691" alt="image" src="https://github.com/user-attachments/assets/384a08d1-6b51-490a-8b57-267a3bb1b3d5" /> </table> task-[6201269](https://www.odoo.com/odoo/project/1519/tasks/6201269) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a problem where users without sufficient accounting permissions would encounter errors when retrieving component data from purchase orders created by others. The change ensures proper access rights are granted, allowing all users to accurately scrape component information, regardless of who created the original order. This improves data visibility and reporting.
Original PR description
When scraping the component of a MO created by another user you could get an access error saying you don't have write access on account analytic lines. Steps to reproduce: ------------------- *…
When scraping the component of a MO created by another user you could get an access error saying you don't have write access on account analytic lines. Steps to reproduce: ------------------- * Install timesheet_grid and project_mrp_account * Create product A, storable * Create product B with a cost of 20 and also storable * Update the available quantity of product B * Create a BoM for product A, it should only require one product B * Update Marc Demo access right and make sure he doesn't have access to any accounting stuff and he has atleast timesheet approver * Create a first MO for 1 product A and produce it * Create a second MO for 1 prodcuct A but just confirm it * Login as Marc Demo and try to scrap the component of the second MO > Observation: You get an access error here https://github.com/odoo/odoo/blob/d98afdc08b46bf458eaa287ea882cc7663286a59/addons/stock_account/models/analytic_account.py#L95 opw-5954989 Forward-Port-Of: odoo/odoo#261588 Forward-Port-Of: odoo/odoo#255824
This update fixes inconsistencies in the XML structure used for Swedish bank payments (l10n_se_bban). Specifically, it ensures the correct format for bank identification details, enhancing compatibility with Swedish payment systems and improving data accuracy. This resolves a technical issue related to ISO 20022 compliance.
Original PR description
Here is few fixes added to the swedish iso 20022 XML: - CdtrAgt seems to be always mandatory, change the condition in `_skip_CdtrAgt` to always use the CdtrAgt if payment_method is iso20022_se - The `_is_se_bban` is too restrictive, this should be always True when payment method is swedish iso - The `FinInstnId` node can either contain BIC or ClrSysMmbId. But as ClrSysMmbId seems to change from one bank to another, it's more relevant to always use the BIC. opw-5395736 Forward-Port-Of: odoo/enterprise#114662
This update fixes an issue where self-order receipts incorrectly displayed 'Service at Table' instead of 'Pickup At Counter' when a customer selected a counter service without identification. This ensures accurate receipt information for self-order transactions, improving the customer experience and order accuracy.
Original PR description
When selecting a preset with a service at counter but without identification, after a self order the receipt header was wrongly showing "Service at Table" instead of "Pickup At Counter". This is now fixed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264115
This update corrects a bug where the 'Purchase Orders' button disappeared when changing an Analytic Account's plan. The fix adjusts how the system identifies purchase orders linked to analytic accounts, ensuring the button remains visible regardless of the plan setting. This ensures users can always access purchase order details based on their accounting setup.
Original PR description
# How to reproduce - Enable the analytic accounting in the settings - Create a PO - Add a PO line - Set the Analytic Distribution of that PO line to an Analytic Account of your choice - Confirm the…
# How to reproduce
- Enable the analytic accounting in the settings
- Create a PO
- Add a PO line
- Set the Analytic Distribution of that PO line to an Analytic Account of your choice
- Confirm the PO
- Create a Vendor Bill from that PO and confirm the VB
- Go to the Analytic Account chosen before
- Change the Plan of that Analytic Account
# The problem
When the Plan is not set to the "Project Plan", the Purchase Orders smart button disappears
# Why
The Purchases Orders smart button is invisible if the variable purchase_order_count is equal to 0. That field is computed by a function that does a search with the following domain :
```py
[('order_line.invoice_lines.analytic_line_ids.account_id', '=', account.id)]
```
When we change the Plan of the Analytic Account, analytic_line_ids.account_id is set to NULL, so the search return nothing.
Why is that field set to NULL ?
Well, to reference its plan, an Analytic Line does not use a python-defined field. In fact, each time a new Analytic Plan is added to the database, a new column is added to the Analytic Line model. That column's name is x_plan{plan.id}_id or, for the specific case of the "Project Plan", it is account_id
When the Plan of an Analytic Account is changed, it takes every Analytic Line associated with that Plan and switch which column containing the id of the Analytic Account.
Take for exemple the following Analytic Line :
```
(account_id = NULL, x_plan2_id = NULL, x_plan3_id = 1)
```
When the associated Analytic Account's Plan is changed to the "Project Plan", it becomes :
```
(account_id = 1, x_plan2_id = NULL, x_plan3_id = NULL)
```
So, we need to adapt to search so that it uses the right plan's name.
opw-5897037
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#263652
Forward-Port-Of: odoo/odoo#248236This update fixes a minor issue where some work entry names within the HR module were displaying incorrect spellings. The team corrected the data files to ensure accurate and consistent naming conventions, improving the overall user experience. This change was driven by a reported issue (opw-6090081).
Original PR description
Issue: ---------------------------------------- Some work entry names are wrong. Solution: ---------------------------------------- Change the data files. opw-6090081
This update fixes an issue where users without write access to the Fiskaly Point of Sale (PoS) module would receive an access error when attempting to authenticate with an expired token. The fix ensures that the correct error message is displayed, improving the user experience for AT companies using the Fiskaly integration.
Original PR description
When trying to auth directly from the PoS when the token expires, if you are logged in with a user that doesn't have write access to the PoS. You would get an access error. Steps to reproduce: ------------------- * Setup Fiskaly in an AT company * Open PoS and try to make a sale * To fake the token expiration I modified the code so that the request always return 401 status code > Observation: You get an access error opw-5925203 Forward-Port-Of: odoo/enterprise#112474
This update corrects a technical issue where an approval rule was being applied incorrectly due to a duplicate XML ID. By renaming the duplicate ID, we've ensured that approval rules are applied correctly based on user and manager roles, improving the reliability of the approval process. This resolves a potential inconsistency in how approvals were handled.
Original PR description
The XMLID `approval_approver_manager` was defined twice, causing the rule to be applied with the last evaluated access configuration for both `group_approval_user` and `group_approval_manager`. This commit renames the first occurrence of the duplicated XMLID to `approval_approver_user` to restore the intended separation between user-level and manager-level approval access rules. task-6095010 Forward-Port-Of: odoo/enterprise#113480
This update clarifies the Sale Order process for subcontracted products by hiding a confusing Manufacturing Order button. This prevents users from navigating to unnecessary back-end manufacturing details, streamlining the workflow managed through Purchase Orders and Subcontracting Receipts.
Original PR description
The Manufacturing Order (MO) smart button on a Sale Order is confusing when the product is subcontracted. In a subcontracting flow, the user manages the process via the Purchase Order and the Subcontracting Receipt. This commit ensures the MO smart button is hidden when the fulfillment is handled through subcontracting to prevent user confusion and unnecessary navigation to back-end manufacturing documents. Task-id: 6173877 Forward-Port-Of: odoo/odoo#263105
This update resolves an issue where Point of Sale orders would fail if a product used an archived unit of measure. We've now implemented a fix to load archived UOMs during the POS order process, ensuring accurate product handling and preventing order errors.
Original PR description
If a product uses an archived UOM and an order is then created in the POS with this product, an error would occur because it could result in trying to use a UOM that wasn't loaded in the POS since it was archived. To fix this issue, we now load archived UOMs in the POS. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6197465 Forward-Port-Of: odoo/odoo#264441 Forward-Port-Of: odoo/odoo#263838
This update resolves an issue that occurred when menus were deleted from the Odoo database. Specifically, the system would fail during a menu loading process. This change ensures the system continues to function correctly even after menus have been removed, improving stability and preventing potential disruptions.
Original PR description
to reproduce issue: 1) make a database in 18.3 . 2) delete the menu/menus. 3) it will fail on _load_menus_blacklist. 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#262824
This update resolves an issue where deleting menus in the Enterprise version of Odoo would cause a critical error. The fix ensures the system correctly handles the absence of menus, preventing a crash and maintaining stability. This improves the overall reliability of the Enterprise module.
Original PR description
to reproduce issue: 1) make a database in 18.3 . 2) delete the menu/menus. 3) it will fail on _load_menus_blacklist. Forward-Port-Of: odoo/enterprise#116498