Thursday, July 2, 2026
39 changes · saas-19.3
Enhancements to existing features
This change removes technical e-reporting fields from the standard invoice screen to make invoicing simpler and less cluttered for users. The relevant status, flow, and blocking error information is now available in the invoice chatter, with a direct link to the related flow, and address validation warnings are no longer shown for B2C invoices when they are not needed.
Original PR description
E-reporting technical fields were displayed directly on invoices, adding noise for regular invoicing users. Hide the e-reporting status columns and technical block from the standard invoice views. Log the relevant e-reporting flow, status and blocking errors in the invoice chatter instead, with a link to the related flow. Also avoid reporting address validation errors on B2C invoices, as they are not required for Flux 10 e-reporting. Task-6273226 Forward-Port-Of: odoo/odoo#271865
Resolved issues and error corrections
This fix prevents invoice notifications from crashing when they are sent in a different language than the one used while creating the invoice. It ensures Quick Edit invoice confirmations render properly for customers and users, avoiding failed notifications and interrupted workflows.
Original PR description
**Steps to Reproduce:** - Install the Accounting and Contacts modules. - Enable Quick Encoding for Customer Invoices and Vendor Bills in the company settings. - Create a new customer: Assign a…
**Steps to Reproduce:**
- Install the Accounting and Contacts modules.
- Enable Quick Encoding for Customer Invoices and Vendor Bills in the company
settings.
- Create a new customer: Assign a salesperson.
- Ensure:
- The salesperson is not a login user.
- The customer language, salesperson's language, and Login user's language
are different. Example:
- Customer language: English
- Salesperson language: French
- Login user language: French
- Create a customer invoice using the Upload Document functionality.
- Select the customer created above.
- Use Quick Edit mode and enter an amount and Click Confirm.
**Issue:**
- When the invoice notification is rendered in a language different from the one
used during the write operation, the notification rendering flow calls
_notify_by_email_prepare_rendering_context().
- During rendering, the code executes:
```
self.tax_totals.get('total_amount_currency', 0)
```
- Since tax_totals is protected, the ORM returns False instead of the expected
dictionary, leading to:
```
AttributeError: 'bool' object has no attribute 'get'
```
**Root Cause:**
- This issue occurs in Quick Edit mode because tax_totals is [not read-only](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/views/account_move_views.xml#L1359)
in Quick Edit mode and is included in [the values](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/web/static/src/model/relational_model/record.js#L708) sent by the web client during write().
- During create()/write(), _get_protected_vals() marks tax_totals as protected.
- Since tax_totals is a [@api.depends_context('lang')](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/models/account_move.py#L975) computed field, it
maintains a separate cache per language. [During write()](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/models/account_move.py#L3955), the [field becomes
protected](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/models/account_move.py#L3863) by [env.protecting()](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/odoo/orm/fields.py#L1738). While the protection is still active, the mail
notification flow renders the email using the recipient's language. If the
corresponding language-specific cache entry for tax_totals is not available,
the ORM cannot recompute the protected field and returns False instead
of the expected dictionary.
- The rendering code assumes tax_totals is always a dictionary and directly
calls .get(), leading to the crash.
**Solution:**
- Exclude tax_totals from _get_protected_vals().
- tax_totals is already handled explicitly after create()/write(), so protecting
it is unnecessary. This allows the field to be recomputed during notification
rendering when required.
**Result:**
- Invoice notifications render correctly in all languages.
- No RPC crash occurs when rendering notifications after Quick Edit.
**Runbot reproduction: [video](https://github.com/user-attachments/assets/5f045efb-37de-40aa-b135-1368b1601d61)**
**opw-6209647**
Forward-Port-Of: odoo/odoo#266335This fix avoids an error that could appear when a user removes the currency while registering a payment. It keeps the payment flow working smoothly in the Argentine withholding setup and prevents an unexpected interruption.
Original PR description
When the user removes the currency from the payment register, a traceback is raised. Steps to reproduce the error: - Install ``l10n_ar_withholding`` module - Switch to ``(AR) Exento`` company - Create a new invoice > Confirm > Pay > Unset the currency Traceback: ```py ValueError: Expected singleton: res.currency() ``` https://github.com/odoo/odoo/blob/d98afdc08b46bf458eaa287ea882cc7663286a59/addons/l10n_ar_withholding/wizards/account_payment_register.py#L27 This line causes a traceback with an empty currency when the user removes the currency from the payment register. sentry-7362499567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272891 Forward-Port-Of: odoo/odoo#255825
Fixed an issue where new employee document folders were being created in a user's personal drive instead of the company’s main folder. This keeps employee folders organized in the correct company location and makes them easier to find and manage.
Original PR description
Steps to reproduce =================== - Install documents_hr. - Log in with admin. - Create a new company `Test`. - Go to Document and choose the new company (top right). - Go to `My Drive`: a folder named `Employees - Test` has been created. This new folder should be created in the `Company` root instead of the `My Drive,` which will hold all the employee folders. Technical =========== When the main employee folder is created via `_generate_employee_documents_main_folders` `owner_id` falls back to the current user, which leads to computing the `user_folder_id` as `My drive,` and so that's why the newly created folder starts appearing there instead of the `Company` root. This PR addresses the issue and sets the `owner_id` to False, which leads to show the main employee folder in the company root. Task-6267352 Forward-Port-Of: odoo/enterprise#120677
This change prevents an access error that could block delivery validation when a user can manage inventory but only sees their own sales documents. The system now checks the related subscription status in a safer way, so deliveries can be completed without exposing additional sales data or changing the existing business rules.
Original PR description
## **Issue:** When validating a delivery, users with Sales: Own Documents Only and Inventory Administrator access rights can encounter an access error if the delivery belongs to a sale order owned by…
## **Issue:** When validating a delivery, users with Sales: Own Documents Only and Inventory Administrator access rights can encounter an access error if the delivery belongs to a sale order owned by another salesperson. ## **Steps to reproduce:** - Install sale_subscription_stock. - Create a user with Sales: Own Documents Only and Inventory Administrator access rights. - Create a sale order as another user. - Validate the delivery with the restricted user. ## **Solution:** During _action_done(), [This line](https://github.com/odoo/enterprise/blob/19.0/sale_subscription_stock/models/stock_picking.py#L45) is checking subscription_state. Since the user does not have read access to the sale order, reading this field raises an access error and prevents the delivery from being validated. As the method only needs to read the subscription state, access the field with sudo() to avoid the unnecessary access error while preserving the existing business logic. Runbot Video : [Video](https://drive.google.com/file/d/1d7U2jTCxaaVk2YJcy3bi2SlYuT-yXMsu/view?usp=drive_link) OPW - 6295712 Forward-Port-Of: odoo/enterprise#122420
This change prevents an error that could appear when opening the Stock report after the Manufacturing app had been removed. It restores the report settings to a safe default during uninstall, so users can continue accessing stock reporting normally.
Original PR description
Currently an error occurs when user opens stock report after uninstalling mrp. Steps to replicate: - Install mrp. - Uninstall mrp and open `Stock > Reporting > Stock`. Error: ``` ValueError: Invalid…
Currently an error occurs when user opens stock report after uninstalling mrp.
Steps to replicate:
- Install mrp.
- Uninstall mrp and open `Stock > Reporting > Stock`.
Error:
```
ValueError: Invalid field product.product.is_kits in condition ('is_kits', '=', False)
```
Cause:
- The `mrp` module overrides the `stock.action_product_stock_view` window action domain with `is_kits` field referenced inside [1].
- When mrp is uninstalled, the `is_kits` field is removed from `product.product` but the overridden action domain remains stored in the database. Opening the action then tries to evaluate a domain referencing a non-existent field, resulting in this error.
Solution:
- Restore the original `stock.action_product_stock_view` domain during mrp uninstallation to remove the `is_kits` condition.
[1]: https://github.com/odoo/odoo/blob/c8390638cae4b4dafb805bc0d3a4149fb5194934/addons/mrp/views/product_views.xml#L164-L166
sentry-7332688253
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#269512This change corrects a rounding issue that could make overtime time entries overlap by a few seconds, especially around midnight. It now orders the entries more reliably and prevents one interval from starting before the previous one has finished, improving the accuracy of attendance and payroll data.
Original PR description
__Issue:__ `duration` is rounded to 3 decimals (~1.8s drift) while `time_stop` is exact, so the back-projected start could land before midnight on overnight overtime or middle of the day causing overlaps with the previous line Example: - time_start = 03/05 00:00:00 - time_stop = 03/05 07:07:14 actual duration 7h07m14s gets stored as `duration = 7.121` (= 7h07m15.6s) after `round(_, 3)`. Back-projection yields `datetime_start = 07:07:14 - 7.121h = 02/05 23:59:58`, overlapping by ~2s with the prior line ending at `02/05 23:59:59.999`. __Fix:__ Sort lines by `time_stop` within each date and clamp `datetime_start` to the previously emitted interval's stop when the two intervals genuinely intersect. opw-6170828 Forward-Port-Of: odoo/enterprise#121564 Forward-Port-Of: odoo/enterprise#116565
PDF generation for certain Guatemala vendor bills could fail with an error, preventing users from downloading the document. This update corrects the data setup and template reference so the PDF can be generated successfully again.
Original PR description
**Steps to reproduce:** - Install the `l10n_gt_edi` module and switch to a `GT Company`. - Create a new vendor bill with: - Vendor: GT Company - GT Document Type: `FESP` - Add taxes `VAT Withholding…
**Steps to reproduce:** - Install the `l10n_gt_edi` module and switch to a `GT Company`. - Create a new vendor bill with: - Vendor: GT Company - GT Document Type: `FESP` - Add taxes `VAT Withholding 12%` and `ISR Withholding 5%` in Invoice lines. - `Confirm` the bill and `Send to SAT`. - From the gear icon, click `Download` > `PDF`. **Error1:** `KeyError: 'gran_total'` **Error2:** `KeyError: 'retencion_grand_total'` **Root Cause:** In commit [1], the code at [2] missed calling `_l10n_gt_edi_add_base_values()` before `_l10n_gt_edi_add_withholding_values()`. However, `_l10n_gt_edi_add_withholding_values()` uses the `gran_total` value, which is initialized by `_l10n_gt_edi_add_base_values()`, resulting in a `KeyError`. Additionally, the report template at [3] references `retencion_grand_total` instead of the correct key `retencion_gran_total`, causing another `KeyError`. **Fix:** This commit prevents errors and ensures users can successfully download the PDF by applying a fix similar to [4], [1]: https://github.com/odoo/enterprise/commit/44afd19e4ed0827e343af0e584c81e579935c9e8 [2]: https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/models/account_move.py#L305-L328 [3]: https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/views/report_invoice.xml#L72 [4]: https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/models/account_move.py#L790-L800 opw-6323049 Forward-Port-Of: odoo/enterprise#122398 Forward-Port-Of: odoo/enterprise#122030
This change prevents the system from crashing when a session entry is missing an expected trust flag. It improves stability for affected devices and sessions by handling incomplete data safely instead of failing.
Original PR description
Some devices may not have a `trusted` key in their entry. This is the case for sessions created between these two commits: - https://github.com/odoo/odoo/commit/b6c2aafae2112ef98edca8a7f027716d9c15be11 - https://github.com/odoo/odoo/commit/61f22175ef3df37087887e7419dac54a620bbd55 Task-6348650 Forward-Port-Of: odoo/odoo#273062
This update prevents manually entered timesheet details from disappearing when users close the Timesheets systray after saving or resetting an entry. It helps ensure the description, project, and task they entered are kept and shown again later, reducing user frustration and rework.
Original PR description
## Issue When using the Timesheets systray, if we set a project after clicking the *Save* or *Reset* button, the project is not saved after closing the systray. ## Steps to reproduce 1. Install…
## Issue When using the Timesheets systray, if we set a project after clicking the *Save* or *Reset* button, the project is not saved after closing the systray. ## Steps to reproduce 1. Install *Timesheets* (`timesheet_grid`) 2. Open the Timesheets systray 3. Click *Reset* and set a description, a project and/or a task, then close the systray 4. Open the systray again 5. **The description/project/task set in step 3 do(es) not appear anymore.** ## Cause Commit https://github.com/odoo/enterprise/commit/b9b7f8a0acf7a1c545c6613cf8bbc29871632e26 introduced the `preventUnmountSave` attribute. The attribute is set to `true` after saving and discarding an entry. When the systray is unMounted, the manual values (e.g., description, project and task) are not saved if the attribute is set to `true`: https://github.com/odoo/enterprise/blob/7cd8dd008eb88d6c12f3e65fb8d311058290a301/timesheet_grid/static/src/components/timesheet_timer_inline_form/timesheet_timer_inline_form.js#L171-L174 ## Fix After discussing with the author of the previous commit, it appears this was done to prevent an issue with values stored in cache, but that issue does not seem to occur anymore, which leads to believe that the attribute is not required anymore. opw-6284016 Forward-Port-Of: odoo/enterprise#121605
This update prevents the editor menu from opening when an emoji shortcut is typed and converted into an emoji. It also makes emoji shortcuts work more reliably within a paragraph, so users can insert emojis without unexpected interruptions.
Original PR description
#### Description of the issue this PR addresses: - When an emoji shortcut ending with `/` (e.g. `:/` for 😕) is typed, the emoji plugin replaces the characters before the powerbox `on_input_handler`…
#### Description of the issue this PR addresses: - When an emoji shortcut ending with `/` (e.g. `:/` for 😕) is typed, the emoji plugin replaces the characters before the powerbox `on_input_handler` runs. Since `ev.data` still reflects the original typed `/`, the powerbox was incorrectly opening. - Emoji shortcuts works only when it is used at the end of a text node, because the matching logic checked the whole remaining substring from the current position. - Sometimes, pressing Backspace splits one text node into two, and then an emoji shortcut works at the end of the first text node even when the paragraph is visible as a single line. #### Desired behavior after PR is merged: - Check the DOM character at cursor position instead of `ev.data` to determine whether `/` is actually present before opening the powerbox. - Emoji shortcuts now works when used with a preceding space anywhere in the paragraph. Enterprise PR-https://github.com/odoo/enterprise/pull/118310 task-6243724 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266284
The attendance overtime calculation now includes all work periods that overlap the updated day, even when an attendance crosses midnight. This prevents overtime from being undercounted in cases where a later attendance was previously calculated without taking earlier overlapping hours into account.
Original PR description
Issue: ---------------------------------------- The overtime calculation ignores attendances overlapping midnight when creating an attendance on the day they overlap. Steps to reproduce:…
Issue:
----------------------------------------
The overtime calculation ignores attendances overlapping midnight when creating an attendance on the day they overlap.
Steps to reproduce:
----------------------------------------
- Have the standard 8 hours per day working schedule
- Use the default overtime ruleset:
- Quantity, per day, more than the contract
- Have no rule on weeks
- Create an attendance of 8+ hours overlapping midnight on a day:
- From 10pm to 10am (2h + 10h = 12h)
- Create another attendance on the day the first ended:
- From 2pm to 6pm (4h)
- The first attendance has 2h of overtime:
- 0h from the first worked day (from 10pm to midnight = 2 < 8)
- 2h on the next day (10h worked from midnight to 10am)
- The second attendance have 0h of overtime even though it should be 4h
- We only considered this attendance in the calculation, ignoring the 10h worked in the morning
Cause:
----------------------------------------
In `_update_overtime()` we create a domain to include all useful attendances in the calculation. As all rules are based on days, the domain will use the date of the attendance to get overlapping attendances. But the date of the attendance is the date of its `check_in` ([src](https://github.com/odoo/odoo/blob/4235b48c86077bd5bceb9e817cc45b2eec8697e8/addons/hr_attendance/models/hr_attendance.py#L91)). So when creating the second attendance, the domain only fetches attendance with their `date` on the same date as the `check_in` of the second one. This excludes the first one even though it overlaps on the same day.
Solution:
----------------------------------------
Don't use `date` but `check_in` and `check_out` in the domain to really get all attendances overlapping a day with an updated attendance.
As this domain was used on both `hr.attendance` and `hr.attendance.overtime.line`, we adapt it so it uses the correct fields (`time_start` and `time_stop`) from the overtime lines.
opw-6253777
Forward-Port-Of: odoo/odoo#272447This fix ensures the Italian withholding tax return is calculated independently from the regular tax return. As a result, the amount due on a withholding return no longer incorrectly includes balances from other tax returns, preventing wrong payment amounts.
Original PR description
Steps to reproduce: - setup an Italian company - make an invoice (for example in May) with a withholding tax and make a transaction to pay it - generate tax returns (opening date in June so that it generates from May) - validate regular tax return for May - validate withholding tax return for May -> The withholding tax return shows an amount to pay with a balance that is a combination of both the regular tax return and the withholding one, while it should be independent of the regular one. task-6116304 Forward-Port-Of: odoo/enterprise#121254 Forward-Port-Of: odoo/enterprise#119375
This fix adds descriptive alternative text to language flag images when the website language selector shows flags without text. It improves accessibility for screen readers and gives search engines the context they need to understand the language options.
Original PR description
Steps to reproduce: 1. Enable the language selector in the website header. 2. Enable the "Inline" and "Flag" options. 3. Inspect the flag images rendered in the inline variant. Issue: Flag images in the list items have an empty `alt=""` attribute in "Flag only" mode, where the flag is the sole visual indicator of the language, making the selector inaccessible to screen readers and providing no context for search crawlers. Expected behavior: Inline + Flag should have a descriptive ALT tag since there is no adjacent text or code to identify the language, the flag is not decorative. opw-6246464 Forward-Port-Of: odoo/odoo#273025 Forward-Port-Of: odoo/odoo#271362
This change prevents the accounting automation from marking work as complete when an unexpected error occurs. As a result, failed items are less likely to be skipped silently, improving the reliability of scheduled posting tasks.
Original PR description
The previous fix commits progress even when an unexpected exception escaped the loop iteration when _autopost_draft_entries. Now progress is only committed on success or when a UserError is explicitly handled. Reference: https://github.com/odoo/odoo/pull/271509 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273115
Public links for shared audio files will no longer try to play in the browser preview. This avoids Chrome-specific preview failures and keeps the sharing experience consistent by downloading the file instead of exposing it as streaming media.
Original PR description
**Steps to reproduce:** - Install Documents app - Upload a sound file (mp3 for example, but the behavior is the same for other formats) - Share the document and copy the link - Log out - Paste the…
**Steps to reproduce:**
- Install Documents app
- Upload a sound file (mp3 for example, but the
behavior is the same for other formats)
- Share the document and copy the link
- Log out
- Paste the link
- Click on preview button
- Media is working fine on Firefox
- Media won't read on Chrome
```
Loading media from '' violates the following Content Security Policy directive: "default-src 'none'".
Note that 'media-src' was not explicitly set, so 'default-src' is used as a fallback.
The action has been blocked.
```
**Issue:**
Since [1] default CSP Headers are too strict for Chrome default media rendering, which breaks the file preview (and force user download).
This only impacts Chrome as they seem to render generate `<video><source>` elements to render the file which triggers a secondary request and fails due to the CSP constraint.
**Fix:**
Could re-apply the header fix of 17.4 (see [2]), but it seems better to block the preview of audio files as well by default (to match how we manage videos).
(Note: we don't want to be used as a media streaming platform)
[1] (set csp to none by default) https://github.com/odoo/odoo/commit/64beb80205dffe4b432c8b5813a3271b073fa85e
[2] (similar issue which was not fixed in 18.0+) https://github.com/odoo/enterprise/commit/a7af78eeb2b9763045a5bda8714172f5e7402df8
[3] (mp4 preview removed) https://github.com/odoo/enterprise/commit/ea88cf7c6d5f077b60fb59347659507fded0e2fe
opw-6235043
Forward-Port-Of: odoo/enterprise#119644Fixed an issue that could prevent POS managers from saving changes to a POS configuration when self-order images had been uploaded by someone else. This removes an unnecessary access error so teams can manage POS setups without needing Settings or Admin rights.
Original PR description
When editing a POS config, `_ensure_public_attachments` wrote `public=True` on the self-ordering background/home images on every write. These images are Many2many attachments created with a `res_model` but no `res_id`, so the attachment access check denies write to any non-system user who is not their creator.
As a result, a POS manager without Settings/Admin rights could not edit a config whose images were uploaded by another user (e.g. an admin during setup), getting:
AccessError: Sorry, you are not allowed to access this document.
(Operation: write) - Records: ir.attachment(...), User: ...
Steps to reproduce:
1. Enable self-ordering on a POS and select a background image
2. Set self-ordering back to disabled
3. Log in as a POS admin without Admin/Settings rights
4. Try to edit the POS -> error
opw-6331261
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#273299This update corrects the GSTR-1 export for SEZ invoices issued in foreign currency so the invoice value is shown in the company currency, INR, instead of the foreign currency amount. This helps ensure the GST return spreadsheet reflects the proper values for filing and reporting.
Original PR description
Currently, when generatign GSTR-1 return spreadshee, SEZ invoices issued in a foreign currency are exported with their totals in the foreign currency rather than the company currency (INR) Steps to reproduce: - Create a B2B SEZ invoice in foreign currency - Go to Accounting > Reporting > [India] GST Return periods - Generate the GSTR-1 report for the period Issue: In the resulting spreadsheet, the "Invoice Value" column takes the invoice total in USD rather then INR opw-6292913 Forward-Port-Of: odoo/enterprise#121972 Forward-Port-Of: odoo/enterprise#121157
This update fixes two manufacturing issues that could block production completion in certain multi-step and split-order scenarios. It ensures expected component quantities are correctly taken into account even when reservations are missing, and prevents an invalid negative reservation error when generating serial numbers on split manufacturing orders.
Original PR description
### Steps to reproduce: - In the settings enable: Multi-Steps Routes - Set your warehouse to manufacture in 2 steps (pick then manufacture). - Create a final product (FP) with a BOM in flexible…
### Steps to reproduce: - In the settings enable: Multi-Steps Routes - Set your warehouse to manufacture in 2 steps (pick then manufacture). - Create a final product (FP) with a BOM in flexible consumption: - 1 x COMP (lot tracked) - Create and confirm an MO for 1 units of FP - Set the quantity producing on the MO to 1 > The consumed qty was updated to 1 unit - Set a lot on the pre-production pikcing and validate #### > The lot is not transfered to the MO which you are not able to validate since the registered component is lot less ### Cause of the issue: The issue is caused by https://github.com/odoo/odoo/commit/3223deb871ca4cb4ac0381e4321f2dbf79a60189 as the `qty_waiting` is based on the reservation state of the move origin of the move rather than its actual demand: https://github.com/odoo/odoo/blob/00118002bd6eab2f4c34a32e993a9219fded06ac/addons/mrp/models/mrp_production.py#L1419-L1426 In particular, since the backorder of the pre-production picking was not reserved (since nothing was available in stock), it was not taken into account as it should have been. Issue 2: Steps to reproduce: - In the settings Enable Multi-Steps Routes - Unarchive MTO - Create 3 products: - Final Product: Tracked by SN with a BOM: 1 X Super Component - Super Component: Tracked by SN, MTO with a BOM: 1 X Component - Basic Component: Put 10 units in stock - Create and confirm an MO for 3 units of Final Product > This should create an MO for 3 units of Super Component - Go to the Child MO > Cogs wheel > Split in 3 MO's - Click "Generate serial" on each Child MO and validate the first one - On the MO for Final Product > Cogs wheel > Split in 3 MO's - On the first MO, click "Generate Serial" > Error: Reserving a negative quantity is not allowed. ### Cause of the issue: The `action_generate_serial` calls in turn the `set_qty_producing`: https://github.com/odoo/odoo/blob/9fac1400fe5a8e665732c2ee3701c17c3495318f/addons/mrp/models/mrp_production.py#L1601 However, since the main MO was split the Super component demand is of 1 but each child MO provide an origin quantity of 1 so that the `new_qty` will be set to a negative one here: https://github.com/odoo/odoo/blob/9fac1400fe5a8e665732c2ee3701c17c3495318f/addons/mrp/models/mrp_production.py#L1418-L1426 But, since the first child MO was validated, there is already a move line associated to the Super component move and the `_set_quantity_done` will therefore try to adapt the reservation to a negative quantity which leads to the error: https://github.com/odoo/odoo/blob/9fac1400fe5a8e665732c2ee3701c17c3495318f/addons/stock/models/stock_move_line.py#L469-L470 opw-6128575 opw-6317083 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273168 Forward-Port-Of: odoo/odoo#271123
This update resolves issues with the loyalty program module, ensuring new invoices correctly award points based on defined rules. Previously, the system defaulted to a flat point amount and incorrectly invoiced negative amounts when loyalty points were exhausted. This fix improves the accuracy and reliability of the loyalty program for our subscription customers.
Original PR description
This commit fixes the following problems in the new module: - New invoices sometimes could not grant points according to the specified rules. - The reward point mode was not being taken into account and was giving a flat amount of points. - Reward lines were being invoiced with a negative amount when there was no more points in the loyalty card. - The 'Recurring' option in conditional rules and reward were not showing sometimes for an unknown reason. task-6153127
This update prevents the preparation display from crashing when a customized product line is deleted in the PoS. Previously, deleting a line with a custom attribute value caused a blank screen, disrupting order processing. The fix ensures the display remains functional by gracefully handling the removal of the associated order line.
Original PR description
When an order is sent to the preparation display and one of its products has an attribute with a custom (free text) value, completely deleting that line in the PoS makes the whole preparation display…
When an order is sent to the preparation display and one of its products has an attribute with a custom (free text) value, completely deleting that line in the PoS makes the whole preparation display crash and show a blank white screen, so the kitchen can no longer see any order. Steps to reproduce: ------------------- * Configure a PoS product with an attribute whose variant that has a custom (free text) value. * In the PoS, add the product, select that attribute value and send the order to the preparation display. * Back in the PoS, completely delete that order line (do not just set its quantity to 0) and send the order to the preparation display again. > Observation: The preparation display crashes and only a white screen is shown. The browser console reports "TypeError: Cannot read properties of undefined (reading 'id')". Why the fix: ------------ Completely deleting the line deletes the source pos.order.line, so the preparation line that is still displayed no longer resolves its `pos_order_line_id`. While building the attributes to display, the orderline component dereferenced `.id` on that (now undefined) relation, as well as on the related custom value records, which threw and brought down the whole preparation display instead of only that line. We now guard those relations: when the originating order line is gone, the unresolvable custom value is simply dropped and the attribute is still shown, keeping the preparation display alive. opw-6282607
This change reverts recent updates that allowed employees to directly edit personal information like marital status. Management requested this to mitigate risks to payroll accuracy and compliance, as this data impacts tax deductions and benefits. HR will now maintain this information to ensure data integrity and legal documentation.
Original PR description
This reverts the recent changes that exposed the "Family" and "Personal Info" sections (such as Marital Status) in the employee's "My Preferences" menu. While the initial addition was intended to improve employee self-service, management requested this revert because allowing employees to directly edit these fields poses a risk to payroll accuracy and compliance. Data points like marital status or family dependents directly impact tax deductions and benefit enrollments. To ensure data integrity, any modifications to payroll-affecting information must remain the exclusive duty of the HR team, who can require and verify the proper legal documentation before updating the system. task-6304031 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update reverts a recent change that allowed employees to directly edit sensitive payroll information like marital status. This change was removed due to concerns about potential inaccuracies impacting tax calculations and compliance. HR will now maintain all payroll-related data to ensure accuracy and adherence to regulations.
Original PR description
This reverts the recent changes that exposed the "Family" and "Personal Info" sections (such as Marital Status) in the employee's "My Preferences" menu. While the initial addition was intended to improve employee self-service, management requested this revert because allowing employees to directly edit these fields poses a risk to payroll accuracy and compliance. Data points like marital status or family dependents directly impact tax deductions and benefit enrollments. To ensure data integrity, any modifications to payroll-affecting information must remain the exclusive duty of the HR team, who can require and verify the proper legal documentation before updating the system. task-6304031
This update fixes an issue where customer names weren't being correctly populated when booking appointments through Google Reserve with Google. Now, customer names (first and last) from the Google booking are accurately displayed in Odoo, improving the user experience and ensuring accurate contact information for appointments.
Original PR description
When a customer books through Reserve with Google, the createBooking payload carries the booker given_name and family_name next to the email, but the handler passed only the normalized email to…
When a customer books through Reserve with Google, the createBooking payload carries the booker given_name and family_name next to the email, but the handler passed only the normalized email to _mail_find_partner_from_emails. The new res.partner was therefore created with its name falling back to the email, see https://github.com/odoo/odoo/blob/aa7b5921191a0ff53ef1cc32af99fe458c45c0da/addons/mail/models/res_partner.py#L177 That name then flows into the calendar.event name, the attendee common_name and the contact details, all showing the email instead of the customer name. The module has read neither field since it was added in https://github.com/odoo/enterprise/commit/2e855b910173b56e8501d0ebe9ee6f83ac5845bc. Build the booker name from given_name and family_name and pass it with the email through formataddr in google_reserve_booking_create, so a newly created partner is named after the customer. A partner matched on an existing email keeps its current name. Steps to reproduce: 1. Enable Reserve with Google on an appointment type. 2. Book a slot from Google Maps with given name John and family name Doe. 3. Open the created booking and its contact in Odoo. => the contact name is the email instead of John Doe Ticket [link](https://www.odoo.com/odoo/project/49/tasks/6232318) opw-6232318 Forward-Port-Of: odoo/enterprise#120604
This update resolves an issue where users could select customers from different companies within the Helpdesk module. The fix adds a restriction to the customer dropdown, ensuring users only see customers from their own company. This prevents data inconsistencies and improves the accuracy of Helpdesk ticket management.
Original PR description
Steps to reproduce: - Create two companies (Company A and Company B) - Create one partner in each company - Enable both companies for the user - Open Helpdesk and go to the tickets Kanban view for a Company A team. - In the quick create form, the customer dropdown shows customers from Company B Issue: - Customers from other companies are visible in the customer field, Cause: - The partner_id field in the quick create view had no domain, so it displayed partners from all allowed companies. Solution: - Added a domain on partner_id in the ticket quick create form view. task-4971466 Forward-Port-Of: odoo/enterprise#122358 Forward-Port-Of: odoo/enterprise#121944
This update fixes an issue where flexible employee schedules were incorrectly calculating weekly hours, leading to inaccurate hour projections. By aligning the week start day with the user's locale setting (e.g., Sunday instead of Monday), the system now accurately reflects the employee's available work hours, ensuring accurate planning.
Original PR description
**Steps to reproduce** - Install planning - Switch to English (UK) and change the "First day of the week" to Sunday in the technical settings - Have an employee with a flexible schedule with a total of 40h/week, average 8h/day - In the planning app, after creating a shift to display the employee in the gantt view, notice that when hovering over the progress bar on the left, 48 worked hours are expected for the current week, which is more than what is defined in the employee's calendar **Cause** The displayed week, starting on Sunday, could accumulate more hours than the weekly cap due to the Sunday being part of another week with the locale default first day (Monday). opw-6110395 Forward-Port-Of: odoo/odoo#272900 Forward-Port-Of: odoo/odoo#259600
This update fixes an issue where splitting a restaurant order didn't correctly carry over the original order's fiscal position and pricelist to the new order. Now, when an order is split, the new order inherits the correct tax settings and pricing rules, ensuring accurate financial reporting and customer billing. This improves order accuracy and reduces potential errors.
Original PR description
When splitting an order, the new order was created without the original's fiscal position and pricelist, so its lines fell back to the default taxes Steps to reproduce: 1. Create a fiscal position with some tax mapping 2. Create a pricelist with some price rules 3. Add the fiscal position and pricelist to the delivery preset 4. Create a restaurant order as delivery 5. Split the order 6. Pay both of them 7. First order will have the default taxes and prices list instead of preset's ones Part of: https://github.com/odoo/odoo/pull/268862 -opw-6246434 Forward-Port-Of: odoo/odoo#273174 Forward-Port-Of: odoo/odoo#272837
This update fixes a potential issue where users could refund an order line more times than allowed, leading to inaccurate financial reporting. The change now ensures that refunds are limited to the original amount refundable, improving the reliability of point-of-sale transactions. This resolves a previous vulnerability (opw-6340931) and protects against financial discrepancies.
Original PR description
Before this commit, if an order line was already refunded, it was possible to refund it again. opw-6340931 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272408
This update corrects a bug where quality checks remained active after merging multiple Manufacturing Orders. Previously, the merge process didn't trigger the standard cleanup, leading to unnecessary quality check entries. This fix ensures that pending quality checks are automatically removed when Manufacturing Orders are merged, streamlining the workflow.
Original PR description
Version: -------- - 18.0+ Steps to reproduce: ------------------- - Install `quality_mrp` - Create a manufactured product with a BoM - Create a Quality Point for the `Manufacturing` operation of that…
Version: -------- - 18.0+ Steps to reproduce: ------------------- - Install `quality_mrp` - Create a manufactured product with a BoM - Create a Quality Point for the `Manufacturing` operation of that product - Create and confirm multiple Manufacturing Orders - Verify that each MO generates a quality check - From the MO list view, select the MOs and merge them from the gear menu(merge) Issue: ------ When Manufacturing Orders are merged, All MOs are cancelled but it keep their quality checks in the 'To Do' state. As a result: - The quality checks remain linked to cancelled MOs - The 'Quality Checks' smart button is still displayed on cancelled MOs Expected behavior: ------------------ - Pending quality checks should be deleted when the MO is cancelled - The 'Quality Checks' smart button should no longer be displayed Cause: ------ A previous fix introduced logic to remove pending quality checks when a Manufacturing Order is cancelled: odoo-dev@db93bd2 This logic was implemented in `action_cancel()` by unlinking quality checks associated with the cancelled MO: https://github.com/odoo/enterprise/blob/20bc0eb5c2cec67eecd3b44450934e23370b48f2/quality_mrp/models/mrp_production.py#L94-L97 However, when MOs are merged, the merge flow does not call `action_cancel()`. Instead, it directly invokes `_action_cancel()` on the source Manufacturing Orders: https://github.com/odoo/odoo/blob/aca0b7289c68fc7a75d47ab313f5f791ebf30f7d/addons/mrp/models/mrp_production.py#L2480 Since the quality check cleanup is implemented only in `action_cancel()`, it is bypassed during the merge process. As a result, the source MOs are cancelled but their pending quality checks remain in place. --- opw-6260735 Forward-Port-Of: odoo/enterprise#121809 Forward-Port-Of: odoo/enterprise#119525
This update fixes an issue where refund discounts were incorrectly calculated in the sales details report. Previously, refunds inflated discount amounts instead of canceling them, leading to inaccurate reporting. This change ensures refunds are properly accounted for, providing a more reliable view of sales discounts.
Original PR description
The sales details report computes a line discount as `original_price - price_subtotal_incl`. On a refund line the quantity is negative, so `original_price` is negative, while `price_subtotal_incl` is stored positive. Subtracting the two then inflates the discount instead of cancelling it, understating "discount_amount" by `2 * price_subtotal_incl` for every refunded discounted line. opw-6281752 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271008 Forward-Port-Of: odoo/odoo#270592
This update fixes a misclassification of sales from European companies to Northern Ireland (XI) customers. Previously, these service sales were incorrectly treated as intra-community transactions, leading to potential tax discrepancies. The change adds a check to ensure these sales are accurately categorized as third-country transactions, aligning with regulations.
Original PR description
…stomers The services sales done from a European company to a Northern Ireland (XI) company should not contain intra-community taxes but should be treated as third country (non-EU) transactions. We solve it by adding a check in the EC Sales List return that is only visible when a wrong record occurs. task-6007931 Forward-Port-Of: odoo/enterprise#121487
This update fixes an error in the generation of CFDI documents when payments are made in foreign currencies (like USD). Previously, the CFDI document incorrectly displayed the payment amount and rate. The fix ensures the correct payment amount and rate are used, accurately reflecting the transaction details for Mexican tax reporting.
Original PR description
The rate and payment amount shown on the CFDI document generated after updating payments was wrong when the payment was made in a foreign currency. Steps to reproduce: ------------------- * Create a journal that use USD as currency and set the rate to 20 MXN for 1 USD * Create an invoice in MXN and make sure it is set to PPD * Add any product to the invoice for 300$ and post it * Send the invoice to CFDI (a first document should be generated) * Create a payment of 15 USD in the new journal and reconcile it with the invoice * Go back to the invoice and click on "Update payments" to generate the second CFDI document > Observation: The payment document shows an amount of 300 USD with a rate of 1 instead of 15 USD with a rate of 20. Why the fix: ------------ We make sure to use the amount from the statement line when there is one. opw-5974519 Forward-Port-Of: odoo/enterprise#121515 Forward-Port-Of: odoo/enterprise#115779
This update fixes an issue where the quantity invoiced on a sale order wasn't correctly updated after a refund was processed from the PoS. The fix ensures that refund amounts are accurately reflected in the sale order's invoice quantity, resolving a previous inconsistency between PoS and backend refund processes. This improves the accuracy of order reporting and reconciliation.
Original PR description
When making a refund of a PoS order that was created from a sale order, the sale order qty_invoice was not updated correctly. Steps to reproduce: ------------------- * Create a sale order with any product and confirm it * Open a PoS and settle the order * At this point the qty_invoiced should be 1 on the sale order line * Refund the PoS order from the PoS > Observation: The qty_invoiced is still one. Why the fix: ------------ We now take refund lines into account when computing the qty_invoiced. Note: ------------ There was an inconsistency between a refund made from the PoS and a refund made from the backend. The former is not linking the sale order line to the refund line, while the latter does. This was causing issue when refunding from the backend as it would count the refund twice. To fix this we now remove the link to the sale order line when refunding from the backend. opw-4991405 Forward-Port-Of: odoo/odoo#273132 Forward-Port-Of: odoo/odoo#259653
This update resolves a problem where completed documents in the sign module were displaying inconsistent access rights. The fix ensures that the permissions associated with finalized documents are accurate and reliable, improving the overall security and functionality of the document signing process. This change enhances the trust and reliability of digital signatures within Odoo Enterprise.
Original PR description
Forward-Port-Of: odoo/enterprise#121576
This update fixes an issue where the cost of goods sold (COGS) for products manufactured using the MTO (Make-To-Order) production route wasn't accurately reflecting the FIFO (First-In, First-Out) inventory method. The fix ensures that the invoice COGS now correctly uses the actual lot cost, leading to more accurate financial reporting. This resolves a discrepancy between standard product prices and the true cost of materials.
Original PR description
### Steps to reproduce: - Create a storable product P tracked by SN, fifo perpetual lot valuated using the MTO route and with a BOM: 1 x COMP - Create, confirm and validate an MO for 10 unit of P…
### Steps to reproduce: - Create a storable product P tracked by SN, fifo perpetual lot valuated using the MTO route and with a BOM: 1 x COMP - Create, confirm and validate an MO for 10 unit of P using COMP's at 10$ (by setting its standard price). - Create and confirm a Sales Order for 1 unit of P > This generate an MO - Validate this MO for a new serial say SN011 using a COMP at 20$. - Validate the Delivery Order using SN011 - Create and post the customer invoice #### > The invoice COGS uses Std Price rather than the 20$ lot's fifo value ### Cause of the issue: The cogs value are generated based on the moves returned by the `_get_stock_moves` call of the acount.move.line: https://github.com/odoo/odoo/blob/6a356cb0640ce20c71f20a8bd64ef99e76a82489/addons/stock_account/models/account_move_line.py#L66-L68 Currently, if an account.move.line is linked to a sale.order.line, this methods returns the entire pull of stock moves linked to the sol: https://github.com/odoo/odoo/blob/79c9e7de6764e7f8e47709b827df6eee81e72637/addons/sale_stock/models/account_move.py#L155-L156 However, these moves include both, the delivery move and the `move_finished_ids` of the MTO prodcution. This is problematic since the delivery move is considered as positive cogs qty and the MO is considered as incoming cogs qty leading to a sum of 0 cogs qty which in turns make the cogs price unit fall back to the product standard price instead of the fifo cost of the produced lot.: https://github.com/odoo/odoo/blob/6a356cb0640ce20c71f20a8bd64ef99e76a82489/addons/stock_account/models/stock_move.py#L257-L271 opw-6292048 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272815 Forward-Port-Of: odoo/odoo#271018
This update fixes an issue where payment states weren't correctly updated after changing an invoice's price, specifically for group payments. The change ensures that all payments transition to 'In Process' when a statement reconciliation fails, preventing reconciliation errors and improving payment processing reliability.
Original PR description
**Steps to reproduce:** - Install Accounting - Create an invoice: * Customer: Partner A * Total: 30.00 - Confirm the invoice - Create a second invoice for the same customer: * Customer: Partner A *…
**Steps to reproduce:** - Install Accounting - Create an invoice: * Customer: Partner A * Total: 30.00 - Confirm the invoice - Create a second invoice for the same customer: * Customer: Partner A * Total; 10.00 - Confirm the invoice - From the invoice list, select both invoice - Create payment: * Journal: Bank * Group Payments: [checked] * Amount: 40.00 - Create a third invoice for another customer: * Customer: Partner B * Total: 25.00 - Confirm the invoice - Register payment from the invoice - Create a fourth invoice for another customer: * Customer: Partner C * Total; 40.00 - Confirm the invoice - Register payment from the invoice - From the payment list, select all 3 payments and create batch payment - Validate the batch payment - From Accounting dashboard, open Bank journal - Create a new bank statement line of 105.00 - Match it with the batch payment At that point, the statement line is reconciled with the 4 invoices and the 3 payments are marked as paid. - Go to the fourth invoice - Reset it to draft - Change the price - Save When the amount of the invoice is changed, the statement line is unreconciled and all the payments should change state from "Paid" to "In Process". **Issue:** All the single payments have their state correctly changed to "In Process", except for the group payment for the 2 first invoices, which leads to undesired values when trying to reconcile the statement line with the batch payment again. **Cause:** When the statement is unreconciled, all the partial reconcile records are deleted and the state of the linked payments are updated to "In Process". The payments are retrieved by checking if there are linked to an account move present in the partial reconcile record and if the amount of the payment matches the amount of the partial reconcile record. In case of a group payment, there are 2 partial reconcile records for each invoice linked to the payment. Therefore, in that case, the amount doesn't match the amount of the payment because it matches the amount of one of the invoice. opw-6141089 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273090 Forward-Port-Of: odoo/odoo#269510
This update fixes an issue where group payments weren't correctly updated when a statement line was unreconciled. The change ensures that all payments, including group payments, transition to 'In Process' state when a payment reconciliation fails, allowing for accurate accounting and reporting. This resolves a discrepancy in payment status during reconciliation.
Original PR description
**Steps to reproduce:** - Install Accounting - Create an invoice: * Customer: Partner A * Total: 30.00 - Confirm the invoice - Create a second invoice for the same customer: * Customer: Partner A *…
**Steps to reproduce:** - Install Accounting - Create an invoice: * Customer: Partner A * Total: 30.00 - Confirm the invoice - Create a second invoice for the same customer: * Customer: Partner A * Total; 10.00 - Confirm the invoice - From the invoice list, select both invoice - Create payment: * Journal: Bank * Group Payments: [checked] * Group Payments: [checked] * Amount: 40.00 - Create a third invoice for another customer: * Customer: Partner B * Total: 25.00 - Confirm the invoice - Register payment from the invoice - Create a fourth invoice for another customer: * Customer: Partner C * Total; 40.00 - Confirm the invoice - Register payment from the invoice - From the payment list, select all 3 payments and create batch payment - Validate the batch payment - From Accounting dashboard, open Bank journal - Create a new bank statement line of 105.00 - Match it with the batch payment At that point, the statement line is reconciled with the 4 invoices and the 3 payments are marked as paid. - Go to the fourth invoice - Reset it to draft - Change the price - Save When the amount of the invoice is changed, the statement line is unreconciled and all the payments should change state from "Paid" to "In Process". **Issue:** All the single payments have their state correctly changed to "In Process", except for the group payment for the 2 first invoices, which leads to undesired values when trying to reconcile the statement line with the batch payment again. **Cause:** When the statement is unreconciled, all the partial reconcile records are deleted and the state of the linked payments are updated to "In Process". The payments are retrieved by checking if there are linked to an account move present in the partial reconcile record and if the amount of the payment matches the amount of the partial reconcile record. In case of a group payment, there are 2 partial reconcile records for each invoice linked to the payment. Therefore, in that case, the amount doesn't match the amount of the payment because it matches the amount of one of the invoice. opw-6141089 Forward-Port-Of: odoo/enterprise#122280 Forward-Port-Of: odoo/enterprise#120210
This update fixes a payrun error that occurred when employees had multiple versions recorded within the same month. The issue stemmed from a calculation error when processing worked hours, leading to a system crash. This change ensures accurate payrun processing for employees with multiple versions.
Original PR description
Currently, there is an error while running payrun step with employee who has multiple version in 1 month. ``` number_of_hours = (work100_wds - worked_day).number_of_hours ValueError: Expected singleton: hr.payslip.worked_days(233, 234) ``` Step to reproduce: 1. Create Employee with multiple version in 1 month 2. Create New PayRun during that month 3. Run the PayRun until Payslip step 4. Expected error on payslip steps reason: substraction of work100_wds and worked_day generate more than 1 value, if we have multiple version in 1 month task-6296276
A recent change in Cloudflare impacted the way turnstile callbacks functioned, causing a disruption. To ensure turnstile functionality continues to work correctly, the team reverted to the previous implementation which avoids reliance on external widget details. This resolves a technical issue impacting website performance.
Original PR description
Callbacks were changed to use a single shared callback instead of a bunch of callbacks that captured a specific container. Cloudlfare since introduced a change that breaks this change by not making "this" available inside callbacks. We thus go back to the previous implementation that did not rely on implementation details of the external widget. related: 5aa5cf62a9d3f2b0c862b0aab337b22367843fa6 Forward-Port-Of: odoo/odoo#273538 Forward-Port-Of: odoo/odoo#273336