Daily updates from Odoo
Navigate
Branch
Monday, September 9, 2024
64 changes
23 changes
Enhancements to existing features
This update moves Odoo's web test pages to the newer testing system and keeps legacy test pages available separately. It also fixes several testing-tool behaviors around clicks, touch events, screen sizing, and sidebar layout, helping teams validate web changes more reliably.
Original PR description
New PR: https://github.com/odoo/odoo/pull/179660
Resolved issues and error corrections
Updates the website editor's automated checks to better catch issues during page editing. This helps reduce the chance of regressions reaching users and supports more reliable website publishing workflows.
Original PR description
TODO runbot-60056
Changing the language from My Profile could trigger an error when an unsaved invoice screen was open. This fix prevents that crash, allowing users to save their profile language preference without interruption.
Original PR description
When the user changes the language in My Profile and tries to save, a traceback will appear. Steps to reproduce the error: - Install ```account_accountant``` and ```hr``` module - Activate multi…
When the user changes the language in My Profile and tries to save,
a traceback will appear.
Steps to reproduce the error:
- Install ```account_accountant``` and ```hr``` module
- Activate multi languages
- Go to accounting > Dashboard > New Invoice
- Click on the profile icon > My Profile > Change language > Save
Traceback:
```
ValueError: too many values to unpack (expected 1)
File "odoo/models.py", line 5851, in ensure_one
_id, = self._ids
ValueError: Expected singleton: account.move('n', 'e', 'w')
File "odoo/http.py", line 2254, in __call__
response = request._serve_db()
File "odoo/http.py", line 1829, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1849, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1827, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1834, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2059, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/action.py", line 96, in load_breadcrumbs
display_names.append(Model.browse(record_id).display_name)
File "odoo/fields.py", line 1202, in __get__
record.ensure_one()
File "odoo/models.py", line 5854, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
https://github.com/odoo/odoo/blob/59985860264f7fbd2726a51ff15d7e5101ae8234/addons/web/controllers/action.py#L97
Here, when the user changes the language and tries to save the record.
we received record_id as ('n', 'e', 'w'),
when it tries to access display_name
So it will lead to the above traceback.
This issue is similar to https://github.com/odoo/odoo/pull/163087
sentry-5135218331
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes stock transfer issues where inter-company moves could update the wrong destination location, helping keep inventory quantities accurate. It also removes duplicate lot/serial number fields in receipt details when both creation and existing lot options are enabled, reducing confusion for warehouse users.
Original PR description
Fixes the following issues: - When moving products to the 'Inter-company transit' location, products were effectively moved to the 'Customers' location instead. - ~Unable to see lots/serial numbers in locations having no company, such as the 'Customers' location.~ - Duplicate 'Lots/Serial numbers' field in the move details if both 'Create New' & 'Use Existing One' options are picked in the reception picking type. - ~'No operation made on this lot.' is always displayed in the traceability report after a reload, requiring to leave then re-enter the report instead.~ More information on each issue in its corresponding commit. task-3853055 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The /help command in Discuss now includes canned response guidance, matching the behavior users already had in live chat. This makes the feature easier to discover and use wherever canned responses are available.
Original PR description
Since the canned response settings is introduced in Discuss, the usage of canned responses is not limited to livechat only, so that the /help message should be available in the Disucss as well. after:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now handles mailing list contacts without a name when an email fails to send. This prevents a traceback when users open the contact record after a failed mailing, improving reliability for mass mailing workflows.
Original PR description
Steps to reproduce: --- 1. Install mass_mailing 2. Create a wrong outgoing mail server 3. ip 127.0.0.1 port 1234 4. Create a mailing list 5. Create a mailing list contact without name 6. Make the contact join the list 7. Create a mailing, set the new mailing list 8. Click on send > "1 email(s) not sent." 9. Open the mailing list contact 10. Traceback Cause of the issue: --- Caused by: https://github.com/odoo/odoo/commit/5102328c3dd6e4e751ca8f906e7bd16e190fc386 `this.originThread?.name` can be `False` instead of `Undefined` opw-4054564 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
If we have two bills with the same bill ref and two different partner, one with NIF and the other without it, the schedule action to process SII response might fail since the code expect a NIF in the SII response when there is not (bill with partner without NIF). Technical example: ```py >>> partner_info # Candidate invoice in odoo {'IDOtro': {'ID': 'NO_DISPONIBLE', 'IDType': '06', 'CodigoPais': 'ES'}} >>> respl_partner_info # SII response {'NIF': '12345678K', 'IDOtro': None} ``` This
Original PR description
If we have two bills with the same bill ref and two different partner, one with NIF and the other without it, the schedule action to process SII response might fail since the code expect a NIF in the…
If we have two bills with the same bill ref and two different partner, one with NIF and the other without it, the schedule action to process SII response might fail since the code expect a NIF in the SII response when there is not (bill with partner without NIF).
Technical example:
```py
>>> partner_info # Candidate invoice in odoo
{'IDOtro': {'ID': 'NO_DISPONIBLE', 'IDType': '06', 'CodigoPais': 'ES'}}
>>> respl_partner_info # SII response
{'NIF': '12345678K', 'IDOtro': None}
```
This causes a rollback and no bills at all are processed in Odoo's side.
Steps to reproduce:
1/ Create a l10n_es company with l10n_es_edi_sii in test mode
2/ Create a bill with a bill reference 10001, some lines (ex: negative lines)
that will trigger an error from SII and a partner with a NIF
3/ Copy the partner and remove the NIF
4/ Copy the first bill, keep the same bill reference and change the partner to
copied one
5/ Post both bills
6/ Trigger the schedule action "EDI : Perform web services operations" => Traceback with
ValueError: <class 'AttributeError'>: "'NoneType' object has no attribute 'ID'" while evaluating
Now, a default value is set when the key is not found in respl_partner_info.IDOtro .
opw-4102638
Forward-Port-Of: odoo/odoo#177902Currently, when adding product rewards to an order, you are rewarded with the maximum amount of products you can get with you current points. If you change the quantity of the reward product, the reward lines does not update. Steps to reproduce: ------------------- * Go to the **Point of sale** App * Open Shop session * Select a customer that has plenty of loyalty points * Put any product in the order * Add the reward `Simple pen` (you'll havelike 230 of them) * Try changing the reward
Original PR description
Currently, when adding product rewards to an order, you are rewarded with the maximum amount of products you can get with you current points. If you change the quantity of the reward product, the…
Currently, when adding product rewards to an order, you are rewarded with the maximum amount of products you can get with you current points. If you change the quantity of the reward product, the reward lines does not update. Steps to reproduce: ------------------- * Go to the **Point of sale** App * Open Shop session * Select a customer that has plenty of loyalty points * Put any product in the order * Add the reward `Simple pen` (you'll havelike 230 of them) * Try changing the reward quantity to 1 > Observation: The quantity of the simple pen changes to 1 but the negative reward line still shows 230. Thus, the order can have a negative amount since 229 pens are still being deducted from the order even though they are not present. Why the fix: ------------ This commit https://github.com/odoo/odoo/commit/de45ff3c9f23decdab176bc1511b3356d19844a8 passes the quantity and cost (in points) to the `_applyReward` function. This was done because when recomputing reward lines, if two lines came from the same reward, the quantity would be merged even though they would not apply on the same product. In our case, this causes problems as we are using the function `_getRewardLineValuesProduct` to update the reward quantity but the quantity (230) is given as an argument and is then used as the quantity to set. https://github.com/odoo/odoo/blob/775827b8f7fa95f2afd77a9b42d6cd8e436ea690/addons/pos_loyalty/static/src/overrides/models/loyalty.js#L1548-L1566 `args["quantity"] || freeQuantity` will always use `args["quantity"]` if given, bypassing the maximum quantity that is available to give. `freeQuantity || args["quantity"]` will never use `args["quantity"]`. Since we do not want to reward more than what is available, we add the arguments inside the `Math.min` function. opw-4103833 Forward-Port-Of: odoo/odoo#178805
Current behavior before PR: 1. When we attempt to paste an H1 element into a P element, the H1 element gets converted to a P element. 2. When pasting from GDocs, nested UL or OL is a direct child of its parent UL or OL, rather than being child of LI with class `oe-nested`. 3. Copy/pasting multiple paragraphs into a list does not convert it to list. 4. When pasting content that begins with a list and includes other tags below it into a new list, only the list is pasted, resulting in a loss
Original PR description
Current behavior before PR: 1. When we attempt to paste an H1 element into a P element, the H1 element gets converted to a P element. 2. When pasting from GDocs, nested UL or OL is a direct child of…
Current behavior before PR: 1. When we attempt to paste an H1 element into a P element, the H1 element gets converted to a P element. 2. When pasting from GDocs, nested UL or OL is a direct child of its parent UL or OL, rather than being child of LI with class `oe-nested`. 3. Copy/pasting multiple paragraphs into a list does not convert it to list. 4. When pasting content that begins with a list and includes other tags below it into a new list, only the list is pasted, resulting in a loss of the other content. 5. Copy/pasting one list over another bullets does not get transformed. 6. When copying a checklist from Google Docs, the check options are pasted as images. Desired behavior after PR is merged: 1. When we attempt to paste an H1 element onto a P element, the H1 element will remain as an H1 element. 2. When pasting from GDocs, nested UL or OL are contained within an LI element with class `oe-nested`. 3. Copy/pasting multiple paragraphs into a list gets converted to list. 4. Pasting content with a list and other tags should no longer result in the loss of content. 5. Copy/pasting one list over another bullets get transformed. 6. Check options copied as image from Google Docs will no longer be pasted as images; instead the images should be removed and class `o_checklist` should be add to the closest list. task-2956048 Co-authored-by: Deependra Solanki <deso@odoo.com> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179159 Forward-Port-Of: odoo/odoo#115019
Partners can have multiple Bank accounts in an active database, some being even added automatically on Bank reconciliation. But usually, only some specific accounts that are used for outgoing payments will be marked as "trusted". Currently, when you select a Vendor on a draft Vendor Bill, the first account of the partner is taken, whether or not the account is trusted. This Pr will give priority to the accounts that are trusted. task: 4166740 --- I confirm I have signed the CLA a
Original PR description
Partners can have multiple Bank accounts in an active database, some being even added automatically on Bank reconciliation. But usually, only some specific accounts that are used for outgoing payments will be marked as "trusted". Currently, when you select a Vendor on a draft Vendor Bill, the first account of the partner is taken, whether or not the account is trusted. This Pr will give priority to the accounts that are trusted. task: 4166740 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179365
Steps to reproduce: * install `l10n_mx` * Create a partner * duplicate it * upload an invoice/bill xml with the duplicated partner Issue: A new duplication of the partner will be created Cause: If no partner is found, we will create another one https://github.com/odoo/enterprise/blob/c66a452661c1e5ff9f837e7e1e21e068fec4c124/l10n_mx_edi/models/account_move.py#L2524-L2545 Solution: The VAT should be a sufficiently distinctive criterion to link a partner Ticket [link](https://www
Original PR description
Steps to reproduce: * install `l10n_mx` * Create a partner * duplicate it * upload an invoice/bill xml with the duplicated partner Issue: A new duplication of the partner will be created Cause: If no partner is found, we will create another one https://github.com/odoo/enterprise/blob/c66a452661c1e5ff9f837e7e1e21e068fec4c124/l10n_mx_edi/models/account_move.py#L2524-L2545 Solution: The VAT should be a sufficiently distinctive criterion to link a partner Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4124253) opw-4124253 Forward-Port-Of: odoo/odoo#178078
This commit fixes the error that was triggered when trying to assign a responsible user for a picking batch from the kanban view of batches. The error was thrown because the `user_id` field depends on `company_id` field in its domain, which was not existent in the kanban view. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179179
Original PR description
This commit fixes the error that was triggered when trying to assign a responsible user for a picking batch from the kanban view of batches. The error was thrown because the `user_id` field depends on `company_id` field in its domain, which was not existent in the kanban view. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179179
Issue : 17.0 When a global discount is applied on a sale order with tax included in the price, the discount was incorrectly calculated based on the tax-excluded price. This resulted in inaccurate discount amounts and incorrect tax calculations. steps to reproduce: - Create a tax with included in price (e.g. 10% incl). - Create a sale order with the 10% incl tax. - Now, apply a global discount (e.g. 10%) Cause : When applying a global discount, the system incorrectly calculates the d
Original PR description
Issue : 17.0 When a global discount is applied on a sale order with tax included in the price, the discount was incorrectly calculated based on the tax-excluded price. This resulted in inaccurate discount amounts and incorrect tax calculations. steps to reproduce: - Create a tax with included in price (e.g. 10% incl). - Create a sale order with the 10% incl tax. - Now, apply a global discount (e.g. 10%) Cause : When applying a global discount, the system incorrectly calculates the discount based on the tax-excluded price rather than the unit price. Fix : Ensure the total amount is calculated useing price_unit(price_unit) instead of subtotal. This corrects the discount application and maintains accurate pricing. opw-4018841 Forward-Port-Of: odoo/odoo#174678
Steps to reproduce ================== - Go to Sales > Quotation - Open any record - Open studio - Switch to the x2many list view - Insert a new html field - Exist studio - Type some text in the html field - Select a portion of it - Click on the bold button => Nothing happens Solution ======== Don't unselect the current row when clicking inside the editor toolbar opw-4064662 Forward-Port-Of: odoo/odoo#178189 Forward-Port-Of: odoo/odoo#175880
Original PR description
Steps to reproduce ================== - Go to Sales > Quotation - Open any record - Open studio - Switch to the x2many list view - Insert a new html field - Exist studio - Type some text in the html field - Select a portion of it - Click on the bold button => Nothing happens Solution ======== Don't unselect the current row when clicking inside the editor toolbar opw-4064662 Forward-Port-Of: odoo/odoo#178189 Forward-Port-Of: odoo/odoo#175880
We don't need `point_of_sale` module on the IoT Box: we only need configuration files in it. We don't load it anymore to prevent from having error messages on service start. We also added a new alias to simplify pip usage and removed unused pyotp package. Forward-Port-Of: odoo/odoo#179308
Original PR description
We don't need `point_of_sale` module on the IoT Box: we only need configuration files in it. We don't load it anymore to prevent from having error messages on service start. We also added a new alias to simplify pip usage and removed unused pyotp package. Forward-Port-Of: odoo/odoo#179308
Before this commit, copying an automation rule did not copy its actions. After, it will. Task: 4055597 Forward-Port-Of: odoo/odoo#179350
Original PR description
Before this commit, copying an automation rule did not copy its actions. After, it will. Task: 4055597 Forward-Port-Of: odoo/odoo#179350
### Description of the issue/feature this PR addresses: Wrong account on tax definition. Taxes should not have related payable and receivable accounts. ### Current behavior before PR: VAT 0% Exempt taxes has a payable account, this not valid one and will result on error when creating an invoice with that tax. We resolve the problem by changing the account used on the tax definition with new accounts, one for Sales (Current liabilities) and another for Purchase (Current Aseste), the sam
Original PR description
### Description of the issue/feature this PR addresses: Wrong account on tax definition. Taxes should not have related payable and receivable accounts. ### Current behavior before PR: VAT 0% Exempt taxes has a payable account, this not valid one and will result on error when creating an invoice with that tax. We resolve the problem by changing the account used on the tax definition with new accounts, one for Sales (Current liabilities) and another for Purchase (Current Aseste), the same way is made for the VAT 22% and VAT 10%) ### Desired behavior after PR is merged: Taxes has the proper account and we are able to create invoices/bills with tax 0% without problem ADHOC ticket 76475 - task 34060 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170773
In makeAsyncHandler and makeButtonHandler have been modified in commit fcb16a3b1bd373726ffb54f0fbe41fb6d1784769 to remove guardedCatch. However, in both cases, if result is rejected, Promise.resolve(result) will (quite unexpectedly because of the name of the method) be rejected too. Calling finally on this promise will indeed call the callback, but it will still let the exception bubble up, eventually resulting in a second unhandledrejection for the same original exception. With this commi
Original PR description
In makeAsyncHandler and makeButtonHandler have been modified in commit fcb16a3b1bd373726ffb54f0fbe41fb6d1784769 to remove guardedCatch. However, in both cases, if result is rejected,…
In makeAsyncHandler and makeButtonHandler have been modified in commit fcb16a3b1bd373726ffb54f0fbe41fb6d1784769 to remove guardedCatch. However, in both cases, if result is rejected, Promise.resolve(result) will (quite unexpectedly because of the name of the method) be rejected too. Calling finally on this promise will indeed call the callback, but it will still let the exception bubble up, eventually resulting in a second unhandledrejection for the same original exception. With this commit, we instead call then(callback, callback) on that Promise, so that the rejection is caught and callback is indeed called in both cases. To reproduce this issue in saas-17.4, raise a UserError in the route /website_sale/should_show_product_configurator and add a Drawer to your cart: the exception message is displayed twice. This reproduction doesn't work in 17.0 because the promise is a dialog.opened() that crashes and never resolves, masking the issue (but there is a hint of this, because the loading effect is also never removed from the button (meaning that the callback of makeButtonHandler is never called). Many thanks to MCM to help me understand what was happening here. Forward-Port-Of: odoo/odoo#179512
[FIX] project: restrict access to project in email sent Before this commit, when the `Project Stages` feature is enabled and the user set an email template on a project stage, if the user moves a project to that stage with the email template, an email is sent to the customer (if set on the project) and the customer can click on the project name to see all tasks inside that project even if the project is private. This commit makes sure the project name displayed in the template is only
Original PR description
[FIX] project: restrict access to project in email sent Before this commit, when the `Project Stages` feature is enabled and the user set an email template on a project stage, if the user moves a…
[FIX] project: restrict access to project in email sent Before this commit, when the `Project Stages` feature is enabled and the user set an email template on a project stage, if the user moves a project to that stage with the email template, an email is sent to the customer (if set on the project) and the customer can click on the project name to see all tasks inside that project even if the project is private. This commit makes sure the project name displayed in the template is only clickable is the project visibility is 'portal' (`Invited portal users and all internal users`). Steps to reproduce: ------------------ 1. Install project 2. Go to Project > Configuration > Settings 3. Enable Project Stages feature 4. Set email template to project stage 5. Create a project with a customer set and project visibility is not set to "Invited portal users and all internal users". 6. Move the project to the project stage with the email template set. Current behavior: ---------------- An email is sent based on the email template set but the project name is clickable to allow the customer to see the tasks of the project in the portal even if the project is not public. Expected behavior: ----------------- The project name should not be clickable inside the email sent when the project visibility is not "Invited portal users and all internal users". Close #175396 Forward-Port-Of: odoo/odoo#178260 Forward-Port-Of: odoo/odoo#178171
Following commit https://github.com/odoo/odoo/pull/171765/files# multi-currencies are not supported anymore by our edi engine. Using a currency other than euro leads to an invalid XML file. Steps to reproduce: 1. install Italian E-invoicing 2. make sure your have access to another currency, along with EUR 3. create a partner outside of Europe (e.g. US-based - using USD) 4. create an invoice for that partner 5. confirm + send and print the invoice (generate XML file) 6. go to https
Original PR description
Following commit https://github.com/odoo/odoo/pull/171765/files# multi-currencies are not supported anymore by our edi engine. Using a currency other than euro leads to an invalid XML file. Steps to reproduce: 1. install Italian E-invoicing 2. make sure your have access to another currency, along with EUR 3. create a partner outside of Europe (e.g. US-based - using USD) 4. create an invoice for that partner 5. confirm + send and print the invoice (generate XML file) 6. go to https://www.fatturacheck.it/ to verify the XML 7. Error 2.2.2.5 should be returned opw-4038850 opw-4129380 opw-4123758 opw-4095910 Forward-Port-Of: odoo/odoo#175996
### Steps to reproduce: - In the settings: - Change the Barcode Nomenclature to Default gs1 - Enable Promotions, Coupons, ... on Point of sale - Create a prodcut with barcode 95412427100283 - Point of Sale > Product > Discount & Loyalty - Create a new discount and change the conditional rule to set your product and a min purchase of 0 - Open a new pos session - Scan the gs1 barcode 0195412427100283 #### > the product is found but the discount is not applied ### Expected behav
Original PR description
### Steps to reproduce: - In the settings: - Change the Barcode Nomenclature to Default gs1 - Enable Promotions, Coupons, ... on Point of sale - Create a prodcut with barcode 95412427100283 - Point…
### Steps to reproduce: - In the settings: - Change the Barcode Nomenclature to Default gs1 - Enable Promotions, Coupons, ... on Point of sale - Create a prodcut with barcode 95412427100283 - Point of Sale > Product > Discount & Loyalty - Create a new discount and change the conditional rule to set your product and a min purchase of 0 - Open a new pos session - Scan the gs1 barcode 0195412427100283 #### > the product is found but the discount is not applied ### Expected behavior: Just as if you scanned the barcode 95412427100283 directly the discount should be applied. Cause of the issue: When a barcode is scanned in the pos, the ` _scan` method is called to parse the barcode and to trigger the associated action: https://github.com/odoo/odoo/blob/775827b8f7fa95f2afd77a9b42d6cd8e436ea690/addons/point_of_sale/static/src/app/barcode/barcode_reader_service.js#L69-L79 This flow use to not update the rewards after a product scanned and was fixed by commit 21392ab when the barcode associated action is `_barcodeProductAction` because fo these lines: https://github.com/odoo/odoo/blob/775827b8f7fa95f2afd77a9b42d6cd8e436ea690/addons/pos_loyalty/static/src/overrides/components/product_screen/product_screen.js#L105-L107 however, if the code is identified to be gs1 Howecver, if the barcode is identified to be of the gs1 nomenclature it will trigger the `_barcodeGS1Action` which still does not update the rewards. ### Fix: Inspired by commit 21392ab opw-3813858 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178600
Loyalty programs discount could be applied on specific products through a domain. When putting a domain with a True or False as a third operand (e.g. ('is_available_in_pos', '=', True)), the PoS was crashing at launch because the domain goes through a json.dumps that changes the Boolean to lower case and then through ast.literal_eval that doesn't accept lower case Boolean. The change is to replace lower case Boolean to upper case Boolean in the domain before the ast.literal_eval. --- I co
Original PR description
Loyalty programs discount could be applied on specific products through a domain. When putting a domain with a True or False as a third operand (e.g. ('is_available_in_pos', '=', True)), the PoS was crashing at launch because the domain goes through a json.dumps that changes the Boolean to lower case and then through ast.literal_eval that doesn't accept lower case Boolean.
The change is to replace lower case Boolean to upper case Boolean in the domain before the ast.literal_eval.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#175805Problem: While merging two partners in the contact app using the _update_foreign_keys method, the foreign keys are merged using SQL instead of ORM. The issue is that the partner_share field is computed based on the user_ids field and is stored. If we update using SQL, it will not trigger the _compute_partner_share method, which will set the latest value. Other problems might arise for fields that are computed based on foreign keys updated using SQL during a merge. Steps to reproduce: I
Original PR description
Problem: While merging two partners in the contact app using the _update_foreign_keys method, the foreign keys are merged using SQL instead of ORM. The issue is that the partner_share field is computed based on the user_ids field and is stored. If we update using SQL, it will not trigger the _compute_partner_share method, which will set the latest value. Other problems might arise for fields that are computed based on foreign keys updated using SQL during a merge. Steps to reproduce: In a new database, create a basic contact (individual, with name and email). Merge this contact with another contact who has document access (e.g., Marc Demo). Go to any product page. Add a log note and tag the new contact. The contact will receive an email without the "View product" button. opw-3864317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175966
35 changes
New functionality added to Odoo
Users can now choose whether an Engineering Change Order should update a product version when it is applied. This gives teams more control over product lifecycle changes and avoids unnecessary version changes when an ECO does not require one.
Original PR description
With this Commit : -------------------------------------- -Introduced a new checkbox in the ECO form allowing users to choose whether to update the version when applying the ECO. -This feature provides greater flexibility for users by giving them control over version updates during the ECO process. Task id : 3962137
Adds new Belgian payroll export capabilities for Group S, with related foundations for other social secretariat providers such as Partena and UCM. This helps businesses prepare and send payroll information to external payroll partners more efficiently and consistently.
Original PR description
Create a new module to export payroll data for Group S. task-3957512
Enhancements to existing features
The contract form now always shows the salary attachment button, even when no attachments exist yet. Users can also create new salary attachments directly from the contract, making payroll setup and maintenance faster and more convenient.
Original PR description
This PR improves the contract form view by making the salary attachment button visible even when there are zero attachments. Additionally, it allows users to directly create new attachments from the contract form view. task-4096116
WhatsApp-related timezone handling now relies on standard fields instead of custom logic. This makes event registration messaging easier to maintain while keeping the expected timezone behavior intact.
Original PR description
Timezone fields can be inferred easily from a fixed list of fields. We add a related field on event registrations so it fits the heuristic, and remove the override to the method that previously defined the path to the timezone field. task-4095356
Approval request buttons now use adjusted colors to make the workflow easier to understand. This helps users quickly identify the right action and reduces confusion when processing approvals.
Original PR description
Buttons color have been adjusted to enhance the flow's understandability. task-3987625
This change adds support for the newer Font Awesome 6 icon set while keeping the existing Font Awesome 4 icons available. It helps preserve compatibility for current screens and customizations while enabling newer icon choices in the web interface.
Original PR description
https://github.com/odoo/odoo/pull/179626
Engineering changes can now be applied without automatically increasing the product or Bill of Materials version number. This gives teams more control over when version numbers change while keeping the existing automatic update behavior as the default.
Original PR description
Sometimes users don't want an ECO to affect the version number of a product/BoM when it is applied, so we add in the option to avoid it. By default we leave `will_update_version=True` so that the current behavior is still the default behavior. This involved manually updating code in several places to ensure this behavior occurs for many different flows including: - create BoM ECO from MO, - applying rebase/conflict resolve due to orig BoM change or new BoM created by another ECO - ECO for a product Note that: - the new BoM version will auto-update when the option is activated/deactivated so that the number matches the final applied version number and is easier for the user to keep track of it. - The Update BoM (for an out of date BoM) logic has been updated to consider newer BoMs with the same version number (i.e. we still expect the previous BoMs to still be archived like the previous flow) Task: 3962137
Colombian companies can now automatically retrieve daily currency exchange rates from Banco de la Republica. This reduces manual updates and aligns exchange rates with the source commonly used by local customers.
Original PR description
The Colombian localization does not have a provider for automatic currency rates yet. This commit implements the API of the Banco de la Republica (because most of the Colombian clients already use this rate) to get the daily rate. task: 4043989
This update renames a field used in India GSTR point-of-sale reporting to align with related reporting changes. It helps keep report terminology consistent and reduces confusion for users reviewing GST return data.
Original PR description
Related: https://github.com/odoo/odoo/pull/179265
The Documents app now avoids an extra server lookup when showing certain error dialogs. This reduces the risk of server overload when many errors happen at once and helps prevent repeated error loops.
Original PR description
This commit removes the orm call which provides the id of the support folder to the error dialog and replaces it by a simple isAdmin check. The reason for this change is that in case of multiple tracebacks triggered at the same time, it could overload the server with orm calls which could also trigger more tracebacks in an infinite cycle.
When the salesperson on a subscription is changed, the linked customer record is now updated to match. This keeps customer ownership aligned during subscription changes and when confirming subscription quotations, reducing manual follow-up and reporting mismatches.
Original PR description
Before this commit, when salesperson on subscription is changed we do not change salesperson for customer related to that subscription. After this commit, update salesperson on customer if salesperson on subscription is get changed. update salesperson on customer while confirming subscription quotation. task-3891309
The login page now only shows the user switch option when there is more than one available user. This keeps the sign-in experience simpler for single-user cases while still supporting quick switching when multiple users are available.
Original PR description
If there is only one user in user switch, don't display it and propose the login form. If there is more than one user, display the user switch. task-4160923
Resolved issues and error corrections
Studio exports no longer fail for databases that do not have the Website app installed. The export process now checks whether Website is available before looking for website-related data, preventing an unnecessary error for affected users.
Original PR description
**[FIX] web_studio: Fix export without website** This commit fixes a bug where we would always check for some website related fields and some records which causes an error when website was not installed. We now simply check that website is installed before checking the fields. This commit does not include a test as it would require to uninstall the website addon and the testing framework does not permit such a thing without introducing side effects.
Belgian SODA imports with incorrect VAT details will now continue instead of stopping the process. The system creates the journal entry and records VAT-related issues in the chatter, helping onboarding and testing proceed with clearer follow-up information.
Original PR description
The blocking message for importing a soda with wrong VAT is not needed as it blocks onboarding or testing. Instead of blocking, create the journal entry and log VAT related errors in the chatter. task-4072804
This update fixes an automated walkthrough used to verify the bank reconciliation interface. It helps keep accounting quality checks reliable, reducing the chance of unnoticed issues in future changes.
Resetting a report in Studio now also restores the header and footer layout configured on the company. This ensures reports return to the expected company branding when users choose to include the header and footer during a reset.
Original PR description
Set the external layout on the company. Edit a report that calls the "web.external_layout" template. In the report editor, hit reset report and include the header/footer. Before this commit, the company's layout was not reset. After this commit it is resetted. The reason was that the external_layout is actually selecting the company's layout via a dynamic t-call, which is ignored by the code that retrieves views. opw-4167257
The property field type selector now displays correctly inside its popover, instead of appearing with broken styling or behind other interface elements. This makes field configuration smoother and avoids confusion when users edit custom properties.
Original PR description
The dropdown inside the property field popover style was broken due to a dropdown refacor, some styles where not applied correctly and the field type dropdown was displayed behind the popover. (https://github.com/odoo/odoo/pull/137691). This PR fixes the issue in 2 commits: The first one adds a supplementary div around each overlay in the overlay container, this isolates each overlay so their z-index do not interfere, their order in the overlay-container is now sufficient to ensure a proper z-index, whatever the amount of popovers, modals, dropdowns, etc... The second adapts the property field style and removes now unnecessary custom z-index values. Community: https://github.com/odoo/odoo/pull/154021
The spreadsheet document tests were adjusted to match improved keyboard behavior in the pivot rename side panel. This helps ensure the Enter and Escape key actions continue to work reliably for users when renaming pivot elements.
Original PR description
With PR[1], we have added handlers for 'Enter' and 'Escape' key events in the pivot rename sidepanel. The test cases need to be updated accordingly. [1] https://github.com/odoo/o-spreadsheet/pull/4793 Task: 4080323
Code cleanup and technical improvements
Payroll accounting tests were reorganized so shared setup steps can be reused across country-specific payroll modules. Additional payslip validation checks were added for several localisations, helping reduce payroll calculation risks without changing day-to-day user workflows.
Original PR description
For tests in l10n_xx_payroll_account modules, we used the same util functions every time. These have now been moved to the hr_payroll_account module. This also adds a util function for setting up the usual employee, contract, etc. Task: 4040388
The demo kiosk setup has been moved from the IoT-specific self-order module into the main self-order module. This makes the sample kiosk experience available to more point-of-sale configurations, not only those using IoT.
Original PR description
We added a demo kiosk to the PoS in the `pos_self_order_iot` module, but now moved it to `pos_self_order` as it can benefit both. Community PR: [https://github.com/odoo/odoo/pull/178080](https://github.com/odoo/odoo/pull/178080)
The Mexican delivery EDI stock functionality has been consolidated into the main stock EDI module because the extended address data is now required for the feature to work. This simplifies module setup and ensures businesses using Mexican delivery EDI have the required data and validations available in one place.
Original PR description
To use the mexican delivery EDI, it is now required that we have the address field from the mx_edi_extended (the module that stock_extended previously additionally depends on). Using base mx_edi_stock without the extended module will not work anymore. With that in mind, it is now a good time to make the base stock depends on extended and merge everything from the stock extended to the base stock module, including the recently merged stock_extended_31 module. task-id: 3894340
Miscellaneous changes
Before this commit: When a user with Billings rights scans a QR code using the vendor QR scan feature, an ir.act.window access error appears. After this commit: We fix the access error. And the QR scan feature works correctly as intended. Forward-Port-Of: odoo/enterprise#69700
Original PR description
Before this commit: When a user with Billings rights scans a QR code using the vendor QR scan feature, an ir.act.window access error appears. After this commit: We fix the access error. And the QR scan feature works correctly as intended. Forward-Port-Of: odoo/enterprise#69700
The problem was that the button tag doesn't support drag & drop functionality in Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=568313). Steps to reproduce (On firefox): - Open Sign up - Open template - Try to drag and drop new compoent - You can only drag and drop through the text inside opw-4085496 Forward-Port-Of: odoo/enterprise#69691 Forward-Port-Of: odoo/enterprise#67772
Original PR description
The problem was that the button tag doesn't support drag & drop functionality in Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=568313). Steps to reproduce (On firefox): - Open Sign up - Open template - Try to drag and drop new compoent - You can only drag and drop through the text inside opw-4085496 Forward-Port-Of: odoo/enterprise#69691 Forward-Port-Of: odoo/enterprise#67772
### Steps to reproduce: - Create a second company COMP 2 - In the settings of COMP2 tick: Inter-Company Transactions Generate SO - With COMP1 create and confirm a PO for COMP2 for 1 unit of any product #### > Traceback ### Cause of the issue: These lines rely on stock models and hence provoque the traceback: https://github.com/odoo/enterprise/blob/d42af3270dea55acf247a99b815264ef96f0ac03/sale_purchase_inter_company_rules/models/purchase_order.py#L123-L132 They were added to transfe
Original PR description
### Steps to reproduce: - Create a second company COMP 2 - In the settings of COMP2 tick: Inter-Company Transactions Generate SO - With COMP1 create and confirm a PO for COMP2 for 1 unit of any product #### > Traceback ### Cause of the issue: These lines rely on stock models and hence provoque the traceback: https://github.com/odoo/enterprise/blob/d42af3270dea55acf247a99b815264ef96f0ac03/sale_purchase_inter_company_rules/models/purchase_order.py#L123-L132 They were added to transfer the `custom_product_template_attribute_value_id` during flows using stock routes. However, the stock dependency was removed from the `sale_purchase_inter_company_rules` module so that these lines should be moved to `sale_purchase_stock_inter_company_rules` ## opw-4151614 Forward-Port-Of: odoo/enterprise#69353
Note that the Swiss payroll modules haven't been translated into any other language than French so far, so that's why only the fr.po is fw-ported. Forward-Port-Of: odoo/enterprise#69654 Forward-Port-Of: odoo/enterprise#69630
Original PR description
Note that the Swiss payroll modules haven't been translated into any other language than French so far, so that's why only the fr.po is fw-ported. Forward-Port-Of: odoo/enterprise#69654 Forward-Port-Of: odoo/enterprise#69630
We need TaxClosingNonPostedDependingMovesError inside account because it is now also used there to catch it when confirming batch of moves. Forward-Port-Of: odoo/enterprise#69518 Forward-Port-Of: odoo/enterprise#69206
Original PR description
We need TaxClosingNonPostedDependingMovesError inside account because it is now also used there to catch it when confirming batch of moves. Forward-Port-Of: odoo/enterprise#69518 Forward-Port-Of: odoo/enterprise#69206
Description: - This accommodates scenarios where the main customer raises a ticket for a delivery partner. Changes: - Code modification for improved flexibility in handling cases where the main customer raises a ticket for the delivery partner. task-3623707 Forward-Port-Of: odoo/enterprise#69637 Forward-Port-Of: odoo/enterprise#52864
Original PR description
Description: - This accommodates scenarios where the main customer raises a ticket for a delivery partner. Changes: - Code modification for improved flexibility in handling cases where the main customer raises a ticket for the delivery partner. task-3623707 Forward-Port-Of: odoo/enterprise#69637 Forward-Port-Of: odoo/enterprise#52864
Steps to reproduce ================== - Open studio - Edit any report - Make some changes - Click on discard - Click on cancel => UncaughtPromiseError Cause of the issue ================== When clicking on cancel, the promise is rejected https://github.com/odoo/odoo/blob/1ffcea337ba463c383483ca53ff57aa6b725b5a2/addons/web_editor/static/src/js/wysiwyg/wysiwyg.js#L1112 Solution ======== Instead of rejecting the promise, resolve it with the confirmation status opw-414
Original PR description
Steps to reproduce ================== - Open studio - Edit any report - Make some changes - Click on discard - Click on cancel => UncaughtPromiseError Cause of the issue ================== When clicking on cancel, the promise is rejected https://github.com/odoo/odoo/blob/1ffcea337ba463c383483ca53ff57aa6b725b5a2/addons/web_editor/static/src/js/wysiwyg/wysiwyg.js#L1112 Solution ======== Instead of rejecting the promise, resolve it with the confirmation status opw-4141192 Forward-Port-Of: odoo/enterprise#69646 Forward-Port-Of: odoo/enterprise#69127
Forward-Port-Of: odoo/enterprise#69591
Original PR description
Forward-Port-Of: odoo/enterprise#69591
The CAR (Código de Anotación de Registro) is an alphanumeric identifier composed of payment voucher data. It includes: - RUC number of the issuer: 11 numeric digits. - Type of payment voucher: 2 numeric digits. - Payment voucher series: 4 alphanumeric digits. - Payment voucher number: 10 alphanumeric digits.  Previously, support for SIRE reports was added. This change updates the general ledger t
Original PR description
The CAR (Código de Anotación de Registro) is an alphanumeric identifier composed of payment voucher data. It includes: - RUC number of the issuer: 11 numeric digits. - Type of payment voucher: 2…
The CAR (Código de Anotación de Registro) is an alphanumeric identifier composed of payment voucher data. It includes: - RUC number of the issuer: 11 numeric digits. - Type of payment voucher: 2 numeric digits. - Payment voucher series: 4 alphanumeric digits. - Payment voucher number: 10 alphanumeric digits.  Previously, support for SIRE reports was added. This change updates the general ledger to ensure compatibility. Adjusted the format of the 'book' field to include zero-padded and truncated document types, series, and folio numbers. Legal reference: https://www.sunat.gob.pe/legislacion/superin/2021/anexo-112-2021.pdf  Resolutions: [Resolución de Superintendencia N.° 112-2021](https://drive.google.com/file/d/19iWgqTeTn5WNIg3RpfAyHtF6xSIFL2rH/view?usp=sharing) Forward-Port-Of: odoo/enterprise#68808 Forward-Port-Of: odoo/enterprise#67911
Steps to reproduce: [l10n_be] - Create a customer from Spain with the following VAT: A12345674 - Create an invoice with the customer - Go to EC Sales report Issue: The country code used in the report is "A1" Solution: Instead of inferring the country code from the VAT, we use the country code per se; to be a bit more defensive we fall back on the initial flow in case there is no country code. opw-4080828 Forward-Port-Of: odoo/enterprise#69125
Original PR description
Steps to reproduce: [l10n_be] - Create a customer from Spain with the following VAT: A12345674 - Create an invoice with the customer - Go to EC Sales report Issue: The country code used in the report is "A1" Solution: Instead of inferring the country code from the VAT, we use the country code per se; to be a bit more defensive we fall back on the initial flow in case there is no country code. opw-4080828 Forward-Port-Of: odoo/enterprise#69125
This PR fixes a wrong documentation link in the helpdesk team form view. Task-4102472 Forward-Port-Of: odoo/enterprise#68101
Original PR description
This PR fixes a wrong documentation link in the helpdesk team form view. Task-4102472 Forward-Port-Of: odoo/enterprise#68101
Steps to reproduce: - Subscriptions > New > Set recurrence - Set 'Date of next invoice' in the future - Renew This should raise a ValidationError because renewing a subscription which was never started (no invoice) is invalid, as specified in the error message "You cannot upsell or renew a subscription that has not been invoiced yet". opw-4116538 Forward-Port-Of: odoo/enterprise#69361
Original PR description
Steps to reproduce: - Subscriptions > New > Set recurrence - Set 'Date of next invoice' in the future - Renew This should raise a ValidationError because renewing a subscription which was never started (no invoice) is invalid, as specified in the error message "You cannot upsell or renew a subscription that has not been invoiced yet". opw-4116538 Forward-Port-Of: odoo/enterprise#69361
In this pr: https://github.com/odoo/odoo/pull/171795 we added some computed fields which caused an increase on the query count of the l10n_au_hr_payroll_account module, this commit will increase that. task: 4127269 Forward-Port-Of: odoo/enterprise#69704
Original PR description
In this pr: https://github.com/odoo/odoo/pull/171795 we added some computed fields which caused an increase on the query count of the l10n_au_hr_payroll_account module, this commit will increase that. task: 4127269 Forward-Port-Of: odoo/enterprise#69704
Scanned barcodes were not saved (setting field in record do not register the change). Continue Production did not take advantage of saveModel parameter of doActionAndClose Forward-Port-Of: odoo/enterprise#69623 Forward-Port-Of: odoo/enterprise#69544
Original PR description
Scanned barcodes were not saved (setting field in record do not register the change). Continue Production did not take advantage of saveModel parameter of doActionAndClose Forward-Port-Of: odoo/enterprise#69623 Forward-Port-Of: odoo/enterprise#69544
6 changes
Enhancements to existing features
This update prevents the system from sending assignment notification emails when recurring subscription invoices are created. Previously, the system could send thousands of unnecessary emails depending on database size. The change maintains proper communication consistency by keeping the same salesperson assigned to invoices as they are on the original subscription order.
Original PR description
Before this commit, assignment emails are sent when an account.move is created with a different user_id than the current one. For subscriptions it can send thousands of email depending on the database size. The user_id on the account.move is the same salesperson than the one in charge of the sale.order. It helps the consistency of communication between the customer and the company. taskid: 4096474
This update improves how bills are matched in the GSTR 2B tax return process by allowing a small Rs. 1 tolerance for amount differences and better handling of bill reference numbers with special characters. This reduces unnecessary bill creation from minor discrepancies like paisa differences, making the tax filing process more accurate and efficient.
Original PR description
Description: - This PR introduces an Rs. 1 tolerance for amount matching to prevent unnecessary bill creation for minor discrepancies (e.g., paisa differences). It also improves bill reference number matching by handling special characters and comparing numerically as text. Impact: - Reduces unnecessary bill creation. - Enhances accuracy in matching bill reference numbers. Task ID: 3975209
Resolved issues and error corrections
Corrected a payroll calculation error in the Belgian localization where employees on extended leave (such as maternity leave) were incorrectly receiving representation fees meant to compensate work expenses. The fix ensures representation fees are only paid when employees have actually worked, not when they are on leave regardless of paid public holidays during that period.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Enable Belgian localization; 2. create a public holiday; 3. have a contracted employee with CP200 salary structure; 4. make sure they get representation fees; 5. create a month-long maternity leave overlapping the holiday; 6. generate a payslip for that month. Issue ----- Employee receives representation fees, meant to compensate work expenses, despite not having worked that month. Cause ----- Representation fee calculation is currently based on "paid days" rather than days where the employee worked. As maternity leave is unpaid, the employee would normally not get representation fee, but because of the paid public holiday, the calculation continues as if the worker wasn't on leave. Solution -------- Check the `work_entry_type_id` of worked days, and skip representation fee calculation if all have `is_leave` set to `True`. opw-3908980 Forward-Port-Of: odoo/enterprise#68462
This fix resolves an access error that prevented users with Billing rights from using the vendor QR code scanning feature. The QR scan functionality now works correctly for all authorized billing users, improving their ability to process vendor bills efficiently.
Original PR description
Before this commit: When a user with Billings rights scans a QR code using the vendor QR scan feature, an ir.act.window access error appears. After this commit: We fix the access error. And the QR scan feature works correctly as intended.
This fix corrects an issue where the EC Sales report was displaying an incorrect country code (e.g., "A1" instead of the actual country code) when processing customer VAT numbers. The system now uses the customer's actual country code instead of trying to extract it from the VAT number, ensuring accurate reporting for cross-border sales.
Original PR description
Steps to reproduce: [l10n_be] - Create a customer from Spain with the following VAT: A12345674 - Create an invoice with the customer - Go to EC Sales report Issue: The country code used in the report is "A1" Solution: Instead of inferring the country code from the VAT, we use the country code per se; to be a bit more defensive we fall back on the initial flow in case there is no country code. opw-4080828 Forward-Port-Of: odoo/enterprise#69125
This update removes an automatic copy action that was triggered immediately when using the Spreadsheet Share Button. Users will now have more control over when content is copied, improving the user experience by preventing unintended clipboard actions. This fix applies to both spreadsheet dashboards and document spreadsheets.
Original PR description
*spreadsheet* = spreadsheet_dashboard_edition documents_spreadsheet opw-4144551