Daily updates from Odoo
Navigate
Branch
Monday, December 8, 2025
199 changes
18 changes
Resolved issues and error corrections
This fix resolves an issue where stock valuations were incorrect after splitting a purchase order receipt into a batch. The problem stemmed from how the system calculated values during batch validation, leading to inaccurate stock valuation amounts. This update ensures correct stock valuation calculations when using batch billing with split receipts.
Original PR description
…n batch billed on ordered qty **Problem:** When the picking of a purchase order (of a product billed on ordered quantity) is split into different moves and put in a batch, at batch validation, svls…
…n batch billed on ordered qty
**Problem:**
When the picking of a purchase order (of a product billed on ordered quantity) is split into different
moves and put in a batch, at batch validation, svls are created with the wrong values.
**Steps to reproduce:**
- enable "Batch, Wave & Cluster Transfers" settings
- create a storable product with a standard price of 1
- set the category as avco
- in the Purchase tab select the control policy as
"on ordered quantities"
- create and confirm a purchase order for 50 of this product
- on the Receipt, change the quantity to 20 and split the
picking
- go back the the PO and create and confirm a bill for
the full amount
- click on the receipt smart button
- select the two pickings and then the 'Action' button
- select add to batch
- check 'new batch transfer' and confirm
- open the batch and validate it
- open stock valuation
**Current behavior:**
the newly created svls have total values of
50 and 50.10
**Expected behavior:**
it should be 20 and 30
**Cause of the issue:**
When the batch is validated, _action_done is called
on the two stock moves.
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/stock/models/stock_picking.py#L1258
In the stock_account override:
- first the super method is called
As a consequence the state of the two moves becomes 'done'
and the qty_received of the linked purchase order line becomes 50.
- then product_price_update_before_done is called before creating
the svls.
Inside product_price_update_before_done we call _get_price_unit.
In the purchase_stock override of _get_price_unit :
- because the super method of action_done was already called,
qty_received of the purchase order line is 50, so _get_qty_received_without_self
will return 30.
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L50
So received_qty is 30 and later remaining_qty will be 20
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L86
- but because no svl was created yet receipt_value will stay 0 and later
remaining_value will be 50
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L55-L63
Therefore price_unit will be 2.5 (50/20) instead of 1
**fix**
We do not take into account the move(s) of the
same batch in the remaining value (because svls are not created yet)
so we should not take them into account in the remaining quantity.
opw-5179581
Forward-Port-Of: odoo/odoo#238222
Forward-Port-Of: odoo/odoo#235601This update resolves an error that occurred when sending invoices for Taiwan customers who didn't have a phone number listed. The fix prevents the system from attempting to access a missing field, ensuring invoices can be successfully generated and sent to Ecpay. This improves the reliability of the Taiwan Electronic Invoicing process.
Original PR description
This error occurs when the user try to send invoice. Steps to reproduce: - Install `l10n_tw_edi_ecpay` module > Switch to `Taiwan` company - SetUp `Taiwan Electronic Invoicing` in settings - Create a…
This error occurs when the user try to send invoice. Steps to reproduce: - Install `l10n_tw_edi_ecpay` module > Switch to `Taiwan` company - SetUp `Taiwan Electronic Invoicing` in settings - Create a New Customer with `Email` and `Tax ID` (eg: 12345678) - and no `phone` number. - Create New Invoice with created Customer > Confirm > Send > `Send to Ecpay` > Generate Traceback: `AttributeError: 'res.partner' object has no attribute 'mobile'` This issue occurs at [1] because when the `phone` field is not set, the system tries to fall back to the `mobile` field. However, the `mobile` field was removed from `res.partner` (see related reference), and it was reintroduced in the referenced [commit]. This commit cleans up the logic to avoid referencing a non-existent field. [1]: https://github.com/odoo/odoo/blob/f1deed16e2355a74fea522439826625535eb7052/addons/l10n_tw_edi_ecpay/models/account_move.py#L677-L678 reference- https://github.com/odoo/odoo/pull/189739 [commit]: https://github.com/odoo/odoo/pull/236938/commits/c7404dff58f232103af4271a445d3841a82be8a3 sentry-7086174794 Forward-Port-Of: odoo/odoo#238657
This update simplifies the appointment calendar by showing only one period (day, week, month, quarter, or year) at a time, instead of three. This change reduces visual clutter and provides users with a clearer view of their appointments, improving usability.
Original PR description
This PR displays one period of the requested scale (day, week, month, quarter and year) in the calendar instead of three. It avoids displaying unwanted periods and overwhelming users with information. Task-5022091 Forward-Port-Of: odoo/enterprise#98796
This update resolves a minor visual glitch in the Email Marketing app when creating campaigns with plain text templates. The fix ensures the snippet menu is initially folded, preventing a brief, distracting appearance. This improves the overall user experience and consistency within the application.
Original PR description
**Steps to reproduce:** - Go to the Email Marketing app - Create a new campaign and select the "Plain Text" Mail body for the template - Change between Mail body and Settings tabs - On Mail body tab, the right-hand building block section appears briefly (1 second) and then disappears **Issue:** Default state of the snippet menu has `snippetsMenuFolded` set to False before being inserted. **Fix:** As described in the comment just after the insert: ``` // Hide the snippetsMenu at first, other code will handle // if it should be shown or not. ``` So the fix ensure the menu is folded by default (not sure as to why the state was changed after inserting, so maybe it's expected). opw-5130191 Forward-Port-Of: odoo/odoo#238766
This update fixes a potential error in the Razorpay payment integration. If the Razorpay secret key is missing, the system would previously fail. The change now gracefully handles this situation by logging a warning and preventing signature calculations, ensuring smooth transaction processing.
Original PR description
An error is expected to occur at line [1] if the secret is missing when a transaction is processed through Razorpay and the page is redirected. **Error:** `AttributeError:'bool' object has no attribute 'encode'` **Solution:** * Added a check to log a warning and return None to abort signature calculation if the secret is missing similar to [2]. [1]: https://github.com/odoo/odoo/blob/bb37b3e320395c6e96b6a0c0c96367bd87d1c702/addons/payment_razorpay/models/payment_provider.py#L232 [2]: https://github.com/odoo/odoo/blob/bb37b3e320395c6e96b6a0c0c96367bd87d1c702/addons/payment_razorpay/models/payment_provider.py#L236-L238 **Sentry-6767571136**
A recent change to exclude US-specific report variants from account_reports tests has inadvertently introduced a bug in the 18.4 version. This fix removes the variant exclusions from the tests, resolving the issue. This change was originally intended for the 19.0 release.
Original PR description
In this commit f030cbefb8885ad023d40dcc5a023a04014f6715, we decided to exclude all the report variant in some account_reports test, because we only want to test with the generic tax report, and not the specific localizations variants. This has been merged in 19.0, but it's breaking tests in 18.4 as well, since this change https://github.com/odoo/enterprise/pull/100063 This commit remove the variants from the tests as well. runbot-234444
This update fixes a bug where old work entries persisted across different versions of our scheduling system. The change ensures that outdated work entries are automatically removed when a new version with a different schedule is created, maintaining data accuracy and preventing confusion.
Original PR description
Problem ---------- When we create a new version with a new working schedule, it will generate correct work entries (because no one was generated for this version before) But it will not remove the previous one for the other previous versions. Solution ---------- Nullify work entries if outside the valid period of the version if they were already created before. task-5065139
A recent test failure related to task scheduling was caused by incorrect timezone calculations. This update corrects the system to use UTC for interval computation, ensuring accurate task planning and preventing scheduling discrepancies. This resolves a potential issue impacting task scheduling accuracy.
Original PR description
The test `test_plan_task_in_calendar` failed with a one-hour difference in `planned_date_begin`. The error occurred because the work intervals were computed using the resource's timezone (`Europe/Brussels`) instead of `UTC`, leading to a shifted planned date. Setting the resource timezone to `UTC` ensures consistent interval computation and resolves the test failure. [RB-227059](https://runbot.odoo.com/odoo/error/227059)
This update resolves an issue where a warning banner appeared during SEPA batch payments if a linked employee lacked an address. The change ensures the system correctly uses the employee's address, eliminating the misleading warning and improving the payment process. This change was made to enhance user experience and data accuracy.
Original PR description
…oyee has an address Doing batch payment for sepa payment would generate a warning banner if the partner has no address ( city and country ) However in reality ( already working ) the xml report will be generated with the linked employee address in the case of absence of the partner address thus it should not show a warning. The change removes the warning in this case. task: 5266346 Forward-Port-Of: odoo/enterprise#99928
This update resolves an issue preventing users from adding products from the parent company to quotation templates within the multi-company setup. Previously, this was allowed in standard sales orders, but not quotation templates. This change aligns the quotation template functionality with the existing sales order flow, improving usability and flexibility for our business users.
Original PR description
### Issue In this issue, having multi-company setup, we cannot make a quotation template with a product from the parent company. While this is allowed in sale order. #### To reproduce: 1- Create a product and in the product form, set the the company field to the parent company. 2- Create a quotation template and set the company field to the child branch. 3- In the quotation template, add a line and use the created product from the parent company. 4- Saving the form will raise an error. Talked with PO about the issue and he agreed that the quotation template should allow product from the parent company. This is already the flow in the quotation itself. opw-5177590 Forward-Port-Of: odoo/odoo#237732
This update resolves a technical issue within the HTML editor that prevented users from successfully coloring text when selecting a link containing a specific character (feff). The fix ensures the editor accurately handles selections and avoids a traceback, improving the overall coloring functionality. This change was made to enhance the stability and reliability of the HTML editor.
Original PR description
Problem: When the user selects a link to color and the selection falls on a `feff` character, a traceback occurs. Cause: After commit 927f4b973932d14961c148e13473017651a60dc0, we preserve the…
Problem: When the user selects a link to color and the selection falls on a `feff` character, a traceback occurs. Cause: After commit 927f4b973932d14961c148e13473017651a60dc0, we preserve the selection at: https://github.com/odoo/odoo/blob/bee7fc1f955c52a88b527ad9a2ddf0021529bbc7/addons/html_editor/static/src/main/font/color_plugin.js#L247-L247 and then call `getFonts()`, which internally uses `this.dependencies.split.splitAroundUntil()`. If the selection is on a `feff` node, `splitAroundUntil()` can clear those nodes because `splitElement()` inside it dispatches to `clean_handlers` with the selected element containing the `feff`. Since the preserved cursor offset refers to the node before the `feff` was removed, restoring it throws: `The offset x is larger than the node's length (y).` Solution: After `splitAroundUntil()`, adjust the preserved cursor offsets if the nodes were mutated to ensure they remain valid. Steps to reproduce: It is difficult to reproduce manually, but the issue occurs when coloring a link with the selection on a `feff`. A test case replicating the situation can be based on the original failing template in the customer’s database. opw-4953943 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238450 Forward-Port-Of: odoo/odoo#234328
This update resolves an issue where the SAFT export process would fail when a journal entry lacked a partner but included a receivable account. The fix ensures the system can now correctly generate SAFT files in these scenarios, preventing export errors and improving compliance. This impacts companies using the SAFT reporting feature.
Original PR description
If we try to export a SAF-T file when a line doesn't have any partner but having a receivable account, then a traceback is displayed.
(Backport of #98240)
How to reproduce?
1. Use a company with a localization using SAF-T (e.g. l10n_dk)
2. Create and post a journal entry with no partner, and with a line having a receivable account.
3. Go on the general ledger, and export in the SAF-T format
opw-5260937
Forward-Port-Of: odoo/enterprise#100960
Forward-Port-Of: odoo/enterprise#100296This update resolves an issue where marking multiple manufacturing orders as done resulted in an error. The fix ensures accurate precision rounding when handling multiple units of measure within the manufacturing process, preventing data inconsistencies.
Original PR description
Currently, an error occurs when user marks multiple Manufacturing Orders as Done. **Steps to Reproduce…
Currently, an error occurs when user marks multiple Manufacturing Orders as Done.
**Steps to Reproduce ([Video](https://drive.google.com/file/d/1XfkMB001rMiyulRGrP4dlJFDYByo_5Bv/view?usp=drive_link)):**
- Install the `mrp` module.
- Go to `Settings` and enable `Units of Measure & Packagings`.
- Go to `Products and `create two products` with different `units of measure`.
- Go to `Manufacturing Orders`, create a manufacturing order by `adding one of the products`, and then `create work order` in the Work Orders section and `confirm` it.
- Create another `manufacturing order` with the `same quantity` for the second product and add a `Work Order` for it as well and `confirm` it.
- Go to the `list view`, select `both orders`, and click `Mark as Done` from the `Actions` menu.
**Error:**
```
ValueError: ValueError('Expected singleton: uom.uom(4, 6)') while evaluating
"if records:\n res = records.filtered(lambda mo: mo.state in {'confirmed', 'to_close', 'progress'}).button_mark_done()\n if res is not True:\n action = res"
ValueError: Expected singleton: uom.uom(4, 6)
```
After [this commit], which improves the performance of button_finish, when a user marks multiple orders as done with the same quantity but different uom , it creates all_vals_dict based on the vals[1] data as the key and the work order as the value[2]. Then it stores two or more work orders with different UoMs under the same vals key. When attempting to write multiple work orders[3], the precision rounding is calculated, which raises the error[4] due to multiple UoMs.
The commit ensures that when writing records, precision_rounding is calculated separately for each Work Order's UoM.
[this commit]: https://github.com/odoo/odoo/pull/223715/commits/b857d192085a38b612335223d04f8bdff91b898c
[1]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L698-L703
[2]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L706
[3]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L708
[4]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L477
sentry-7050854871
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#238086This update ensures POS orders are processed immediately after online payments, regardless of whether the user views a confirmation page. Previously, delays caused confusion for customers and cashiers. Now, transactions are processed directly after payment confirmation, maintaining accurate order status.
Original PR description
..., pos_online_payment_self_order Task: [#5217268](https://www.odoo.com/odoo/project/1737/tasks/5217268) --- Previously, when an online payment was made, the user was supposed to be redirected to a…
..., pos_online_payment_self_order Task: [#5217268](https://www.odoo.com/odoo/project/1737/tasks/5217268) --- Previously, when an online payment was made, the user was supposed to be redirected to a payment confirmation page, which triggered the payment transaction post-processing. However, in some cases, the user never reaches this page. For example: the user sees that the payment succeeded in their banking app and closes the tab before being redirected to the confirmation page. To still process the orders, a cron runs every 10 minutes to post-process transactions that were not processed yet. However, for POS self-orders this is not ideal: we need the order to be processed as soon as possible since we are in direct contact with the user. A situation where the customer insists their payment went through but the cashier sees no updated order creates unnecessary confusion. --- To fix this, we now trigger the cron directly after receiving the callback from the payment provider. This ensures that the transaction (and therefore the order) is always post-processed immediately and kept up-to-date, even if the user never reaches the confirmation page. Forward-Port-Of: odoo/odoo#235254
This update ensures that orders are automatically sent to the kitchen (PDIS) after a self-order payment is confirmed, regardless of whether the user sees a confirmation page. Previously, reliance on the confirmation page was unreliable, leading to potential delays and confusion. This change improves the overall POS experience by guaranteeing timely order processing.
Original PR description
pos_online_payment* = pos_online_payment_self_order_preparation_display Task: [#5217268](https://www.odoo.com/odoo/project/1737/tasks/5217268) --- Previously, when an online payment was made, the…
pos_online_payment* = pos_online_payment_self_order_preparation_display Task: [#5217268](https://www.odoo.com/odoo/project/1737/tasks/5217268) --- Previously, when an online payment was made, the user was supposed to be redirected to a payment confirmation page which, once the transaction succeeded, sent the related order to the kitchen (PDIS). However, in some cases, the user never reaches this page. For example, the user may see the payment succeed in their banking app and close the tab before the redirection happens. For POS self-orders, we must send the order to the kitchen as soon as the payment is confirmed to avoid confusion between the customer, the cashier, and the kitchen staff. Relying solely on the confirmation page was therefore unreliable. --- To fix this, we now leverage the cron that post-processes payment transactions: we gather all transactions made in self-order or kiosk mode that are not yet post-processed, and send their corresponding orders to the kitchen. This ensures that orders reach the PDIS even when the user never lands on the confirmation page. Forward-Port-Of: odoo/enterprise#99249
This update fixes a bug where form fields without labels were not being submitted correctly. Now, all form fields, even those without labels, are reliably captured and sent when the 'send' button is clicked. Additionally, the system now prevents users from removing labels on form fields, ensuring data integrity.
Original PR description
Before this commit, a form input without a label would not send its data when clicking send. Steps to reproduce - go to the website editor - add a form - choose any field - delete the field label - save and exit the editor - now in the website, fill the form and click send => the fields without a name label are not sent After this commit fields without a label get sent with a placeholder "unknown_field" task-5062575 Forward-Port-Of: odoo/odoo#237805 Forward-Port-Of: odoo/odoo#225545
This update corrects a bug where inactive accounts were hidden from reports. The change reflects a new setting ('active') for account status, which previously caused the reporting engine to ignore inactive accounts. This ensures all accounts, active or inactive, are accurately reflected in reports.
Original PR description
In replacing the deprecated field with the special `active` field the account_codes prefix engine no longer displays values for accounts that are inactive.
This disables the active test in:
- computing the domain for accounts
- auditing the value (since the domain is `('account_id.code', 'in'...)`
opw-5226153
Forward-Port-Of: odoo/enterprise#100885A recent update to Odoo's security features caused a problem where users couldn't successfully revoke trusted devices through the portal. This fix corrects two typos in the system's dynamic content, ensuring that users can now properly remove previously trusted devices from their accounts. This resolves a potential security concern.
Original PR description
After public widgets have been rewritten as Interactions [1], there were 2 typos in `dynamicContent` that led to the wrong behavior. Because of that, we couldn't revoke a trusted device, or all of them. Steps to see the issue, - Turn the 2FA on - Add a trusted device, for example, by checking `Don't ask again on this device` when prompted to enter the authentication code while logging in. - Go to /my/security - Try to revoke a trusted device, either just by clicking on the trash icon button, or the 'Revoke all' button. => Nothing happens. [1]: https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba Forward-Port-Of: odoo/odoo#238830
9 changes
Resolved issues and error corrections
This update resolves an error that occurred when users attempted to send invoices through the Taiwan Electronic Invoicing module for ECpay. The issue stemmed from a system attempt to access a field that was no longer present in the customer record. This change ensures the system correctly handles invoices without this missing data, preventing the sending process from failing.
Original PR description
This error occurs when the user try to send invoice. Steps to reproduce: - Install `l10n_tw_edi_ecpay` module > Switch to `Taiwan` company - SetUp `Taiwan Electronic Invoicing` in settings - Create a…
This error occurs when the user try to send invoice. Steps to reproduce: - Install `l10n_tw_edi_ecpay` module > Switch to `Taiwan` company - SetUp `Taiwan Electronic Invoicing` in settings - Create a New Customer with `Email` and `Tax ID` (eg: 12345678) - and no `phone` number. - Create New Invoice with created Customer > Confirm > Send > `Send to Ecpay` > Generate Traceback: `AttributeError: 'res.partner' object has no attribute 'mobile'` This issue occurs at [1] because when the `phone` field is not set, the system tries to fall back to the `mobile` field. However, the `mobile` field was removed from `res.partner` (see related reference), and it was reintroduced in the referenced [commit]. This commit cleans up the logic to avoid referencing a non-existent field. [1]: https://github.com/odoo/odoo/blob/f1deed16e2355a74fea522439826625535eb7052/addons/l10n_tw_edi_ecpay/models/account_move.py#L677-L678 reference- https://github.com/odoo/odoo/pull/189739 [commit]: https://github.com/odoo/odoo/pull/236938/commits/c7404dff58f232103af4271a445d3841a82be8a3 sentry-7086174794 Forward-Port-Of: odoo/odoo#238657
This update simplifies the appointment calendar by showing only one period at a time (day, week, month, etc.) instead of three. This change reduces visual clutter and provides users with a clearer view of their appointments, improving usability.
Original PR description
This PR displays one period of the requested scale (day, week, month, quarter and year) in the calendar instead of three. It avoids displaying unwanted periods and overwhelming users with information. Task-5022091 Forward-Port-Of: odoo/enterprise#98796
This update resolves a minor visual glitch in the Email Marketing app when creating campaigns with plain text templates. The fix ensures the snippet menu is initially folded, preventing a brief, distracting appearance. This improves the overall user experience and consistency within the application.
Original PR description
**Steps to reproduce:** - Go to the Email Marketing app - Create a new campaign and select the "Plain Text" Mail body for the template - Change between Mail body and Settings tabs - On Mail body tab, the right-hand building block section appears briefly (1 second) and then disappears **Issue:** Default state of the snippet menu has `snippetsMenuFolded` set to False before being inserted. **Fix:** As described in the comment just after the insert: ``` // Hide the snippetsMenu at first, other code will handle // if it should be shown or not. ``` So the fix ensure the menu is folded by default (not sure as to why the state was changed after inserting, so maybe it's expected). opw-5130191 Forward-Port-Of: odoo/odoo#238766
This update resolves an issue where a warning banner appeared during SEPA batch payments if a linked employee lacked an address. The change ensures the system correctly uses the employee's address, eliminating the misleading warning and streamlining the payment process. This improves user experience and data accuracy.
Original PR description
…oyee has an address Doing batch payment for sepa payment would generate a warning banner if the partner has no address ( city and country ) However in reality ( already working ) the xml report will be generated with the linked employee address in the case of absence of the partner address thus it should not show a warning. The change removes the warning in this case. task: 5266346 Forward-Port-Of: odoo/enterprise#99928
This update prevents errors during Peppol invoice sending caused by invalid characters in invoice data. The system now filters out control characters that are not compatible with XML, ensuring invoices can be successfully transmitted to Peppol. This resolves a technical issue that could have disrupted Peppol integration.
Original PR description
## Issue: When a character that's not compatible with XML is in an invoice, and you send it to Peppol, a traceback was raised: `ValueError: All strings must be XML compatible: Unicode or ASCII, no NULL bytes or control characters` ## Cause: `dict_to_xml` converts each invoice field into XML, but certain control characters (e.g., `\x02`) are not allowed in XML according to the specification: https://www.w3.org/TR/xml/#charsets If such a character appears in the data (e.g., imported through a product CSV), the XML generation crashes ## Steps to produce: - Install `account_peppol` and `l10n_be` (to get the BE Company CoA) - Import a product containing a control character: `echo -e "name,default_code\nTest\x02Product,ABC123" > products.csv` - Create an invoice for the BE company using the product `Test\x02Product` - Send it via Send > by Peppol - A traceback is raised opw-5114648 Forward-Port-Of: odoo/odoo#236836
This update resolves an issue preventing users from adding products from the parent company to quotation templates within a multi-company setup. Previously, this was allowed in standard sales orders, but not quotation templates. The change ensures consistent functionality across sales processes, simplifying product selection for users.
Original PR description
### Issue In this issue, having multi-company setup, we cannot make a quotation template with a product from the parent company. While this is allowed in sale order. #### To reproduce: 1- Create a product and in the product form, set the the company field to the parent company. 2- Create a quotation template and set the company field to the child branch. 3- In the quotation template, add a line and use the created product from the parent company. 4- Saving the form will raise an error. Talked with PO about the issue and he agreed that the quotation template should allow product from the parent company. This is already the flow in the quotation itself. opw-5177590 Forward-Port-Of: odoo/odoo#237732
This update fixes an issue that prevented the generation of SAFT files when a journal entry lacked a partner but included a receivable account. The fix ensures that SAFT exports now function correctly for companies using this reporting standard, resolving a potential reporting error. This improves compliance and data accuracy.
Original PR description
If we try to export a SAF-T file when a line doesn't have any partner but having a receivable account, then a traceback is displayed.
(Backport of #98240)
How to reproduce?
1. Use a company with a localization using SAF-T (e.g. l10n_dk)
2. Create and post a journal entry with no partner, and with a line having a receivable account.
3. Go on the general ledger, and export in the SAF-T format
opw-5260937
Forward-Port-Of: odoo/enterprise#100960
Forward-Port-Of: odoo/enterprise#100296A test related to filtering work orders by user was intermittently failing. This fix addresses a timing issue where the test checked for record visibility too early after a user switch. By splitting the test into two steps – verifying the user switch and then confirming the presence of new records – the test now consistently passes.
Original PR description
The test `test_shop_floor_my_wo_filter_with_pin_user` sometimes fails on these steps:…
The test `test_shop_floor_my_wo_filter_with_pin_user` sometimes fails on these steps: https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L177-L190 https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L196-L206 https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L212-L221 This happends since changing the user requires some time to display the related shopfloor records, but the steps check the number of visible records as soon as it has switched rather than when it is sure that the records are displayed. #### Fix: Since switching employees will first empty the recordset and later display the related records, we can split the steps in two. We first check that we switched users, then we check the existence of a record that is not present for the previous user, and only then perform the related checks. #### runbot-226734 Forward-Port-Of: odoo/enterprise#100908 Forward-Port-Of: odoo/enterprise#100746
This update corrects a technical issue preventing users from successfully revoking trusted devices within the security settings. The problem stemmed from a typo in the system's dynamic content, which blocked the revocation process. This ensures users can properly manage their 2FA security settings.
Original PR description
After public widgets have been rewritten as Interactions [1], there were 2 typos in `dynamicContent` that led to the wrong behavior. Because of that, we couldn't revoke a trusted device, or all of them. Steps to see the issue, - Turn the 2FA on - Add a trusted device, for example, by checking `Don't ask again on this device` when prompted to enter the authentication code while logging in. - Go to /my/security - Try to revoke a trusted device, either just by clicking on the trash icon button, or the 'Revoke all' button. => Nothing happens. [1]: https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba Forward-Port-Of: odoo/odoo#238830
4 changes
Resolved issues and error corrections
This update resolves an issue where helpdesk ticket assignments were failing due to incorrect resource selection. The fix ensures that only resources within the same company as the helpdesk team are considered, preventing access errors and improving ticket assignment functionality. This improves stability and reliability of the helpdesk module.
Original PR description
To reproduce: ============= - with `hr_contract` and `helpdesk` installed - create a user with 2 resources in 2 different companies - add the user as member of a helpdesk team of company A - enable…
To reproduce: ============= - with `hr_contract` and `helpdesk` installed - create a user with 2 resources in 2 different companies - add the user as member of a helpdesk team of company A - enable auto assignment on the team - try to create a ticket on that team -> error Problem: ======== When computing working intervals for resources of the team members, we were considering all resources of the user, even those not in the same company as the helpdesk team. Which lead to access errors when trying to read data from the other company. This issue was not caught before as we were never reading data from the resources, until this [commit](https://github.com/odoo/odoo/commit/79a559c9741410ad861c107e395b2fc486da95e8) where we try reading `employee_id` of the resource. Solution: ========= Filter resources to keep only those in the same company as the helpdesk team. P.S: ==== the removed test was trying to test assigning ticket to user that is not in the same company as the helpdesk team, which is not correct so the test was removed. opw-[2749232](https://www.odoo.com/web#id=2749232&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#99614
This change eliminates a misleading warning banner that appeared during SEPA batch payments when a linked employee had an address. The system was already correctly generating reports using the employee's address, so this fix ensures a smoother user experience and avoids unnecessary alerts. This improves the reliability of batch payment processing.
Original PR description
…oyee has an address Doing batch payment for sepa payment would generate a warning banner if the partner has no address ( city and country ) However in reality ( already working ) the xml report will be generated with the linked employee address in the case of absence of the partner address thus it should not show a warning. The change removes the warning in this case. task: 5266346 Forward-Port-Of: odoo/enterprise#99928
This update resolves an issue where clicking a Field Service record in the kanban view opened it in the same tab instead of a new one. The fix corrects a technical error within the `industry_fsm` module that prevented the expected new-tab behavior when using a middle mouse click. This ensures a smoother user experience when accessing records.
Original PR description
Steps to reproduce: 1. Install `industry_fsm` 2. Open Field service module 3. In the kanban view, click a record with the middle mouse button Issue: - The record opens in the same tab instead of a new tab. Cause: - `FsmMyTaskKanbanRecord` overrides `onGlobalClick` without propagating the `newWindow` argument, preventing the expected new-tab behavior. Solution: - Forward the `newWindow` parameter to the parent implementation to restore the correct handling of the middle mouse click opw-5351842
This update fixes an issue where subscription details weren't correctly displayed in the dashboard. Specifically, it addressed a bug where sale order items were incorrectly shown alongside subscriptions and the subscription titles were not accurate. The change ensures subscriptions are presented clearly and accurately within the dashboard.
Original PR description
Before this commit, when subscriptions were linked to the analytic account of a project, the sale order items appears in an unwanted section when the section is unfolded. Meanwhile, when the subscription section is unfolded the title of the subscriptions items are not correctly displayed. The first issue is due to the fact that we did not correctly exclude the subscriptions items from the domain. The second issue is due to the fact that we fetch the field 'name' from the subscription search instead of the field 'display_name' task-5159781
13 changes
Enhancements to existing features
This update enhances the VoIP call setup process by adding a country selector to the keypad. Users can now easily input country codes, defaulting to the country of their last call. The system will automatically format the number correctly once a valid country is selected, streamlining the calling experience.
Original PR description
Instead of only show a country flag on keypad, we now have a country selector that can help user to input country prefix when calling. The default flag will be the country of last call. We will format the number when it's valid. Task-5106962
Resolved issues and error corrections
This update resolves a bug where the 'lock document' action wasn't consistently updating in the document previewer's action menu. The fix ensures the action menu reflects the current document status, improving the user experience when managing document access.
Original PR description
Steps to reproduce =================== - Preview any documents. - Click on the actions menu and lock the document. - Now go to the actions menu again. => The set of options is not updated. Technical =========== - The action menu, which we are using inside the file previewer, is passed explicitly inside the FileViewer component of the document. We were using the `record.load()`, which will not have any effect on the FileViewer component and that's why the action menu was not updating. After this commit ================== - Used the `this._notifyChange()` method, which closes the preview and loads the model to align with the same behaviour as other actions. Task-4988116 Forward-Port-Of: odoo/enterprise#100639 Forward-Port-Of: odoo/enterprise#91760
This update resolves an issue causing errors during payslip generation. The fix ensures the system handles missing data gracefully by using a safer method to access dictionary values, preventing a key error. This improves the reliability of payroll processing.
Original PR description
Bug: When generating payslips, there is a traceback with keyerror. Cause: We were getting info from a dict but keys could be not present. Fix: Use get instead, with a default value. Forward-Port-Of: odoo/enterprise#100709 Forward-Port-Of: odoo/enterprise#99245
This update resolves a technical issue where calculations for new electronic invoice documents in the l10n_uy_edi module were failing. The fix ensures that necessary data is correctly assigned when a new document record is created, preventing calculation errors. This improves the reliability of invoice processing.
Original PR description
The PR https://github.com/odoo/odoo/pull/209587 adds a check for onchange calls on a newly created record. Since in that case `move_id` is not set on `l10n_uy.document`, the compute method fails to assign values. This commit adds a pre-assigned fallback for this specific case. Runbot error: https://runbot.odoo.com/odoo/error/234425 Forward-Port-Of: odoo/enterprise#101060
This update resolves a technical issue that prevented the printed receipt tour from working correctly after installing the `l10n_se_pos` module. The fix corrects a programming error that caused a runtime error, ensuring the receipt tour functions as expected for users.
Original PR description
in this commit: - Fixed TypeError: this.get_order is not a function raised during the `test_printed_receipt_tour` in POS after installing or `l10n_se_pos`. runbot-233248 Forward-Port-Of: odoo/enterprise#101016 Forward-Port-Of: odoo/enterprise#97355
This update improves the accuracy of pay dates displayed on payslips. Now, the payslip will show the actual payment date if available, otherwise it defaults to the current date. This ensures employees and payroll teams have the most up-to-date information.
Original PR description
Change the pay date in the payslip to the payment date if available; otherwise, use the current date. task-5358370
This update fixes an issue where employees were incorrectly added as future drivers for multiple vehicles during contract signing. The system now automatically remembers the last selected vehicle and its associated costs, streamlining the process and ensuring accurate salary calculations. A new tutorial has also been added to demonstrate the improved functionality.
Original PR description
purpose: When, for the same offer, the employee/applicant sign several times and choose a different car each time, he's recorded as future driver for all the cars. It should only be the last one previous behavior: - the employee/applicant is assigned as a future driver to each car he selects with each sign which removes them from the salary configurator for other employees/applicants - the salary configurator doesn't autofill previously selected vehicle values for partially signed contracts current behavior: - reset the `future_driver_id` field of previously selected vehicles with each sign - made the vehicles autofill from previously partailly signed offers - made the configurator display the vehicle cost of the selected vehicle instead of 0 the first time you choose it (when checking the checkbox not selecting from the dropdown) - added a tour `hr_contract_salary_tour_sign_again` to check if the values are filled correctly from previous signs task-id : 4962961
A recent update resolved a crash that occurred when users clicked the 'Add from Documents' button within the Contacts or CRM apps. This fix addressed an error related to accessing data, ensuring the button now functions reliably. This improves the user experience for logging notes.
Original PR description
Steps to reproduce ================== - Go in the app Contacts or CRM - Open a record - Click on "Log note" - Click on the icon "Add from Documents" You get an error: TypeError: Cannot read properties of undefined (reading 'channel_type') Technical ========== The [Commit] changes the way of accessing the `channel_type` from thread. The patch of `SelectAddDocumentCreateDialog` missed the optional chaining in accessing the type. This commit adds the optional chaining to avoid crash on accessing `channel_type` when `channel` is undefined. [Commit]: https://github.com/odoo/enterprise/commit/8d1c75abfcb437962ce4314dd480f16398474532 Task-5343940
This update corrects a flaw in how payroll amounts are calculated for employees with fixed wages. Previously, the system assumed all work entries were present, leading to inaccuracies when pay schedules aren't monthly or when there are no work entries. Now, the calculation uses the actual working days to determine the daily rate, ensuring more accurate payroll amounts.
Original PR description
As of now, in payslips, the computation of the amount for the work entries is based on the assumption that the effect of all work entries required for the computation is present. So if I have a total of 10 days total days, then the rate per day is considered as: Wage / 10. But this would not work with the cases where the pay schedule is not exactly one month for non-attendance cases, or if there are days with no work entries in them, especially if the wage type is Fixed Wage. The suggestion for this task is to enhance the way the wage per day is computed when it is based on a Fixed Wage. which is to compute the number of days in the payslip period based on the working schedule, and have the rate per day being: Fixed Wage / Total days. Where Total days is based on the payslip period & the work schedule. task-5186744
This update simplifies the export of HR work entries by automatically hiding the company selection field when only one company is available for the user. Previously, users could only export from their current company. Now, the system intelligently adapts to allow selection of other accessible companies, improving usability and flexibility.
Original PR description
In the HR Work Entry Export mixin form view, the company_id field is now hidden when there is only one available company in the selection. A computed boolean field determines whether the field should be visible, based on the current user's allowed companies and any country restrictions. The form view uses this flag to automatically hide the field when unnecessary. task-5149817
A test related to employer costs calculations within the South Africa payroll module (l10n_sa_hr_payroll) was failing. This was resolved by moving the test to the related module, l10n_sa_hr_contract_salary, ensuring accurate calculations for employer contributions.
Original PR description
**Issue** : TestEmployerCostsWithSaFields.test_employer_costs_with_sa_fields fails in Single app testing of l10n_sa_hr_payroll causing this error "AttributeError: 'hr.version' object has no attribute '_compute_final_yearly_costs'" **Cause** : _compute_final_yearly_costs is defined in hr_contract_salary which is not a dependency of l10_sa_hr_payroll **Fix** : move the test to l10n_sa_hr_contract_salary , because the module depends on l10n_sa_hr_payroll and hr_contract_salary **task** - 5361838 **related PR** : enterprise#98239
Features or functions removed from Odoo
This update removes a method called '_get_report_date_to' from several Odoo reports. This method was previously only used for the stable version of the software and is no longer required in the main version. This cleanup improves code efficiency and maintainability.
Original PR description
Follow up of https://github.com/odoo/enterprise/commit/e23fad86efc0470960f6ef9768760a281cccb4de In the above mentioned fix modification of `_get_report_date_to` method meant only for stable. This PR removes the method as it is no longer needed in master.
Code cleanup and technical improvements
This update cleans up an outdated feature in Odoo's messaging system (Chatter) and improves the overall appearance. Specifically, the compact height property has been removed, and the topbar alignment has been adjusted for a cleaner and more intuitive user experience. This enhances usability for users communicating within Odoo.
Original PR description
https://github.com/odoo/odoo/pull/238570
28 changes
Enhancements to existing features
This update enables administrators to modify the work entries associated with payslips that have been reversed or refunded. Previously, these entries were immutable. This change provides greater flexibility in managing payroll records and correcting errors related to refunded payments.
Original PR description
-Originally, work entries for validated payslips cannot be modified. -This task allows for the modification of the work entries for the reverted payslips. -State of work entries can be modified manually through list view + form view on gear icons Task-id: #5380821
This update clarifies the label for a key work entry type within the Hong Kong payroll module. The term 'Use 713' has been replaced with 'ADW Calculation' for better clarity and understanding. This change improves the user experience and ensures accurate reporting within the system.
Original PR description
- changed the string for `l10n_hk_use_713` to be `ADW Calculation` instead of `Use 713` task-id: 5084137
This update ensures the E-Ledger report accurately reflects branch numbers by linking them to a new 'SUBENO' tag on partner records. This change aligns with a recent update to better define branch information within Odoo, improving the reliability of financial reporting. The update also ensures compatibility with related modules.
Original PR description
Currently, the BranchNumber field in the E-Ledger CSV is linked to res.company.company_id. However, a new res.partner.category 'SUBENO' was introduced to properly define branch numbers. So this change makes sure the branch number is captured from the tags on the branch's partner_id. l10n_tr_reports now also depends on l10n_tr_nilvera_einvoice because the SUBENO tag is created there. Task-id: 5022037
Resolved issues and error corrections
This update resolves an issue where the Frontdesk kiosk URL didn't consistently display the correct company logo. The fix ensures the logo is always shown when switching companies, improving the user experience. It corrects a permission error preventing access to the company record.
Original PR description
When switching companies in a Frontdesk station and opening the kiosk URL, the company logo does not appear. **Steps to produce:** - Install the `frontdesk` module. - Ensure the database has at least…
When switching companies in a Frontdesk station and opening the kiosk URL, the company logo does not appear. **Steps to produce:** - Install the `frontdesk` module. - Ensure the database has at least two companies, each with a logo configured. - `Enable multi-company` access (user has access to all companies). - Open any Frontdesk station configuration and change the company to one different from the currently active company. - Copy the kiosk URL and open it in an incognito/private window. - The kiosk opens, but the company logo is missing. **Issue:** - Company logo not comes on frontdesk kiosk. **Root cause:** - When the kiosk URL is accessed, Odoo logs an `Access Denied by record rules`. - This happens because the selected company on the station is not included in the `Public User’s companies`. - As a result, the public user cannot read the company record, so the logo does not load. **Solution:** - Added an `onchange` on `company_id` to automatically include the selected company in the Public User’s `company_ids` if it is not already present. - This ensures the kiosk always has access to correct company record and logo. - Also added an XML-side fix to prevent an access error that occurs when a company is not activated and we attempt to select it in the company field. **Before:** <img width="500" height="500" alt="frontdesk_image_before" src="https://github.com/user-attachments/assets/b002ac6e-5271-4561-bf03-542a3feeefd1" /> **After:** <img width="500" height="500" alt="frondesk_image_after" src="https://github.com/user-attachments/assets/7b5bffe4-ccbf-48f5-ad9c-d5e6d2e7678e" /> **opw-5138980** Forward-Port-Of: odoo/enterprise#100300
This update resolves an issue where the server logger was experiencing excessive queue buildup. The change reverts a recent adjustment to the logging interval, restoring it to a more stable setting. This ensures smoother data transmission and prevents potential performance slowdowns in the IoT driver.
Original PR description
Based on this review of https://github.com/odoo/odoo/pull/238740 this pr reverts the flush interval to 0.5s introduced in https://github.com/odoo/odoo/pull/238648 to avoid queue saturation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238912
This update resolves a technical issue that prevented the printed receipt tour from functioning correctly after installing the `l10n_se_pos` module for Swedish POS systems. The fix corrects a programming error, ensuring the receipt tour operates as intended and improving the user experience.
Original PR description
in this commit: - Fixed TypeError: this.get_order is not a function raised during the `test_printed_receipt_tour` in POS after installing or `l10n_se_pos`. runbot-233248 Forward-Port-Of: odoo/enterprise#101016 Forward-Port-Of: odoo/enterprise#97355
This update resolves a minor visual glitch in the Email Marketing app where a section briefly appeared and disappeared when switching between email templates. The fix ensures the snippet menu is initially folded, providing a smoother and more consistent user experience when creating campaigns. This improves the overall usability of the Email Marketing functionality.
Original PR description
**Steps to reproduce:** - Go to the Email Marketing app - Create a new campaign and select the "Plain Text" Mail body for the template - Change between Mail body and Settings tabs - On Mail body tab, the right-hand building block section appears briefly (1 second) and then disappears **Issue:** Default state of the snippet menu has `snippetsMenuFolded` set to False before being inserted. **Fix:** As described in the comment just after the insert: ``` // Hide the snippetsMenu at first, other code will handle // if it should be shown or not. ``` So the fix ensure the menu is folded by default (not sure as to why the state was changed after inserting, so maybe it's expected). opw-5130191 Forward-Port-Of: odoo/odoo#238766
This update resolves an issue where saving changes to course descriptions in the website editor would trigger an error. The fix modifies a template to ensure the correct HTML attributes are included, preventing the error and allowing users to successfully save their changes. This ensures a stable and functional website experience.
Original PR description
Steps to reproduce: --------------------------- 1. Install the `website_slides` module. 2. Navigate to the Courses page on the website. 3. Open the Website Editor. 4. Modify the short description of…
Steps to reproduce:
---------------------------
1. Install the `website_slides` module.
2. Navigate to the Courses page on the website.
3. Open the Website Editor.
4. Modify the short description of any course.
5. Click the Save button.
Observation:
---------------------------
A traceback is raised:
```
File '/data/build/odoo/addons/website/models/ir_ui_view.py', line 514, in save_embedded_field
Model = self.env[el.get('data-oe-model')]
```
Issue:
---------------------------
In the template
https://github.com/odoo/odoo/blob/9333df06e15134df92efed765cf95db38c0dfede/addons/website_slides/views/website_slides_templates_homepage.xml#L375 the short description is rendered inside a `<small>` tag. When parsed by `lxml`, the `<small>` tag is converted to a self-closing element and the text becomes wrapped in a new `<p>` inside an additional `<div>`.
```
b'<div><small class='o_line_clamp' data-oe-xpath='/t[1]/a[1]/div[2]/div[1]/small[1]'
data-oe-model='slide.channel' data-oe-id='1' data-oe-field='description_short'
data-oe-type='html' data-oe-expression='channel.description_short'
data-oe-sanitize='allow_form' spellcheck='false'/><p>Learn the basics of gardening! th new</p></div>'
```
This wrapper `<div>` does not contain the required `data-oe-model` attribute, causing `save_embedded_field` to fail.
Solution:
---------------------------
Replace the `<small>` tag with a `<div>` tag, adding the `small` class to preserve styling. This prevents lxml from producing a self-closing tag and ensures the attributes remain on the correct element.
opw-5273079This update resolves a testing error related to employee leave balances in the EG payroll module. Previously, tests incorrectly checked allocations for 2025, causing failures when calculating balances for 2026. The fix incorporates a 'freeze_time' setting across all relevant tests to ensure accurate calculations and prevent incorrect balance resets.
Original PR description
Before this commit, the test `test_get_annual_remaining_leaves_with_allocation` was checking the balance of an employee with an allocation for 2025. As no freeze_time was set, the test would fail in 2026 as the allocation would be invalid and the employee balance would fallback to 0. Same issue for the test `test_get_annual_remaining_leaves_after_leave_taken` The PR https://github.com/odoo/enterprise/pull/98223 was targetting the wrong test and thus, the error was not fixed. This commit merges all 3 tests in one using freeze_time runbot error 231559 Forward-Port-Of: odoo/enterprise#101458
This update resolves an error that occurred when sending invoices through the Taiwan Electronic Invoicing module for ECpay. The issue stemmed from a system attempt to access a field that was previously removed, causing a crash. This fix ensures invoices can be successfully generated and sent.
Original PR description
This error occurs when the user try to send invoice. Steps to reproduce: - Install `l10n_tw_edi_ecpay` module > Switch to `Taiwan` company - SetUp `Taiwan Electronic Invoicing` in settings - Create a…
This error occurs when the user try to send invoice. Steps to reproduce: - Install `l10n_tw_edi_ecpay` module > Switch to `Taiwan` company - SetUp `Taiwan Electronic Invoicing` in settings - Create a New Customer with `Email` and `Tax ID` (eg: 12345678) - and no `phone` number. - Create New Invoice with created Customer > Confirm > Send > `Send to Ecpay` > Generate Traceback: `AttributeError: 'res.partner' object has no attribute 'mobile'` This issue occurs at [1] because when the `phone` field is not set, the system tries to fall back to the `mobile` field. However, the `mobile` field was removed from `res.partner` (see related reference), and it was reintroduced in the referenced [commit]. This commit cleans up the logic to avoid referencing a non-existent field. [1]: https://github.com/odoo/odoo/blob/f1deed16e2355a74fea522439826625535eb7052/addons/l10n_tw_edi_ecpay/models/account_move.py#L677-L678 reference- https://github.com/odoo/odoo/pull/189739 [commit]: https://github.com/odoo/odoo/pull/236938/commits/c7404dff58f232103af4271a445d3841a82be8a3 sentry-7086174794 Forward-Port-Of: odoo/odoo#238657
This update fixes an issue where the keyboard would unexpectedly appear on mobile date fields, causing a poor user experience. Now, the keyboard doesn't open automatically, and the cursor is hidden on small screens, resulting in a smoother and more intuitive date selection process.
Original PR description
Before this commit:
- The cursor was shown inside the date/datetime input field on mobile,
which triggered the keyboard unnecessarily and degraded the user
experience.
Steps to reproduce:
1. Add a form snippet.
2. Add a Date/Datetime field.
3. Click on the Date field.
- The virtual keyboard appears and the datepicker popover may be
clipped or partially hidden.
After this commit:
- The virtual keyboard is now prevented from opening on date/datetime
inputs, and the text cursor within these fields is also hidden.
task-[4745714](https://www.odoo.com/odoo/project/974/tasks/4745714)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#238771
Forward-Port-Of: odoo/odoo#212053This update resolves an issue where users were incorrectly receiving access errors when working with Sales Orders and Projects across different companies. The fix ensures that users with access to multiple companies can correctly interact with linked records, improving usability in multi-company environments. This change enhances security by correctly validating access permissions.
Original PR description
**Steps to reproduce:** 1. Create a database in 19.0 version. 2. Create a second company (so there are two companies in total). 3. Install the Sales and Project applications. 4. In Company 1, create…
**Steps to reproduce:** 1. Create a database in 19.0 version. 2. Create a second company (so there are two companies in total). 3. Install the Sales and Project applications. 4. In Company 1, create a Sales Order. 5. In Company 2, create a Project that is restricted to Company 2 only (i.e., not shared across companies) and ensure it is billable. 6. Inside that project, create a Task and link it to the Sales Order from Company 1. Make sure both companies are selected in your company switcher. 7. Now, switch to only Company 1, and try to open the Sales Order that is linked to the task in Company 2. 8. At this point, an AccessError will be raised, even though the user has access rights in both companies. **Description of the issue:** The `AccessError` is being raised even though the user already has read access. This issue started after the following commit : (https://github.com/odoo/odoo/commit/aae732957c3c3b3590f5686cfccc0ab264d0b5c9) In that update, a new check was added requiring **read access** when performing operations on **many2many fields**. This behavior is correct and improves security. However, a problem occurs in **multi-company environments**. For example, if a user has access to two companies (Company A and Company B), and a **Sales Order** belongs to Company A while the linked **Project** belongs to Company B, then when the user opens or writes records with only one company selected, an `AccessError` is raised — even though the user has access to both companies. **Current behavior before PR:** When writing on a many2many field that links records across different companies, an `AccessError` is raised. This happens because the context does not include the `suggested_company`, so the system cannot detect that the user has access to both companies. In the [commit](https://github.com/odoo/upgrade/pull/7960/files#diff-df0a10c9996a33faffbfcd4f2126eb2143cc9ecaa7dc1c28dad7fe930b3c1388R475-R489) , the issue was avoided during tests by adding the `suggested_company` from the context to the allowed company list. But in the related Odoo commit: [6213c40](https://github.com/odoo/odoo/commit/6213c40932236101b529b82f0ea9fce1829c8c24#diff-706c5300f0b758ed43a362c85fa84a655c8bae12339bd882e98dc419623facc2R208) the context is always empty, meaning no company is added to the allowed list — leading to an unnecessary AccessError. **Desired behavior after PR is merged:** The `context` is now added before raising the AccessError. If the user has access to both companies (e.g., the one linked to the Sales Order and the one linked to the Project), the system correctly identifies this and does **not** raise an AccessError. If the user does **not** have access to the other company, the AccessError is still raised — ensuring that security remains intact. Desired behavior after PR is merged:c --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a minor issue on the Odoo portal where an empty filter menu appeared when no data was available on mobile devices. The change ensures a cleaner, more user-friendly experience by hiding the offcanvas filter section when there's no data to display. This improves usability and reduces visual clutter.
Original PR description
This PR prevents the offcanvas containing filters/sort buttons to be displayed in there is no data in the view, preventing to show an empty menu on screen. task-5072304 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a critical issue impacting holiday calculations for Swiss users in Odoo Enterprise 19.0. The fix corrects broken leave calculations and incorporates continued pay and disability benefits within the time-off application process, ensuring accurate payroll processing.
Original PR description
After recent changes in 19.0 on the time off mechanisme, leave calculation in switzerland was completely broken, we fix in this PR the view and the calculation and add the continued pay and disability on the time off application as well task-5384297
This update enables administrators to modify the work entries associated with payslips that have been reversed or refunded. Previously, these entries were immutable. This change improves operational efficiency by allowing for corrections to be made directly within the system through a user-friendly interface.
Original PR description
-Originally, work entries for validated payslips cannot be modified. -This task allows for the modification of the work entries for the reverted payslips. -State of work entries can be modified manually through list view + form view on gear icons Task-id: #5380821
This update fixes an issue where old work entries persisted across different versions. Now, when a new version is created with a new schedule, outdated work entries are automatically removed, ensuring accurate reporting and data consistency. This improves the reliability of our scheduling and time tracking processes.
Original PR description
Problem ---------- When we create a new version with a new working schedule, it will generate correct work entries (because no one was generated for this version before) But it will not remove the previous one for the other previous versions. Solution ---------- Nullify work entries if outside the valid period of the version if they were already created before. task-5065139
This update simplifies the appointment calendar by showing only one period (day, week, month, quarter, or year) at a time, instead of three. This change reduces visual clutter and provides users with a clearer view of their appointments. It addresses a previous issue with overwhelming information.
Original PR description
This PR displays one period of the requested scale (day, week, month, quarter and year) in the calendar instead of three. It avoids displaying unwanted periods and overwhelming users with information. Task-5022091 Forward-Port-Of: odoo/enterprise#98796
This update resolves an issue where a warning banner appeared during SEPA batch payments if a linked employee lacked an address. The change ensures the system correctly generates XML reports using the employee's address, even when the primary partner lacks address information. This improves the reliability of batch payment processing.
Original PR description
…oyee has an address Doing batch payment for sepa payment would generate a warning banner if the partner has no address ( city and country ) However in reality ( already working ) the xml report will be generated with the linked employee address in the case of absence of the partner address thus it should not show a warning. The change removes the warning in this case. task: 5266346 Forward-Port-Of: odoo/enterprise#99928
This update resolves an issue where newly created documents in the l10n_uy_edi module weren't correctly calculating certain fields. The fix ensures that these fields are properly assigned when a new document record is first created, preventing calculation errors. This improves the accuracy of edi document generation.
Original PR description
The PR https://github.com/odoo/odoo/pull/209587 adds a check for onchange calls on a newly created record. Since in that case `move_id` is not set on `l10n_uy.document`, the compute method fails to assign values. This commit adds a pre-assigned fallback for this specific case. Runbot error: https://runbot.odoo.com/odoo/error/234425 Forward-Port-Of: odoo/enterprise#101060
This update resolves an issue where opening GIF pickers within knowledge article comments would cause Odoo to crash. The fix adjusts how the GIF picker identifies action placement, ensuring it correctly recognizes buttons within 'extra actions' like those found in standard chat interfaces. This improves stability and usability for knowledge article commenting.
Original PR description
Before this commit, opening gif picker in a comment of a knowledge article would lead to crash. This happens because composer uses chatter visual, and pickers in composer picks either the quick or more node element as anchor of picker, depending on whether the action is in the quick or more action. In the case of knowledge article, the buttons are placed in extra actions like in chatter. However the picker placement was not taking into account this place, thus it fails to find action placement. This commit fixes the issue by adding support of extra actions as anchor for composer picker. Task-5163888
This update improves the time off dashboard by displaying the remaining unspent amount of overtime hours instead of the total overtime. This provides a clearer picture of an employee's available time off and avoids confusion regarding already used hours.
Original PR description
Instead of showing total overtime on the timeoff dashboard, show the unspent amount. Task-5261777
This update resolves a bug preventing users from opening Sales Orders linked to projects in different companies. The fix removes a restrictive check, allowing users with appropriate access rights to view Sales Orders regardless of the linked project's company affiliation. This ensures consistent access for users across multiple companies.
Original PR description
**Steps to reproduce the issue** 1. Create a database in Odoo 19.0. 2. Create a second company (so now you have two companies). 3. Install the **sale_project** app. 4. In **Company 1**, create a…
**Steps to reproduce the issue** 1. Create a database in Odoo 19.0. 2. Create a second company (so now you have two companies). 3. Install the **sale_project** app. 4. In **Company 1**, create a Sales Order. 5. In **Company 2**, create a Project that belongs **only** to Company 2 and mark it as *billable*. 6. Inside this Project, create a Task and link it to the Sales Order from Company 1. Make sure both companies are selected in the company switcher. 7. Now, switch to **only Company 1**, then try to open that Sales Order. 8. You will get an **AccessError**, even though the user has access rights in both companies. **Second scenario** 1. Create another user (User 2) who has access **only** to Company 1. 2. Give User 2 manager access in both Sales and Project. 3. Log in as User 2 and try to open the Sales Order. 4. You will again get an **AccessError**. **What is the actual issue?** The AccessError happens in multi-company setups. Even if a user has read access to the Sales Order, The error still blocks them from opening it if: * The Sales Order belongs to Company A * The linked Project belongs to Company B * The user currently has only Company A selected or have Access to company A only. This is because of the `_compute_project_ids` https://github.com/odoo/odoo/blob/ac6960dc553088894e688bcc0f4a49245aa02d6c/addons/sale_project/models/sale_order.py#L127 This logic causes problems because: * It only uses this check when the user is *not* a project manager. * Even project managers can get AccessErrors if they don’t have the other company selected or not have access of other company. * This is wrong because a user who **has the right to access the Sales Order** should still be allowed to open it, even if they don’t have access to the project in the other company. **How the issue is fixed** I removed the condition: `if not is_project_manager` This allows the system to skip the problematic filtering behavior. A user who has access rights to the Sales Order can now open it normally even if the linked project belongs to another company. OPW: [5229806](https://www.odoo.com/odoo/project/70/tasks/5229806) UPG: [3485646](https://upgrade.odoo.com/odoo/upgrade.request/3485646) 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 resolves a technical issue where the Chatter widget in the bank reconciliation module would display an error if a statement line wasn't selected when opening the chat. Making the 'statementLine' property optional eliminates this error and ensures the Chatter widget functions correctly.
Original PR description
The aim of this commit is putting the bank reco widget chatter's props "statementLine" as optional. Since we saved the last state of chatter (open/close), it might happen that we are opening the chatter without a statement line selected. This leads to an error in debug where the props statementLine of our custom chatter is not filled and leads to a traceback. By putting the props as optional, we are removing the error. no task id
This update simplifies the display of payment references in the bank reconciliation view. Previously, excessively long payment references were automatically expanded, now users must manually unfold the line to view the complete reference. This change improves the user experience and reduces potential visual clutter.
Original PR description
This commit removes the expand text feature available on payment reference field in the bank reconciliation. Before this commit, a payment reference too long to be fully displayed in the bank reconciliation view could be expanded to have the full payment ref. Now, the user has to unfold the line to get the full payment ref. no task id
This update corrects a technical issue preventing users from successfully revoking trusted devices through the security settings. The problem stemmed from a typo in the system's dynamic content, which blocked the removal of trusted devices. This ensures users can properly manage their 2FA security.
Original PR description
After public widgets have been rewritten as Interactions [1], there were 2 typos in `dynamicContent` that led to the wrong behavior. Because of that, we couldn't revoke a trusted device, or all of them. Steps to see the issue, - Turn the 2FA on - Add a trusted device, for example, by checking `Don't ask again on this device` when prompted to enter the authentication code while logging in. - Go to /my/security - Try to revoke a trusted device, either just by clicking on the trash icon button, or the 'Revoke all' button. => Nothing happens. [1]: https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba Forward-Port-Of: odoo/odoo#238830
This update resolves a bug that prevented the generation of SAFT files when a journal entry lacked a partner but included a receivable account. The fix ensures that SAFT exports can now successfully process these entries, addressing a potential compliance issue for businesses using SAFT reporting.
Original PR description
If we try to export a SAF-T file when a line doesn't have any partner but having a receivable account, then a traceback is displayed.
(Backport of #98240)
How to reproduce?
1. Use a company with a localization using SAF-T (e.g. l10n_dk)
2. Create and post a journal entry with no partner, and with a line having a receivable account.
3. Go on the general ledger, and export in the SAF-T format
opw-5260937
Forward-Port-Of: odoo/enterprise#100960
Forward-Port-Of: odoo/enterprise#100296This update ensures that Indian payroll localization settings are only displayed for companies located in India. Previously, all companies could see these settings, which has now been corrected to improve accuracy and compliance for Indian payroll operations. This change was made to align with local regulations.
Original PR description
Before: - Indian payroll localization setting was visible to all company. After: - Indian payroll localization settings will be visible to only Indian company. Steps to reproduce: - Install l10n_in_hr_payroll > Go to non Indian company > Payroll setting visible to all company. Task: 5383944
This update simplifies the creation of sign templates by automatically assigning them to the standard 'Sign' folder. Previously, users had to manually select the folder for each new template, which is now handled automatically. This streamlines the process and reduces the potential for errors.
Original PR description
Assign a default document folder to sign templates so that each newly created template automatically points to the default "Sign" folder. task-5023107 Forward-Port-Of: odoo/enterprise#92624
19 changes
Enhancements to existing features
This update expands how SLAs are defined for helpdesk tickets, allowing other Odoo modules to customize the criteria used to match SLAs. Previously, this was limited, but now it's enabled, providing greater flexibility and control over SLA management within the Helpdesk module. This improves the ability to tailor SLAs to specific business needs.
Original PR description
Allow other modules to modify the _sla_find domain when adding SLAs to helpdesk tickets. This is already the case for extra and false domains, while the main domain is hardcoded up to this commit.
Resolved issues and error corrections
This update fixes an accounting error related to invoices in Vietnam (l10n_vn). Previously, the system incorrectly created entries for both receivable and payable accounts when processing invoices. By changing the account type for 'Unearned Revenue' to 'Current Liabilities,' the system now accurately reflects financial data, ensuring correct balance sheet reporting.
Original PR description
When posting an invoice, the system creates: - Journal Entry: Dr 131 (Receivable) / Cr 511 Then the system creates a deferral entry: - Deferral entry: Dr 511 / Cr 3387 (Payable) Falsifying the…
When posting an invoice, the system creates: - Journal Entry: Dr 131 (Receivable) / Cr 511 Then the system creates a deferral entry: - Deferral entry: Dr 511 / Cr 3387 (Payable) Falsifying the Balance sheet report, in the accounts receivable and accounts payable indicators The issue was that account 3387 was configured as `Payable`, which caused the system to generate both Receivable (131) and Payable (3387) for the same partner. This is incorrect because account 3387 represents "Unearned Revenue", which is a current liability, not a payable account. By changing the account type from `Payable` to `Current Liabilities`, the deferral entry now correctly reflects that 3387 is a current liability account, preventing the incorrect reconciliation behavior where both receivable and payable entries were created for the same partner. After this fix: - Entry: Dr 131 (Receivable) / Cr 511 - Deferral: Dr 511 / Cr 3387 (Current Liabilities) 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#237493
This update fixes a bug that prevented users with multiple company employees from correctly creating helpdesk tickets. The change ensures that resources are filtered by company to avoid incorrect working interval calculations, preventing errors and ensuring accurate ticket creation for all users.
Original PR description
after https://github.com/odoo/enterprise/commit/6268dbaf07d742b5371a08dbf9f2dbb5fc0f8ce5 when computing working intervals for users, we filter resources by company to avoid concidering resources from employees in other companies different than the helpdesk team one. the method `_get_working_user_interval` is overriden in `helpdesk_holidays` and was not updated to follow same logic, which lead ro a traceback when a user with multiple employees in different companies was assigned is part of a helpdesk team and you try to create a ticket for that team. this commit fix the issue and add a test case covering this scenario. opw-5223717
This update fixes a performance issue within Odoo's PDF viewing functionality. By upgrading the PDF.js library to version 4.8.69, Odoo now handles corrupted PDF files more reliably, preventing potential infinite loops. This ensures a smoother and more stable user experience when uploading and viewing PDFs.
Original PR description
This commit updates the PDF.js library to patch the issue related to: https://github.com/mozilla/pdf.js/pull/18878 In Odoo this issue raises a performance issue that makes a infinite loop when you upload a corrupted file and Odoo tries to upload a traceback. OPW-5214755 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses a performance issue in the sign module related to corrupted PDF uploads. By updating the PDF.js library, Odoo now prevents an infinite loop and traceback errors that could occur when processing damaged files. This improves the overall reliability of the sign process.
Original PR description
Modification of module to align it with the newer version This commit updates the PDF.js library to patch the issue related to: mozilla/pdf.js#18878 In Odoo this issue raises a performance issue that makes a infinite loop when you upload a corrupted file and Odoo tries to upload a traceback. OPW-5214755
This update corrects a bug in the l10n_es_edi_tbai module that prevented the correct generation of the `FechaOperacion` field in TBAI XML invoices. Specifically, when the invoice date and delivery date are set to a past date, the `FechaOperacion` was missing. This ensures compliance with TicketBAI specifications and accurate tax reporting.
Original PR description
**[FIX] l10n_es_edi_tbai: fix FechaOperacion** With l10n_es_tbai: - Create an invoice with an `invoice_date` and `delivery_date` that are the same and earlier than today. - In the generated TBAI XML, `FechaOperacion` is missing. In the TBAI XML, `FechaExpedicionFactura` corresponds to the date on which the XML is generated. `FechaOperacion` corresponds to the `delivery_date` and should appear whenever it differs from the issue date. The TicketBAI specs define `FechaOperacion` as: > “Date on which the transaction was carried out, whenever it differs from the issue date.” So when the invoice date and delivery date are equal but set in the past, `FechaOperacion` is not generated, even though it should be. opw-4477135 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235563
A bug prevented the correct calculation of working time for tasks when a company's public holiday was active. Switching between companies with time off created an incorrect working time assignment. This fix ensures that working time is accurately calculated based on the company's holiday status.
Original PR description
__ ## Short functional explanation of the error Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in…
__ ## Short functional explanation of the error Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in company A, then switch back to company B. In company B, we create a project and a task, and assign this task. The working time to assign will stay at 0. ## Reproduction Steps 1. Switch to company A and create a timeoff starting before today and ending later. 2. Switch back to company B. Create a project, a stage and a task. 3. Enable the debugger. 4. The field Working Time to Assign is invisible by default, so open studio, click on View, and check Show Invisible Elements. 5. Click on the tab Extra info and on the block Working time to assign. Uncheck Invisible. 6. Close studio and assign someone to the task. Make sure that you do this operation at a different time than the one recorded for the last stage change. ### Expected behavior The hours under Working Time to Assign should compute the difference between the last time the task got its stage changed and the time of assignation ### Unexpected behavior Nothing happens ## Origin of the issue When computing the working time to assign, we also take into consideration leaves: if this happened during public holidays, we consider that it took no working time to get assigned. However, when a holiday is set in another company, the Working Time to Assign duration will be impacted, as the domain to retrieve the corresponding leaves is the following: https://github.com/odoo/odoo/blob/c7e965a61b7ce856c2daa8e2574cf4c60caf7a20/addons/resource/models/resource_calendar.py#L537-#546 The company isn't taken into account in the domain, applying the holiday for every company. _________________________________________ opw-5222883
This update ensures that downpayment taxes, when calculated externally (like with Avatax), use the correct downpayment account set on the product category – aligning with standard Odoo downpayment behavior. Previously, invoices incorrectly used the default income account, leading to inaccurate tax calculations. This change improves tax accuracy and consistency.
Original PR description
**Problem:** When calculating taxes externally (such as Avatax) and a downpayment is made, the line on the invoice will always use the default income account, regardless of the downpayment account set as a company default. This is inconsistent with the standard behavior of downpayments, which will use the downpayment account set on the product's category instead of the income account (which themselves may come from company defaults). **Solution:** Check if there's a company default for downpayment account on product category and use this account for the downpayment line instead of the income account. opw-5171067
This update resolves an issue where the server logger was experiencing excessive logging activity, leading to potential performance slowdowns. The change reverts a recent adjustment to the logging interval, restoring it to a more stable setting to ensure reliable and efficient logging of system events. This improves overall system stability and responsiveness.
Original PR description
Based on this review of https://github.com/odoo/odoo/pull/238740 this pr reverts the flush interval to 0.5s introduced in https://github.com/odoo/odoo/pull/238648 to avoid queue saturation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238912
This update resolves an issue where removing a video URL in the website editor would create a broken link, resulting in a 404 error. The fix ensures that the 'Add' button is disabled when a video URL is empty, preventing the creation of invalid links and improving the user experience. This ensures videos display correctly.
Original PR description
*=website **Steps to reproduce:** 1. Drop a video 2. Reopen the media dialog 3. Remove the URL 4. Confirm **Issue:** When the URL was removed and confirmed, an iframe without a valid source was saved, leading to a 404 error. **Fix:** When the video URL is cleared, VideoSelector component calls selectMedia with an empty object. MediaDialog did not previously handle this case, so the media selection was not cleared. Now we Update MediaDialog to treat an empty object as a clear-selection signal and disable the Add button accordingly. task-5190485 Forward-Port-Of: odoo/odoo#234085
This update resolves a potential memory error that could occur during Odoo installation on databases with many existing accounting records. The change ensures that new fields are initialized correctly, preventing the system from running out of memory and improving installation speed and stability. This primarily affects users with large accounting databases.
Original PR description
Description ----------- On databases with a large count of existing `account.analytic.line` records, installing modules like `hr_timesheet`, which adds compute stored or related stored fields to this model can trigger a memory error due to the volume of records that need to be recomputed. This commit creates the columns manually with the correct default value that is inferred from the state and implementation of said fields. Reference --------- opw-5234833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where new employees were incorrectly generating timesheets due to a misconfiguration with time off entries. The change ensures that only global time offs are considered, resolving this problem and improving timesheet accuracy for all employees.
Original PR description
**Steps to reproduce** 1. Have a future `resource.calendar.leaves` without a `calendar_id` but with a `resource_id`. To achieve this, you can for example install Payroll and Attendance, create a contract with the work entry source being attendances and with no working schedule. Then, create a time off in hours for that employee and validate it. In that case, the `hr.leave` has no `resource_calendar_id` as computed in `_compute_resource_calendar_id`. This leads to a `resource.calendar.leaves` record without a `calendar_id` once the time off is validated. 2. Create a new employee. A timesheet corresponding to the previously created time off is created. **Change** Make sure only global time offs are considered. opw-5248992
This update fixes an issue where outdated sub-channels were incorrectly unpinned, leading to unnecessary email notifications. The change now prevents unpinning sub-channels if there are still unread messages, ensuring users can easily access important threads. This improves the overall email experience.
Original PR description
Before this commit, outdated sub-channels were unpinned each time the vacuum ran. It occurs because a condition on sub-channel being pinned is missing. In practice, it's not a big deal funtionnaly but leads to useless notifications being sent. While at it, this PR prevents unpins when there are still unread messages in the sub-channel: the pin feature is used to see unread messages on otherwise hidden threads.
This update resolves a technical error within the Luxembourg payroll module (l10n_lu_hr_payroll) where a duplicate method was present. This fix ensures the payroll calculations are accurate and reliable, preventing potential discrepancies in employee payments.
Original PR description
There was a duplicate method in hr_payslip.py of Luxembourg Loca. Runbot error: 234334 Task: 5391399
This update resolves an issue preventing errors when sending vendor bills to eTIMS. The problem was triggered by removing product names or descriptions from the bill. This fix ensures smooth eTIMS integration for Kenyan businesses using the l10n_ke_edi_oscu module.
Original PR description
Backport of commit https://github.com/odoo/enterprise/pull/77750/commits/ed19d1db79d8ea3a228eee15b02dd8668123dd3c Because the issue is also reproducible in 18.0 using the same steps (removing the product name and the product description). sentry-7027319462
This update resolves an issue where a warning banner appeared during SEPA batch payments if a linked employee lacked an address. The change ensures the system correctly generates XML reports using the employee's address, even when the primary partner's address is missing. This improves the reliability of batch payment processing.
Original PR description
…oyee has an address Doing batch payment for sepa payment would generate a warning banner if the partner has no address ( city and country ) However in reality ( already working ) the xml report will be generated with the linked employee address in the case of absence of the partner address thus it should not show a warning. The change removes the warning in this case. task: 5266346 Forward-Port-Of: odoo/enterprise#99928
This update fixes a calculation error in the MRR evolution dashboard that was incorrectly double-counting 'Contraction'. The change ensures the 'Net new' figure accurately reflects subscription growth by properly accounting for contraction trends. This improves the dashboard's reliability for tracking revenue.
Original PR description
…traction **Issue** The formula defined for the "Net new" in the MRR evolution dashboard double counted the "Contraction", as it is already included in the "Up/Downgrade" (cell B6, equal to B4+B5, "Contraction" + "Expansion"). <img width="360" height="354" alt="image" src="https://github.com/user-attachments/assets/0a19a86a-f1b9-462f-812c-71a283f6fe89" /> opw-4925930 Forward-Port-Of: odoo/enterprise#96878
This update allows administrators to prevent automatic module installation during database upgrades, addressing potential upgrade failures caused by outdated modules. This enhances stability and ensures business logic functions correctly, particularly after module uninstalls or new stable releases.
Original PR description
In some case, a database can be in a state where some auto install module are not installed - when the user uninstall a module - when module was added in stable and a database was created before the…
In some case, a database can be in a state where some auto install module are not installed - when the user uninstall a module - when module was added in stable and a database was created before the addition. It can lead to issues where an upgrade fails or some business logic does not work as expected because of the missing modules. This is not easy to reproduce and to test, even if uninstalling such module should in theory work and be tested. This pr proposes to add a flag "--skip-auto-install" to the config to be able to disable all auto install of modules. It is open to discussion to change this to a config option, with or without a module list **Initial solution (alternative to avoid a config)** --dev skipautoinstall **Current solutions** (command line param) --skip-auto-install **Maybe in the future but unlikely** (more flexible) --skip-auto-install=all --skip-auto-install=web_enterprise,iap (krma suggestions) --skip-auto-install=* --skip-auto-install=web_*,iap Those two last one could be more flexible but the use case are limited and can be done another way with an explicit -i, maybe no worth the additional complexity (mainly since we need to filter in two different places) Note that this pr uses **get** on the config just in case the config is monkey patched somewhere to make it more robust. Forward-Port-Of: odoo/odoo#234710
This update improves how Odoo determines the file type (mimetype) of large documents like .docx files. Previously, the system incorrectly identified these files as 'application/zip' when using the python-magic library. Increasing the amount of data sent to the guesser function resolves this issue, ensuring accurate file type detection for all document types, especially large ones.
Original PR description
### Description of the issue/feature this PR addresses: The current number of bytes (1024) sent to the mimetype guesser function is not enough for a correct guess on big .docx files (maybe other open…
### Description of the issue/feature this PR addresses: The current number of bytes (1024) sent to the mimetype guesser function is not enough for a correct guess on big .docx files (maybe other open office files too) whenever `python-magic` is installed. If `python-magic` is not installed, it falls back to a [simpler implementation (by odoo)](https://github.com/odoo/odoo/pull/233266/files#diff-706296f6593337a9ff88c0e33e0e090eec75f63a22f9825dd31833ba17922840R145) that actually works correctly. But in odoo.SH it seems that `python-magic` is always installed and in that case, it returns the mimetype "application/zip" for big .docx files. The issue is not reproducible in runbot, so I'm assuming `python-magic` is not present in that environment. I've tested it with double the amount of bytes and it seems to work correctly. Please check the [following ticket](https://www.odoo.com/odoo/project.task/5125592) for more details. ### Current behavior before PR: <img width="1141" height="674" alt="image" src="https://github.com/user-attachments/assets/a3d28757-c55a-4b0f-9ee5-042777943635" /> ### Desired behavior after PR is merged: The uploaded file's mimetype is correctly identified for big (>40mb) open office files. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233266
9 changes
Enhancements to existing features
This update aligns Odoo's accounting system in Vietnam with new Vietnamese regulations (TT 99/2025/TT-BTC). The previous accounting system (TT 200/2014/TT-BTC) is now outdated and this change ensures compliance with current tax laws. This update impacts financial reporting and accounting processes within the Odoo system for Vietnam.
Original PR description
[TT 99/2025/TT-BTC](https://thuvienphapluat.vn/phap-luat/ho-tro-phap-luat/toan-van-thong-tu-992025ttbtc-che-do-ke-toan-doanh-nghiep-thay-the-thong-tu-200-tu-01012026-ra-sao-239165.html) replace TT 200/2014/TT-BTC outdated at 01/01/2026 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This change prevents distracting audio notifications during local testing of Odoo. Previously, unexpected beeps and ringtones could interrupt the testing process. This improvement ensures a smoother and more reliable testing experience.
Original PR description
When running tests locally, it's really annoying (and sometimes really jarring / surprising) to hear random beeps and boops from your machine, especially when it's an old timey ringtone from voip. Make it stop. Forward-Port-Of: odoo/odoo#238882
This update resolves an issue preventing users from renaming the "Help" menu item in the Helpdesk module. Previously, a system error blocked renaming, even without attempting to modify the URL. Now, users can freely change the menu item's name, improving usability and flexibility.
Original PR description
**Issue** It was not possible to rename the "Help" menu item, an error appeared with the message: "This URL is reserved for the helpdesk teams with 'website form' feature enabled.", even if the user was not trying to edit the URL. **Change** Allow the user to edit the menu item's name. opw-5375334
This update fixes a technical error that was causing tracebacks when sending snail mail for documents other than the standard followup report. The issue stemmed from a misconfiguration in the code, and this change corrects that to ensure reliable snail mail functionality. This resolves a potential disruption to our mail delivery process.
Original PR description
Currently there is a traceback when sending snailmail for anything that is not the followup report. The call to the super function has the wrong name and misses an argument The issue was introduced in this commit 08ec299cf2b06cd900f84be0a95b5917abe7d453 . task-None
This change reverts a recent update to Odoo's portal access functionality. The original fix, intended for newer versions, wasn't stable for Odoo 17. This ensures continued stability and functionality for existing Odoo 17 users regarding portal access management.
Original PR description
**Issue:** Active check is needed when granting access to a previous portal user which was archived. But changing the template to fix this is not stable for previous versions. **Fix:** Reverted https://github.com/odoo/odoo/pull/233757 in 17.0 (Fixed with https://github.com/odoo/odoo/pull/236462 in 18.0+) -> reverted as well for now https://github.com/odoo/odoo/pull/239477 opw-4760550
This update resolves an issue in the l10n_se_sie_import module related to how SHA512 hashes are generated. The fix ensures that SHA512 hashing is performed correctly, improving the reliability of data import processes for Swedish SIE files. This prevents potential errors during data synchronization.
This update corrects a formatting error in the invoice report for KE (Kenya) invoices. Previously, the total and taxable amounts lacked proper currency formatting (commas). The fix removes a duplicate XPath and applies the correct formatting options, ensuring invoices display accurate price values.
Original PR description
Steps to reproduce: 1. install `l10n_ke` 2. Switch to KE Company 3. Create a product with all KRA eTIMS details set on the Accounting page. 4. Create an invoice to KE Company with that product and set unitprice > 10000 5. Confirm the invoice and send it. Now, see the invoice report Issue: 1. xpath for `td_subtotal` was duplicated 2. The total amount and taxable amount were not formatted as prices (no commas). Before: <img width="771" height="397" alt="image" src="https://github.com/user-attachments/assets/492fe911-18d6-4e01-a16d-d7450c17373f" /> After: <img width="766" height="389" alt="image" src="https://github.com/user-attachments/assets/bbe5d4e2-b337-445c-833a-06492a8c827d" /> Solution: Updated the invoice report to: - Remove the duplicated `td_subtotal` xpath. - Properly format the total and taxable amounts with `t-options`. opw-5341578
This update resolves a potential error that caused invoices to fail during confirmation when specific currency and pricing settings were used. The fix prevents a division-by-zero error, ensuring invoices can be processed correctly under these circumstances. This improves the reliability of the invoicing process.
Original PR description
Steps to reproduce:
--------------------
1. Install l10n_cl and switch to the CL company
2. Create a new invoice:
- Change the currency to a value different from the company currency
(e.g., from CLP to USD)
- Add an invoice line with a price value of 0
- Remove the default tax value
3. Try to confirm the invoice
Issue:
------
A traceback occurs:
`ZeroDivisionError: float division by zero`
Cause:
------
Since the price value is 0, the `amount_total` of the move becomes 0.
When computing the currency rate, it tries to divides by `amount_total`, resulting in a ZeroDivisionError.
Solution:
---------
Add a conditional check before division to ensure the `amount_total` is non-zero
Related enterprise PR: https://github.com/odoo/enterprise/pull/99518
opw-5247058
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes a potential error that could prevent invoices from being confirmed when specific currency and pricing settings are used. The fix adds a check to avoid division by zero, ensuring invoices can be processed correctly. This improves invoice processing reliability and prevents disruptions to financial workflows.
Original PR description
Steps to reproduce: -------------------- 1. Install l10n_cl and switch to the CL company 2. Create a new invoice: - Change the currency to a value different from the company currency (e.g., from CLP to USD) - Add an invoice line with a price value of 0 - Remove the default tax value 3. Try to confirm the invoice Issue: ------ A traceback occurs: `ZeroDivisionError: float division by zero` Cause: ------ Since the price value is 0, the `amount_total` of the move becomes 0. When computing the currency rate, it tries to divides by `amount_total`, resulting in a ZeroDivisionError. Solution: --------- Add a conditional check before division to ensure the `amount_total` is non-zero Related community PR: https://github.com/odoo/odoo/pull/235252 opw-5247058