Monday, May 4, 2026
12 changes · 19.0
Resolved issues and error corrections
This update fixes a restriction preventing users from deleting time off requests created after a payslip was validated. Previously, an error message blocked deletion, even if the time off wasn't impacting the payslip. This change ensures requests can be deleted regardless of payslip validation status, streamlining HR processes.
Original PR description
## Issue After confirming a payslip for a period, no time off request within that period can be deleted, even though requests are ont taken into account in the payslip if they are not approved. ##…
## Issue
After confirming a payslip for a period, no time off request within that period can be deleted, even though requests are ont taken into account in the payslip if they are not approved.
## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
- Contract: Jan 1 to Indefinite
- Wage: $1000/month
3. In Time Off > Management > Time off, create a new time off allocation for Employee E:
- Date: anywhere during March
- **Do not validate the time off**
4. In Payroll > Payslips, create a new Off-Cycle for Employee E:
- Period: March 1 - March 31
- *Compute Sheet*, *Confirm* and *Mark as paid*
5. Try to delete the allocation created in step 3
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_, even though the time off is not taken into account in the payslip.**
## Cause
The condition to raise the error message does not take into account the state of the leave:
https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_payroll_holidays/models/hr_leave.py#L195-L204
This commit completes https://github.com/odoo/enterprise/pull/114895, which was preventing the error from being raised when time off were generated after validating the payslip. The error should also not be raised for leaves that are not approved yet, as they did not impact the generation of the payslip.
(related to)
opw-6089990This update resolves an issue where the Swedish EC Sales Report (KVR export) was incorrectly displaying decimal values. The fix ensures that all sales report values are rounded to integers as required by Swedish reporting regulations, preventing data discrepancies and ensuring accurate financial reporting.
Original PR description
**PROBLEM** EC Sales Report in Sweden needs to be reported with integer values. **STEP TO REPRODUCE** 1. Install l10n_se 2. On the se company, create a invoice with lines with EU tax and confirm it. 3. Go to Accounting/Reporting/EC Sale List and export to KVR. 4. Notices the KVR uses numbers with decimals places. opw-6045289 Forward-Port-Of: odoo/enterprise#115459 Forward-Port-Of: odoo/enterprise#114292
This update resolves an issue where Amazon-related stock moves incorrectly displayed 'False' as their reference. The change updates the system to use the 'reference' field instead of 'name', ensuring accurate tracking of these moves within the Amazon integration. This prevents data discrepancies and improves the reliability of order fulfillment.
Original PR description
Issue ----- Commit d0c1e78 removed the `name` field of `stock.move`. Instead, we now use the `reference`field, which is computed in `_compute_reference` https://github.com/odoo/odoo/blob/2ec714b19e2c56bff965ab32f7e6a4485df2d247/addons/stock/models/stock_move.py#L357-L369 The problem is that there is no picking linked to the move, so `move.reference` is set to `False`. This means that, after we go through the override in `sale_amazon`, we end up with `Amazon move: False` https://github.com/odoo/enterprise/blob/596d8c1216b33c1f73feb8f60eef1b69a2164579/sale_amazon/models/stock_move.py#L10-L14 ----- Ticket: opw-5969357
This update resolves a bug in the Spanish BOE (mod347) export that incorrectly included certain invoices. Previously, invoices under €3,005.06 were causing the BOE to display incorrect partner information. This fix ensures that the BOE accurately reflects cash payments related to invoices, improving data accuracy for tax reporting.
Original PR description
Fix a bug in mod347 BOE export. Steps to reproduce: 1- Create an invoice with a spain Company, with an amount lower than 3 005,06€ 2- Add a Type for mod347 3- Create a cash payment 4- Export the mod347 BOE The partner will appear in the BOE with all line at 0. But this partner shouldn't be in the export. This is due because of a search on account.partial.reconcile, which add partners to the export if a cash payment is found in the period. But this search is not usefully as there is no legal indication that these partners should be in the export in this case, as the partners should only be returned by the main queries. Backport of PR #84317 opw-5960226 Forward-Port-Of: odoo/enterprise#114672 Forward-Port-Of: odoo/enterprise#110947
This update fixes an issue where helpdesk notification emails incorrectly linked to the company's default website instead of the customer's original website. Now, 'View Ticket' buttons in helpdesk emails always direct users to the website where their ticket was created, improving the user experience across multi-website setups. This ensures consistent and accurate ticket navigation.
Original PR description
On a multi-website / single-company setup, helpdesk notification emails posted after the initial confirmation contained a "View Ticket" button pointing to the wrong website, always the company's…
On a multi-website / single-company setup, helpdesk notification emails posted after the initial confirmation contained a "View Ticket" button pointing to the wrong website, always the company's default website instead of the website the ticket was created from. Steps to reproduce: =================== 1. Create two websites W1 (seq 1) and W2 (seq 2) under the same company, with distinct domains. 2. Create two helpdesk teams with "Submit a Ticket" enabled, each bound to one website (Helpdesk1 -> W1, Helpdesk2 -> W2). 3. From W2, submit a ticket on /helpdesk/helpdesk2. 4. In the ticket, send email from the chatter. 5. Inspect the outgoing notification email. => "View Ticket" button points to W1's domain. Root cause: ============ `helpdesk.ticket` has no `website_id`, so `Base.get_base_url` falls through to `company_id.website_id.domain`, i.e. the first website of the company by sequence. The first confirmation message looked right only because it was posted inside a website request, where `website.get_current_website()` provided the correct context; subsequent agent replies are posted from the ticket with no such context, so the fallback kicked in. Override `get_base_url` on `helpdesk.ticket` to prefer `team_id.website_id.domain` when set, so every notification on the ticket links back to the website the customer submitted it from. => "View Ticket" button points to W2's domain (the site the customer is browsing). opw-6071999
This update ensures that barcode validations during stock receipt creation correctly check if a destination has been scanned, even if a destination wasn't explicitly selected. Previously, the system didn't verify this, leading to potential issues. This change enhances the reliability of the barcode scanning process for stock management.
Original PR description
### Steps to reproduce: - In the settings: Enable "Storage Locations" - Inventory > Configuration > Warehouse Management > Operation Types - On receipts, in the Barcode App tab enable: "Force a…
### Steps to reproduce: - In the settings: Enable "Storage Locations" - Inventory > Configuration > Warehouse Management > Operation Types - On receipts, in the Barcode App tab enable: "Force a destination on all products" - Open the barcode app, create a new receipt - Scan a product > Validate #### > You are not blocked by the fact that you did not scan any destination even just to validate the default one ### Cause of the issue: The `barcode_validation_after_dest_location` operation type setting is not used at any point in the barcode app. ### Note: Line in the barcode app are always created a with a `location_dest_id`: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1310-L1322 In particular, even if the setting says: Force a destination on all products. It should rather be interpreted as force a destination scan before validation. Note that a destination scan will not necessarily update a single line but rather all concerned lines at once: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1558-L1576 It is therefore a valid call to check if a location dest was scanned to determine if the a destination was set on each product before validation of the picking, even if it is just to confirm the default destination. ### Note 2: We modify the `_get_barcode_config` to only provide a `barcode_validation_after_dest_location` if locations re enabled otherwise users enabling the option without the ability to scan locations would be soft lock and unable to validate their picking. That same logic already being applied to the `restrict_scan_dest_location` config parameter: https://github.com/odoo/enterprise/blob/6afe02e3e836df2822d7cae8aebbd5bdde6b34cc/stock_barcode/models/stock_picking_type.py#L109 opw-6110690 Forward-Port-Of: odoo/enterprise#115534 Forward-Port-Of: odoo/enterprise#114429
This update simplifies the process for Dutch companies to manage their digipoort certificates within the accounting settings. Previously, users had to navigate to a separate section to create a certificate before setting it. Now, users can directly create and edit certificates within the digipoort setting, improving usability and efficiency.
Original PR description
Description of the issue this commit addresses: In the Accounting settings on a Dutch company, the setting for the selection of the digipoort certificate only lets you choose amongst existing certificates so if you haven't created one yet, you need to go to the dedicated certificates menu to create one and then come back to the digipoort certificate setting to set it. This is poor UX. --- Desired behavior after this commit is merged: This is improved by letting the user Create and Edit inside the digipoort certificate setting directly. --- task-6065566 Forward-Port-Of: odoo/enterprise#115628 Forward-Port-Of: odoo/enterprise#114307
This update resolves an issue where users wouldn't be able to view equity information for partners associated with inaccessible companies. The change adds a 'company_id' field to equity models, allowing the system to correctly identify and display equity data for all partners, regardless of company access. This ensures accurate reporting and a smoother user experience.
Original PR description
Before this commit, if you had some holders only visible to a company you don't have access to, the cap table would show an access error. This commit introduces multi-company logic to equity models by adding a new company_id field related to the company_id of the partner_id. Other partners (holder, seller, subscriber) will have their companies checked against that company. task-6018771
This update prevents unauthorized users from viewing or modifying assets linked to invoices. Previously, users on lower-level access groups could access invoices with assets, leading to potential data access issues. Now, access is restricted to users within the ‘account.group_account_readonly’ or ‘account.group_account_invoice’ groups, enhancing security and data integrity.
Original PR description
Only groups `account.group_account_readonly`, `account.group_account_invoice` or higher have access to model `account.asset`, therefore if an user goes to see an invoice with assets and they are not on either group, they will receive an error and won't be able to access said invoice. How to reproduce: - Create a vendor bill - Create an account.asset and link it to said account.move - Go to the form view with an user that it's on group "Purchase: User" for example --> They get a traceback --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#113858 Forward-Port-Of: odoo/enterprise#112890
This update fixes an issue where Shopee account authorization was failing when a shop already existed. Now, the system correctly reuses authorization tokens to fetch access tokens for multiple shops associated with an account, streamlining the onboarding process for Shopee users. This ensures a smoother and more reliable experience when connecting multiple shops through a single Shopee account.
Original PR description
When authorizing a Shopee shop, a user has the choice to either connect to a Shopee Shop, or connect to a Shopee Account and grant access to multiple shops of the account. In the later scenario, the authorization code returned by Shopee OAuth should be used once to fetch the access tokens, and the tokens should be copied to all shops authorized by the account. However, when the shop already existed, the access token was fetched again, raising an error because the authorization code had already been used. opw-6166585
This update resolves a crash that occurred when sending invoices with attachments created via log notes. The fix prevents the system from incorrectly syncing orphaned attachment files, which caused versioning conflicts and data loss during the printing process. This ensures invoices print reliably and avoids data corruption.
Original PR description
Steps to reproduce: - Set a journal with documents folder sync. - Create and post a customer invoice. - Add an image attachment via a log note. - Click Send & Print. -> KeyError:…
Steps to reproduce: - Set a journal with documents folder sync. - Create and post a customer invoice. - Add an image attachment via a log note. - Click Send & Print. -> KeyError: `proforma_pdf_attachment` Cause: Adding an image via log note sets it as the main attachment, but it is intentionally orphaned (res_model=False) to prevent UI clutter. `documents_account` incorrectly syncs this unlinked file, creating a workspace document with a missing model. During "Send & Print", the official invoice PDF replaces the image as the main attachment. The document versioning logic intercepts this swap and attempts to re-parent the new PDF to match the orphaned document. This destroys the PDF's linkage to the invoice, causing a crash when the system later attempts to fetch the PDF. Solution: Since the base module now suppresses premature document creation during the message post, we explicitly handle the sync ourselves. We override `_fix_attachments_on_record_from_files_data` to iterate over the validated attachments and trigger document creation only for files that retained their `res_model`. We also add a check inside `_update_or_create_document` to strictly block orphaned attachments. opw-5930888 Forward-Port-Of: odoo/enterprise#115065
This update optimizes appointment scheduling by calculating availability only for the currently displayed month, rather than pre-computing all slots. This change significantly reduces server load and improves the responsiveness of the appointment booking process, leading to a smoother user experience. It addresses a performance bottleneck related to handling extended booking periods.
Original PR description
Generate all slots and compute only availabilities for the display month instead of pre-computing all slots for the whole booking period. task-4144524