Daily updates from Odoo
Navigate
Branch
Thursday, March 21, 2024
72 changes
21 changes
Resolved issues and error corrections
This fixes cases where users could see internal technical action names in the web interface. Client actions will no longer fall back to these technical labels, keeping screens clearer and more user-friendly.
Original PR description
Since [1], it's now possible to set a display name on a client action, but a fallback to the action's name was also added. The issue with this, is that the action's name is a very technical one, and we don't want to display it to the user. [1] https://github.com/odoo/odoo/commit/3ad4fd65387f60b524e5f786556963ead8ae9dfe
Miscellaneous changes
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#157954 Forward-Port-Of: odoo/odoo#157817
Original PR description
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#157954 Forward-Port-Of: odoo/odoo#157817
This PR introduces a new configuration parameter 'event.event_mail_async' forcing registrations-based communication to be asynchronous. Instead of directly sending communication it triggers the cron to be run as soon as possible. When having large volume of registrations, and especially concurrent registrations it saves a DB to avoid generating tickets and preparing emails synchronously to the registration creation. Task-3764894: Event: Allow using cron triggers for communication Par
Original PR description
This PR introduces a new configuration parameter 'event.event_mail_async' forcing registrations-based communication to be asynchronous. Instead of directly sending communication it triggers the cron to be run as soon as possible. When having large volume of registrations, and especially concurrent registrations it saves a DB to avoid generating tickets and preparing emails synchronously to the registration creation. Task-3764894: Event: Allow using cron triggers for communication Part of Task-3084943: Event: Improve communication scheduler scalability Forward-Port-Of: odoo/odoo#155777
An error occurs when the user attempts to access a forecast report for the replenishment product but does not receive the warehouse location ID (archive/delete). Steps to reproduce: (without demo data) - Install "stock_account" module - Inventory -> Operation -> Procurement -> Replenishment - Create a new Replenishment product - Configuration -> warehouse -> Archive warehouse records - Go to a product made in the replenishment and click on forecast report Traceback : ```IndexError:
Original PR description
An error occurs when the user attempts to access a forecast report for the replenishment product but does not receive the warehouse location ID (archive/delete). Steps to reproduce: (without demo…
An error occurs when the user attempts to access a forecast report for the replenishment product but does not receive the warehouse location ID (archive/delete).
Steps to reproduce: (without demo data)
- Install "stock_account" module
- Inventory -> Operation -> Procurement -> Replenishment
- Create a new Replenishment product
- Configuration -> warehouse -> Archive warehouse records
- Go to a product made in the replenishment and click on forecast report
Traceback :
```IndexError: list index out of range
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1826, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1847, 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 1824, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1832, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2057, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, 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/dataset.py", line 34, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 30, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/stock/report/stock_forecasted.py", line 21, in get_report_values
'docs': self._get_report_data(product_ids=docids),
File "addons/stock/report/stock_forecasted.py", line 126, in _get_report_data
res.update(self._get_report_header(product_template_ids, product_ids, wh_location_ids))
File "addons/sale_stock/report/stock_forecasted.py", line 34, in _get_report_header
res = super()._get_report_header(product_template_ids, product_ids, wh_location_ids)
File "addons/purchase_stock/report/stock_forecasted.py", line 11, in _get_report_header
res = super()._get_report_header(product_template_ids, product_ids, wh_location_ids)
File "addons/stock_account/report/stock_forecasted.py", line 17, in _get_report_header
company = self.env['stock.location'].browse(wh_location_ids[0]).company_id
```
This commit will help to open a forecast report if the warehouse location is not found.
sentry-4998176742
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#158017### Steps to reproduce: - Install **Field service** app. - Go to Field Service app and create a new task, with Allocated Time of 5 hours. - In the new ticket, Log 5 hours in the **TimeSheets** tab. - Go to the tasks list. - Notice how the progress bar of the new task shows **1** _instead_ of **100** although 5 out of 5 hours have been logged. ### Investigation: - 8389722b1abdef029799c3c082a44e30dafb24b1 introduced the new **ProjectTaskProgressBarField** component. - 4a93d9aee957dd3feb3
Original PR description
### Steps to reproduce: - Install **Field service** app. - Go to Field Service app and create a new task, with Allocated Time of 5 hours. - In the new ticket, Log 5 hours in the **TimeSheets** tab. - Go to the tasks list. - Notice how the progress bar of the new task shows **1** _instead_ of **100** although 5 out of 5 hours have been logged. ### Investigation: - 8389722b1abdef029799c3c082a44e30dafb24b1 introduced the new **ProjectTaskProgressBarField** component. - 4a93d9aee957dd3feb3db0cb69eb3b8f0f4a4683 introduced a change to calculate the `task.progress` as a _fraction_ instead of a _percentage_ https://github.com/odoo/odoo/blob/7280dd53bc14f7c398c63a1f719987bcab7c257a/addons/hr_timesheet/models/project_task.py#L102 - But the **ProjectTaskProgressBarField** wasn't adapted to that change working with percentage values. opw-3790397 Forward-Port-Of: odoo/odoo#157825
Before this commit, when the current user did not have `hr.group_hr_user` group and creates a timesheet for an employee in his team, he could get a traceback before one field defined only `hr.employee` model cannot be fetched in `hr.employee.public` by the ORM. The reason is because when the user creates a timesheet in a task without any company set, we will take the company of the employee set on the timesheet to set it in the new timesheet, by doing that, the ORM will prefetch the fields of `h
Original PR description
Before this commit, when the current user did not have `hr.group_hr_user` group and creates a timesheet for an employee in his team, he could get a traceback before one field defined only…
Before this commit, when the current user did not have `hr.group_hr_user` group and creates a timesheet for an employee in his team, he could get a traceback before one field defined only `hr.employee` model cannot be fetched in `hr.employee.public` by the ORM. The reason is because when the user creates a timesheet in a task without any company set, we will take the company of the employee set on the timesheet to set it in the new timesheet, by doing that, the ORM will prefetch the fields of `hr.employee` and returned the company from its cache. This commit makes sure we will not have any issue when we try to get the company of the employee to set in the new timesheet if one field defined in `hr.employee` is not defined in `hr.employee.public` and has to be prefetched by the ORM. Steps to reproduce (in 17+) ================== 0. install `hr_timesheet` and `pos_blackbox_be` modules. 1. create a user A with `hr_timesheet.group_hr_timesheet_approver`, without any access to Employee app 2. create a project and a task without any company set (default value) 3. log in as user A 4. go to the form view of task created in step 2 5. add a timesheet and save the form view Expected Behavior ================= The timesheet should be added in the task and the form view should be saved without any issue. Actual Behavior =============== A traceback is occured saying "The fields 'insz_or_bis_number' you try to read is not available on the public employee profile" opw-3769277 Forward-Port-Of: odoo/odoo#156506
# Context With 17.0 the `mail.alias.domain` was introduced, allowing the configuration of the bounce, catchall and default from email addresses at the company level (`res_company`). For this purpose, the `_compute_email_from` method was introduced to correctly compute the `email_from` in various email contexts. But, the `email_from` field in mass_mailing was using an obsolete combination of `default=` and a compute method. This meant that when one created a new `mailing.mailing` record,
Original PR description
# Context With 17.0 the `mail.alias.domain` was introduced, allowing the configuration of the bounce, catchall and default from email addresses at the company level (`res_company`). For this purpose,…
# Context With 17.0 the `mail.alias.domain` was introduced, allowing the configuration of the bounce, catchall and default from email addresses at the company level (`res_company`). For this purpose, the `_compute_email_from` method was introduced to correctly compute the `email_from` in various email contexts. But, the `email_from` field in mass_mailing was using an obsolete combination of `default=` and a compute method. This meant that when one created a new `mailing.mailing` record, it was always defaulting to `self.env.user.email_formatted`. The compute was only triggered when the `mail_server_id` field manually updated. This is corrected with this fix and a unit test was added to test three different use cases. An invisible `create_uid` was added to the base mailing From view xml to have the compute method trigger correctly in some unit tests. ## How to reproduce bug: See related github issue https://github.com/odoo/odoo/issues/151310 ## Behavior after this fix: If `mail.alias.domain` is setup for the company and a default `ir.mail_server` is configured for Email Marketing, `_compute_email_from` will select the expected `email_from` at record creation for `mailing.mailing`. opw-3704715 Fixes #151310 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152655
When the user inserts a video with the `/video` command and provides a link of an unlisted vimeo video, the system generates a new url based on the options selected but omits the hash parameter granting access to the given video. As a result, the video can not be loaded and the vimeo `iframe` indicates that the video does not exist. To fix the issue, we will copy the hash parameter from the original link to the newly generated url. That way, the video will be loaded properly and the user will
Original PR description
When the user inserts a video with the `/video` command and provides a link of an unlisted vimeo video, the system generates a new url based on the options selected but omits the hash parameter…
When the user inserts a video with the `/video` command and provides a link of an unlisted vimeo video, the system generates a new url based on the options selected but omits the hash parameter granting access to the given video. As a result, the video can not be loaded and the vimeo `iframe` indicates that the video does not exist. To fix the issue, we will copy the hash parameter from the original link to the newly generated url. That way, the video will be loaded properly and the user will be able to embed unlisted vimeo videos. Steps to reproduce the issue: 1. Install the website app 2. Open the website builder 3. Drag and drop a text block 4. In the text block, type the `/video` command to insert a video 5. In the modal, paste the link of an unlisted video 6. The `iframe` indicates that the video does not exist => The system should extract the hash parameter from the provided url and set it on the generated url. The video should then be loaded properly. task-3697764 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157279 Forward-Port-Of: odoo/odoo#150663
Steps to reproduce: - Enter in edit mode. - Select the 'Header' menu. - Switch the default template to 'Rounded box menu'. - Select again the 'Header' menu and on the 'Navbar' details, update the format value (i.e: 10px) and save. -> Problem: some buttons are not affected by the change of the format value. The problem is that since [1], those buttons have the `rounded-circle` class so their font size is not the custom one (but it is the value of `$font-size-base` instead). To solve
Original PR description
Steps to reproduce: - Enter in edit mode. - Select the 'Header' menu. - Switch the default template to 'Rounded box menu'. - Select again the 'Header' menu and on the 'Navbar' details, update the format value (i.e: 10px) and save. -> Problem: some buttons are not affected by the change of the format value. The problem is that since [1], those buttons have the `rounded-circle` class so their font size is not the custom one (but it is the value of `$font-size-base` instead). To solve the problem, the css rule has been adapted in order to force the font size of the buttons inside the header to the custom value if it exists. [1]: https://github.com/odoo/odoo/commit/e3e9c492e0d1e009a0c459a1dc591e122b4b65d3 opw-3810794 Forward-Port-Of: odoo/odoo#158135
Removed background color of crm enrich mail messages, so that they look good on both light and dark mode Related task: 3541419 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#158119 Forward-Port-Of: odoo/odoo#158003
Original PR description
Removed background color of crm enrich mail messages, so that they look good on both light and dark mode Related task: 3541419 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#158119 Forward-Port-Of: odoo/odoo#158003
The push-to-talk extension service sends a message to the extension when starting to check if it is enabled. If the response is received before the RTC service is started, the answer is ignored, and the service acts as if the extension were not available. This PR fixes this issue. Forward-Port-Of: odoo/odoo#158252
Original PR description
The push-to-talk extension service sends a message to the extension when starting to check if it is enabled. If the response is received before the RTC service is started, the answer is ignored, and the service acts as if the extension were not available. This PR fixes this issue. Forward-Port-Of: odoo/odoo#158252
Since [1] when the social share widget was introduced, a hashtag is generated from the name of the website that is found inside the page title. This fails when the page title is replaced through the SEO feature. This commit prevents the failure but not extracting the website name if it is missing from the title. Steps to reproduce: - Install website_forum. - Go to a forum post. - Set SEO title to a value without `|` (pipe). - Share to X. => An error popup was shown. [1]: https:/
Original PR description
Since [1] when the social share widget was introduced, a hashtag is generated from the name of the website that is found inside the page title. This fails when the page title is replaced through the SEO feature. This commit prevents the failure but not extracting the website name if it is missing from the title. Steps to reproduce: - Install website_forum. - Go to a forum post. - Set SEO title to a value without `|` (pipe). - Share to X. => An error popup was shown. [1]: https://github.com/odoo/odoo/commit/1c91e27c8c8cb7492d26f03e27c4991b53a1675d opw-3799914 Forward-Port-Of: odoo/odoo#158064
Before this commit, radio buttons in the offcanvas filters (displayed on mobile) were not working as they should: clicking on the label worked fine but the click on the radio itself did not trigger anything. We impeach input's `pointer-event` so, the `<a>` becomes main and only interaction This commit also fixes an contrast issue in the tag filter in the offcanvas task-3649662 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-
Original PR description
Before this commit, radio buttons in the offcanvas filters (displayed on mobile) were not working as they should: clicking on the label worked fine but the click on the radio itself did not trigger anything. We impeach input's `pointer-event` so, the `<a>` becomes main and only interaction This commit also fixes an contrast issue in the tag filter in the offcanvas task-3649662 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147129
Purpose of this commit: Currently, people having access to different dashboards without any access rights would end up with a traceback when trying to search more employees. Steps to reproduce this issue: - have a user with timesheet officer rights and no hr rights - log in with that user account - go on the dashboard app and select "Timesheets" - go on employee filter and click on "search more" Current behaviour: A traceback is displayed because the user has no access to the view
Original PR description
Purpose of this commit: Currently, people having access to different dashboards without any access rights would end up with a traceback when trying to search more employees. Steps to reproduce this…
Purpose of this commit: Currently, people having access to different dashboards without any access rights would end up with a traceback when trying to search more employees. Steps to reproduce this issue: - have a user with timesheet officer rights and no hr rights - log in with that user account - go on the dashboard app and select "Timesheets" - go on employee filter and click on "search more" Current behaviour: A traceback is displayed because the user has no access to the view Expected behaviour: The public employee search view should be displayed How the issue was fixed: The method called `_get_views` has been overriden in the `hr.employee` model to return the `hr.employee.public` views instead if the user doesn't have the appropriate access rights. As there was no way through the dashboard to define a relation, the method explicitely takes the result for the public employee and sets it as result of the private one as well. Forward-Port-Of: odoo/odoo#158096 Forward-Port-Of: odoo/odoo#155739
`_get_checkout_steps` didn't provide a friendly way to add steps in the checkout flow. Developers had to reimplement part of the parent logic in their overrides. This commit introduces `get_checkout_step_list`. This method will allow an easier override of the checkout steps while keeping the logic to return a single step in the parent method. Forward-Port-Of: odoo/odoo#158026
Original PR description
`_get_checkout_steps` didn't provide a friendly way to add steps in the checkout flow. Developers had to reimplement part of the parent logic in their overrides. This commit introduces `get_checkout_step_list`. This method will allow an easier override of the checkout steps while keeping the logic to return a single step in the parent method. Forward-Port-Of: odoo/odoo#158026
Since [1] when the "Padding (Y, X)" option was added, form elements are recognized as columns because they match the `.row > div` selector of that new option. This commit excludes those form elements from this option's selector. Steps to reproduce: - Drop a website form. - Click on field's input. => An empty "Column" editor appeared in the side panel, and an error occurred when trying to delete it. [1]: https://github.com/odoo/odoo/commit/11418cc6f0afcc8e14869f4f38ae0d6d462ac712
Original PR description
Since [1] when the "Padding (Y, X)" option was added, form elements are recognized as columns because they match the `.row > div` selector of that new option. This commit excludes those form elements from this option's selector. Steps to reproduce: - Drop a website form. - Click on field's input. => An empty "Column" editor appeared in the side panel, and an error occurred when trying to delete it. [1]: https://github.com/odoo/odoo/commit/11418cc6f0afcc8e14869f4f38ae0d6d462ac712 task-3748574 Forward-Port-Of: odoo/odoo#157572
The barcode service using jquery for chrome on mobile is not working properly without jquery included, we include it here task-3817495 Forward-Port-Of: odoo/odoo#158275
Original PR description
The barcode service using jquery for chrome on mobile is not working properly without jquery included, we include it here task-3817495 Forward-Port-Of: odoo/odoo#158275
Steps to reproduce: * Create a product tag (available on ecommerce) * Select that filter on the /shop page * Enter a search string -> Traceback The selected tag is given as a string to the autocomplete route, and not a list of ids, which fails when converted to an 'in' domain leaf. `[('product_variant_ids.all_product_tag_ids', 'in', tags)]` This commit makes sure to convert the given ids to a list, correctly handled by the orm. Fixes #155327 Forward-Port-Of: odoo/odoo#1554
Original PR description
Steps to reproduce:
* Create a product tag (available on ecommerce)
* Select that filter on the /shop page
* Enter a search string
-> Traceback
The selected tag is given as a string to the
autocomplete route, and not a list of ids,
which fails when converted to an 'in' domain leaf.
`[('product_variant_ids.all_product_tag_ids', 'in', tags)]`
This commit makes sure to convert the given ids to a list, correctly handled by the orm.
Fixes #155327
Forward-Port-Of: odoo/odoo#155430Steps to reproduce: - - Create 4 products: Final product (FP), Product 1,2,3 (P1,P2 and P3) - Set routes to manifacture on each product - For P1, P2, P3 add a 0:0 reordering rule. - Add a BOM for P2 with 1 unit of P1 as components - Add a BOM for P3 with 1 unit of P2 as components - Add a BOM for FP with 1 unit of P3 and of P2 as components The MO overview of a FP should look like this : ``` FP /\ / \ P3 P2 | | P2 P1 | P1 ``` - Create and confirm a
Original PR description
Steps to reproduce: - - Create 4 products: Final product (FP), Product 1,2,3 (P1,P2 and P3) - Set routes to manifacture on each product - For P1, P2, P3 add a 0:0 reordering rule. - Add a BOM for P2…
Steps to reproduce:
-
- Create 4 products: Final product (FP), Product 1,2,3 (P1,P2 and P3)
- Set routes to manifacture on each product
- For P1, P2, P3 add a 0:0 reordering rule.
- Add a BOM for P2 with 1 unit of P1 as components
- Add a BOM for P3 with 1 unit of P2 as components
- Add a BOM for FP with 1 unit of P3 and of P2 as components The MO overview of a FP should look like this :
```
FP
/\
/ \
P3 P2
| |
P2 P1
|
P1
```
- Create and confirm a manufacturing order for a FP
Current behavior:
-
As the quantity on hand is not sufficient to manufacture a FP, manufacturing orders are automatically created for P3, P2 and P1. However, the quantity on each of these MOs is of 1 unit.
Expected behavior:
-
Since 2 units of P2 and of P1 will be required to manufacture the FP the quantity of their respective MOs should be at 2.
Cause of the issue:
-
Confirming the MO for FP will call the trigger_scheduler() on its raw stock move:
https://github.com/odoo/odoo/blob/79813f08e5a2f0188ac7d184d000486f25319503/addons/mrp/models/mrp_production.py#L1291
https://github.com/odoo/odoo/blob/f3ef40da0406bb0fd683dce3a08739e247fd6dfc/addons/stock/models/stock_orderpoint.py#L495
In this method, we compute the qty to order for the orderpoints of P2 and P3. Since these ones are positive, procurement will be run for both of these leading to the creation of 2 new MO's via the manufacture route. The post process of the scheduler is then run https://github.com/odoo/odoo/blob/f3ef40da0406bb0fd683dce3a08739e247fd6dfc/addons/stock/models/stock_orderpoint.py#L550
An override of this method in mrp will then find the created MO and confirm these, triggering the above process once more but now for the MO's of P3 and P2 rather than FP: we start by computing the qty to order for the orderpoints of P2 and P1 to manufacture P3 and P2. However, to compute this quantity, we look at the forecast of these quantities and this is where the problem comes in:
https://github.com/odoo/odoo/blob/f3ef40da0406bb0fd683dce3a08739e247fd6dfc/addons/stock/models/stock_orderpoint.py#L284
With the orderpoint of P2:
- `virtual_available` is at a value of -1 since there is currently 2 stock moves taking this product (one to manufacture FP and one to manufacture P3) and one stock move bringing one unit of this product (the one coming from the MO of P2 we are currently trying to confirm).
- `orderpoint._quantity_in_progress()` has a value of 1 due to the MO of P2 that we are currently confirming.
Adding these quantities to one an other, the forecasted qty of P2 is at 0. This is a mistake since the incoming stock move for P2 is counted twice in the forecast qty: once in each term. As a result no new procurement will be generated for P2 hence the issue.
FIX:
-
Since this `_quantity_in_progress()` seems to have been introduced to improve purchase flows rather than to interact with manufacturing flows: https://github.com/odoo/odoo/commit/943da6df0f1d39e8e10869b25c5ba8cc13a2aa54
We decided to ignore its contribution during our manufacturing flow for the forecast qty to be correctly computed.This requires to ignore the contribution of each mo triggering the scheduler and those that already triggered the scheduler since the confirmation of the MO of FP.
Notes: The test sets a little more complex MO overview than the above use case to be sure to catch corner cases situations.
opw-3689920
-
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#153400**Current behaviour before commit:** After selecting cells in table, moving cursor through arrowkeys doesn't deselect cells. **Desired behaviour after commit:** Now cells are getting deselected. task-3718716 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153365
Original PR description
**Current behaviour before commit:** After selecting cells in table, moving cursor through arrowkeys doesn't deselect cells. **Desired behaviour after commit:** Now cells are getting deselected. task-3718716 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153365
This commit fixes an issue where one could interract with the load more button of the kanban view even in sample data mode. task-3754233 Forward-Port-Of: odoo/odoo#157740
Original PR description
This commit fixes an issue where one could interract with the load more button of the kanban view even in sample data mode. task-3754233 Forward-Port-Of: odoo/odoo#157740
7 changes
Resolved issues and error corrections
This update fixes a bug that prevented invoices with specific UBL-CII tax formats (ubl_bis3 and nlcius_1) from confirming correctly. The fix ensures the system correctly processes these invoices, allowing users to complete the confirmation process without errors. This improves the reliability of electronic invoicing.
Original PR description
**Current behavior:** Creating a fixed tax with the edi formats ubl_bis3 and nlcius_1 then creating an invoice with this tax tied to a product will cause a traceback when a user tries to confirm the…
**Current behavior:**
Creating a fixed tax with the edi formats ubl_bis3 and nlcius_1
then creating an invoice with this tax tied to a product will
cause a traceback when a user tries to confirm the invoice.
**Expected behavior:**
The invoice will post as any other might.
**Steps to reproduce:**
1. Create a NL company with l10n_nl_edi accounting
2. Create a tax with the following field values:
*tax computation: fixed*
*affect base of subsequent taxes: True*
*base affected by previous taxes: True*
3. In the customer invoices journal for the created company,
go to the 'Advanced Settings' notebook tab and enable the
NLCIUS and Peppol options under 'Electronic Invoicing'
4. Create a new invoice with some product and attach the newly
created tax to it, then try to confirm the invoice to see
the traceback
**Cause of the issue:**
The edi format tags invoke different instances of the
get_invoice_line_allowance_vals_list() method. This method
returns a dict list where the dicts only sometimes contain the
key 'allowance_charge_reason_code'. A subsequent expression
expects this key in the dict which can cause a KeyError.
**Fix:**
Check instead for a 'charge_indicator' key, which is present in
both the ubl_bis3 and nlcius_1 val dicts, allowing the correct
total to be summed and reflected in the EDI document output.
opw-3680527
Forward-Port-Of: odoo/odoo#157221
Forward-Port-Of: odoo/odoo#152229This fix ensures that new projects correctly utilize the selected analytic plan. Previously, the system defaulted to a 'Projects' plan regardless of user settings. This update resolves a discrepancy in how the analytic plan is applied, improving the accuracy of timesheet and project accounting.
Original PR description
Currently, the `plan_id` used to create analytic accounts is not the one set in the settings. Steps to reproduce: ------------------- * Go to the **Settings** * Enable developper mode * Select **User…
Currently, the `plan_id` used to create analytic accounts is not the one set in the settings. Steps to reproduce: ------------------- * Go to the **Settings** * Enable developper mode * Select **User & Companies** > **Groups** * Select `Technical/Analytic Accounting` * Add user * Go to the **Project** app * Select **Configuration** > **Settings** * Under **Time Management**, enable Timesheets * Under **Analytics** > **Analytic Plan**, select Projects * Create a new project * Go into the settings of the project * Under the **Settings** tab, select the internal link for the **Analytic Account** > **Observation**: The Plan is set to Projects * Go to **Conffiguration** > **Settings** * Under **Analytics** > **Analytic Plan**, change Projects to Departments * Create a new project * Go into the settings of the project * Under the **Settings** tab, select the internal link for the **Analytic Account** > **Observation**: The Plan is still set to Projects Why the fix: ------------ When creating, an analytic account, the plan is computed with `_get_all_plans()`. https://github.com/odoo/odoo/blob/e365e22485dc45f1cbe87ae93395b022a4724a3c/addons/project/models/project_project.py#L894-L903 Inside `__get_all_plans()` the plan is computed as follows: https://github.com/odoo/odoo/blob/e365e22485dc45f1cbe87ae93395b022a4724a3c/addons/analytic/models/analytic_plan.py#L106-L107 However, the setting that the user changes in the frontend corresponds to `analytic.analytic_plan_projects`. https://github.com/odoo/odoo/blob/e365e22485dc45f1cbe87ae93395b022a4724a3c/addons/project/models/res_config_settings.py#L18-L22 This seeting is not company-related. It can be used on projects even if they have a `company_id` set to false. We fallback on `_get_all_plans()` if the user did not specifically choose a plan in the settings. opw-3751661 Forward-Port-Of: odoo/odoo#157247
This update removes an automatically installed module, `partner_autocomplete`, from the project module. This fix addresses a previous issue where shared projects with portal users would encounter internal server errors due to missing module files. The change ensures smoother operation for shared projects.
Original PR description
Issue: ------ The `partner_autocomplete` module is an automatically installed module. This module is not included in the dependencies and can therefore be uninstalled. If `partner_autocomplete` is uninstalled and we go to a shared project with a portal user for example, we get an internal server error, as we don't have access to the `partner_autocomplete` files. Solution: --------- Remove the `partner_autocomplete` files from the manifest file of the `project` module. Note: If the widget is not found (in the very rare case of uninstalling the `partner_autocomplete` module), we will use the default widget (and create a log). opw-3774575 Forward-Port-Of: odoo/odoo#157865 Forward-Port-Of: odoo/odoo#157411
Documentation and clarification updates
This pull request formally records the signing of a legal agreement (CLA) by Hari1119. This ensures compliance with Odoo's open-source licensing and strengthens our commitment to the Odoo community. The change involves adding a documentation file detailing this agreement.
Original PR description
Signed a individual CLA Forward-Port-Of: odoo/odoo#156234
This pull request updates the documentation to include a legal agreement (CLA) signature for a contribution by ZhongduoduoQAQ. This ensures the code adheres to Odoo's licensing terms and allows for proper attribution. It’s a standard process for accepting contributions into the Odoo project.
Original PR description
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#157957
This pull request formally signs Odoo's Contributor License Agreement (CLA), ensuring compliance with our open-source licensing. This update is a standard legal step for contributors and doesn't impact Odoo's functionality. It strengthens our commitment to the Odoo community.
Original PR description
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#157960
This pull request formally records that santiagopim has signed the Odoo Contributor License Agreement (CLA). This is a necessary step for santiagopim to contribute code to the Odoo project, ensuring compliance with our licensing terms. With the CLA now signed, santiagopim can begin contributing to Odoo.
Original PR description
Description of the issue/feature this PR addresses: Sign CLA agreement for santiagopim Current behavior before PR: No CLA signed Desired behavior after PR is merged: CLA signed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157955
15 changes
Enhancements to existing features
The webshop demo data now includes a Wood option under product colors, shown with a wood image instead of a plain color. This makes the demo more visually appealing and highlights that color-style product choices can use images, with new Acoustic Bloc Screens examples in White and Wood.
Original PR description
This commit introduces 'Wood' as a new attribute value in the Color attribute (display type = color) for the demo data. Unlike traditional colors, 'Wood' is represented by an image (wood.png), enhancing the demo's visual appeal and showcasing the image upload feature for color displays. The commit also includes two new variants for the 'Acoustic Bloc Screens' product: one in 'White' and another in 'Wood'. This addition demonstrates the flexibility and capability of our attribute system in a more dynamic demo setting. task-3581924 See odoo/odoo#153112
The Referrals app onboarding text can now be translated for users in different languages. This helps companies provide a more localized and accessible onboarding experience for international teams.
Original PR description
This PR makes the Referrals onboarding translatable
Miscellaneous changes
When disposing of an asset after an increase, we have 2 assets in the recordset. Where we should have used `asset`, we used `self` Forward-Port-Of: odoo/enterprise#58838
Original PR description
When disposing of an asset after an increase, we have 2 assets in the recordset. Where we should have used `asset`, we used `self` Forward-Port-Of: odoo/enterprise#58838
Ensure an avatar is generated based on the employee/user name if no image is provided at the record creation (for internal users only). Taskid: 3637523 X-original-commit: 9d11d2087378e1a56333e11daa18e6dc1b8c655e Forward-Port-Of: odoo/enterprise#58860
Original PR description
Ensure an avatar is generated based on the employee/user name if no image is provided at the record creation (for internal users only). Taskid: 3637523 X-original-commit: 9d11d2087378e1a56333e11daa18e6dc1b8c655e Forward-Port-Of: odoo/enterprise#58860
Versions -------- - 15.0+ Steps ----- 1. Have a public holiday; 2. add a planning slot overlapping the holiday; 3. go to Project / Reporting / Timesheets and Planning Analysis. Issue ----- Planned Hours includes holiday hours. Cause ----- The SQL query generating the report only looks at standard workdays. Solution -------- In the SQL query, add a left join on `resource.calendar.leaves` and only select dates date that don't overlap with an employee's leave. opw-3509155
Original PR description
Versions -------- - 15.0+ Steps ----- 1. Have a public holiday; 2. add a planning slot overlapping the holiday; 3. go to Project / Reporting / Timesheets and Planning Analysis. Issue ----- Planned Hours includes holiday hours. Cause ----- The SQL query generating the report only looks at standard workdays. Solution -------- In the SQL query, add a left join on `resource.calendar.leaves` and only select dates date that don't overlap with an employee's leave. opw-3509155 Forward-Port-Of: odoo/enterprise#58867 Forward-Port-Of: odoo/enterprise#56847
Steps to produce: - add new form from editor on website - add action create ticket on it - submit ticket on multi-company environment. Cause: access error while submit ticket with multi-company Solution: access ticket using sudo resolve this issue. task-3635784 Forward-Port-Of: odoo/enterprise#58882 Forward-Port-Of: odoo/enterprise#53389
Original PR description
Steps to produce: - add new form from editor on website - add action create ticket on it - submit ticket on multi-company environment. Cause: access error while submit ticket with multi-company Solution: access ticket using sudo resolve this issue. task-3635784 Forward-Port-Of: odoo/enterprise#58882 Forward-Port-Of: odoo/enterprise#53389
Forward-Port-Of: odoo/enterprise#58973
Original PR description
Forward-Port-Of: odoo/enterprise#58973
Currently, log-level errors occur when WhatsApp webhooks are called, and the app secret may be missed. This commit changes 'logger.error' to 'logger.warning' since this is not an error in the codebase. sentry-4482005357 Forward-Port-Of: odoo/enterprise#47521
Original PR description
Currently, log-level errors occur when WhatsApp webhooks are called, and the app secret may be missed. This commit changes 'logger.error' to 'logger.warning' since this is not an error in the codebase. sentry-4482005357 Forward-Port-Of: odoo/enterprise#47521
The Customs values for a commodity needs to be the values of the entire package. Currently, the value per unit is set which results in the following warning. ``` { 'Severity': 'WARNING', 'Source': 'crs', 'Code': '448', 'Message': 'The sum of internationalDetail commodities customs value amounts do not the equal the internationalDetail customs value amount; the greater customs value amount was used to rate.', 'LocalizedMessage': 'The sum of internationalDetail commodi
Original PR description
The Customs values for a commodity needs to be the values of the entire package. Currently, the value per unit is set which results in the following warning. ``` { 'Severity': 'WARNING', 'Source':…
The Customs values for a commodity needs to be the values of the entire package. Currently, the value per unit is set which results in the following warning.
```
{
'Severity': 'WARNING',
'Source': 'crs',
'Code': '448',
'Message': 'The sum of internationalDetail commodities customs value amounts do not the equal the internationalDetail customs value amount; the greater customs value amount was used to rate.',
'LocalizedMessage': 'The sum of internationalDetail commodities customs value amounts do not the equal the internationalDetail customs value amount; the greater customs value amount was used to rate.',
'MessageParameters': []
}
```
A previous fix https://github.com/odoo/enterprise/pull/38056 missed to correct the value for rating api so a following fix https://github.com/odoo/odoo/pull/116068 was made, which made the first fix obsolete + incorrect. The followup PR missed adjusting the FedEx value to match its change (i.e. other carriers were checked, but FexEx was overlooked) This commit corrects this issue and sets the correct commodity value for FedEx.
This corrects the sequence of arguments passed to the method
`_fedex_update_srm` The method on the super class is intended to be
overridden to add additional information on the Fedex Request.
The incorrect sequence of arguments restricts it from being overridden
correctly.
Forward-Port-Of: odoo/enterprise#58734Currently we send a list of ibans, and a single date from which to fetch the files. This is a bit problematic if the user has multiple journals and one of which is not used. In such a case, this old journal won't have transactions for months. Then we'll use the date of this old journal as the one from which to start fetching. So a journal that is up to date and gets documents everyday will still use this old date. Therefore we'll download lots of files (3 months or historic) even though the v
Original PR description
Currently we send a list of ibans, and a single date from which to fetch the files. This is a bit problematic if the user has multiple journals and one of which is not used. In such a case, this old journal won't have transactions for months. Then we'll use the date of this old journal as the one from which to start fetching. So a journal that is up to date and gets documents everyday will still use this old date. Therefore we'll download lots of files (3 months or historic) even though the vast majority will not be used (only skipped because already imported) From now on, for each journal, we send the date of the last bank statement along with the IBAN of the journal, so that on IAP's side, we can filter out older bank statements. This allows faster fetching of the files. IAP: https://github.com/odoo/iap-apps/pull/771 task-id 3762743 Forward-Port-Of: odoo/enterprise#58936 Forward-Port-Of: odoo/enterprise#57722
Steps to reproduce: - have a codabox setup - from the accounting dashboard, fetch the codabox data Issue: Traceback Cause: When there are no transactions to fetch and there is no fallback journal_id in https://github.com/odoo/enterprise/blob/27878a7b1a0577c2e83d756d0f59fabe25b20223/account_accountant/static/src/components/bank_reconciliation/kanban.js#L541-L558 it will break (no journal_id -> no company_id -> break ensure one) Note: it could be interesting to further investigate why
Original PR description
Steps to reproduce: - have a codabox setup - from the accounting dashboard, fetch the codabox data Issue: Traceback Cause: When there are no transactions to fetch and there is no fallback journal_id in https://github.com/odoo/enterprise/blob/27878a7b1a0577c2e83d756d0f59fabe25b20223/account_accountant/static/src/components/bank_reconciliation/kanban.js#L541-L558 it will break (no journal_id -> no company_id -> break ensure one) Note: it could be interesting to further investigate why there is no default journal in the props opw-3814226 Forward-Port-Of: odoo/enterprise#58835
The amount rounding tour was broken. As it used `:contains(), it was always checking for a substring of the current value of a line. Since it has to wait for the change to open (rpc call), there was a lot of indeterminism. It is fixed by adding more robust extra triggers. Forward-Port-Of: odoo/enterprise#58285
Original PR description
The amount rounding tour was broken. As it used `:contains(), it was always checking for a substring of the current value of a line. Since it has to wait for the change to open (rpc call), there was a lot of indeterminism. It is fixed by adding more robust extra triggers. Forward-Port-Of: odoo/enterprise#58285
**Before this PR:** Status icons in the embedded view were overlapping with the menu. **After this PR:** The issue has been resolved, and now the menu is displayed correctly over the icons. **Task**-3717057 Forward-Port-Of: odoo/enterprise#56926
Original PR description
**Before this PR:** Status icons in the embedded view were overlapping with the menu. **After this PR:** The issue has been resolved, and now the menu is displayed correctly over the icons. **Task**-3717057 Forward-Port-Of: odoo/enterprise#56926
Steps to Reproduce : - Toggle Studio from Odoo Dashboard - Click on create new app button --> Enter App name and Respective model - The `Create your App` button in Chrome will ultimately not be clearly visible at 100% zoom; the user must currently zoom out to see the button. video link: [Video](https://drive.google.com/file/d/1ug8VFpC10l4o_HFRQOnvwbUDO9yg_rzq/view) Observed behavior: - `Create your App` button is not visible. Expected behavior: - `Create your App` button should be
Original PR description
Steps to Reproduce : - Toggle Studio from Odoo Dashboard - Click on create new app button --> Enter App name and Respective model - The `Create your App` button in Chrome will ultimately not be clearly visible at 100% zoom; the user must currently zoom out to see the button. video link: [Video](https://drive.google.com/file/d/1ug8VFpC10l4o_HFRQOnvwbUDO9yg_rzq/view) Observed behavior: - `Create your App` button is not visible. Expected behavior: - `Create your App` button should be visible clearly. Task-3794467 Forward-Port-Of: odoo/enterprise#58404
How to reproduce: - in point of sale, enable "Generate a code on ticket" - create a pos_order, save the ticket - using the code on the ticket, request an invoice through the portal and fill the information as if you were a mexican company => An invoice is generated and sent successfully to the SAT, but "CFDI to Public" is True on the invoice. Hence, the receptor's RFC will be "XAXX..." instead of the RFC filled in the portal. Reason: The pos_order has "CFDI to Public" to True, and
Original PR description
How to reproduce: - in point of sale, enable "Generate a code on ticket" - create a pos_order, save the ticket - using the code on the ticket, request an invoice through the portal and fill the information as if you were a mexican company => An invoice is generated and sent successfully to the SAT, but "CFDI to Public" is True on the invoice. Hence, the receptor's RFC will be "XAXX..." instead of the RFC filled in the portal. Reason: The pos_order has "CFDI to Public" to True, and this value is copied on the invoice. Fix: Recompute the value for the "CFDI to Public" field on the pos_order when the partner_id is filled. It should only be True when the Receptor's RFC is "XAXX...". Note that the new compute for "CFDI to Public" on the pos_order now resembles the one on the account_move. opw-3767576 Forward-Port-Of: odoo/enterprise#58771
29 changes
Security fixes and vulnerability patches
This update fixes a security issue in the messaging system where data sent to users could be manipulated through the write method. The system now retrieves the actual stored data from the database instead of using potentially altered input values, ensuring users always see accurate information and preventing unauthorized data modifications.
Original PR description
When writing in a discuss channel, the updated value sent to the client should be read from the database, not directly from the values passed to the write method, which could lead into security issues. Partially backport of https://github.com/odoo/odoo/pull/139563 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
The HR module now allows managers to edit the duration of approved leave allocations without having to cancel and revalidate them. This streamlines the process for adjusting employee leave balances, saving time and reducing administrative overhead when allocation corrections are needed.
Original PR description
This commit introduces an improvement in the hr_holidays module by making the duration field of leave allocations editable even after they have been approved. This change addresses a limitation where previously, allocations had to be refused and revalidated for any adjustments. Task-3716272 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes previously untranslatable terms in the Point of Sale app available for translation by our global translator community on Transifex. By exposing these missing terms in the translation files, customers using Odoo in different languages will now see consistent and complete translations throughout the Point of Sale interface.
Original PR description
In the Point of Sale app, some terms were not translatable by our translators on Transifex. In this commit we make sure that the missing terms are either made translatable or exported in the related .pot file. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Fixed a critical issue that caused the system to crash when restaurant staff tried to delete orders from the POS session. Now users can successfully delete orders, and the cancellation status is properly reflected in both the kitchen display and backend system.
Original PR description
Before this commit: ========================= - Open session of Restaurant/Bar. - Make sure the Preparation Display is configured. - Create an order(s). - From Orders, try to delete the order(s). - Traceback After this commit: ========================= - The user can able to delete an order from the POS session and the status will be shown as canceled on the kitchen display as well as in the backend. task-3794159
This fix resolves an issue where importing a bank statement CSV file with empty dates in any row would cause the system to crash. Users can now successfully upload CSV files with missing date values, and the system will handle them gracefully without errors.
Original PR description
When the user imports CSV file of a bank statement and the file has an empty date in one of the rows, a traceback will appear. Steps to reproduce the error: - Go to Accounting > Dashboard > Bank >…
When the user imports CSV file of a bank statement and the file has an empty date in one of the rows,
a traceback will appear.
Steps to reproduce the error:
- Go to Accounting > Dashboard > Bank > Import Statement
- Select a CSV file that has an empty date in one of the rows > Upload
Traceback:
```
TypeError: '<' not supported between instances of 'NoneType' and 'datetime.date'
File "odoo/http.py", line 2157, in __call__
response = request._serve_db()
File "odoo/http.py", line 1732, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1759, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1960, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 24, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 466, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "home/odoo/src/enterprise/17.0/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py", line 121, in execute_import
res = super().execute_import(fields, columns, options, dryrun=dryrun)
File "addons/base_import/models/base_import.py", line 1313, in execute_import
input_file_data = self._parse_import_data(input_file_data, import_fields, options)
File "home/odoo/src/enterprise/17.0/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py", line 68, in _parse_import_data
if dates != sorted(dates):
```
https://github.com/odoo/enterprise/blob/312b4e5df327b25e1678755b24bd27803720cd3d/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L104-L105
Here, When one of the dates is empty, line[index_date] will be None,
So, when it tries to sort dates at "sorted(dates)",
It will lead to above traceback.
sentry-4687473224
Forward-Port-Of: odoo/enterprise#58605
Forward-Port-Of: odoo/enterprise#52019This update adjusts how the WhatsApp integration handles logging when webhooks are called and the app secret is missing. Instead of marking these occurrences as errors, they are now logged as warnings, which better reflects that this is a normal operational situation rather than a system failure. This reduces unnecessary error alerts while maintaining visibility into these events.
Original PR description
Currently, log-level errors occur when WhatsApp webhooks are called, and the app secret may be missed. This commit changes 'logger.error' to 'logger.warning' since this is not an error in the codebase. sentry-4482005357 Forward-Port-Of: odoo/enterprise#47521
This update resolves a display issue in the Knowledge module where status icons were overlapping with the menu in embedded views. The menu now displays correctly on top of the icons, improving the user interface and making the application more usable.
Original PR description
**Before this PR:** Status icons in the embedded view were overlapping with the menu. **After this PR:** The issue has been resolved, and now the menu is displayed correctly over the icons. **Task**-3717057 Forward-Port-Of: odoo/enterprise#56926
This fix corrects the Timesheets and Planning Analysis report to properly exclude holiday hours from the Planned Hours calculation. Previously, when a planning slot overlapped with a public holiday, those holiday hours were incorrectly included in the planned hours total. The fix updates the underlying report query to filter out employee leave dates.
Original PR description
Versions -------- - 15.0+ Steps ----- 1. Have a public holiday; 2. add a planning slot overlapping the holiday; 3. go to Project / Reporting / Timesheets and Planning Analysis. Issue ----- Planned Hours includes holiday hours. Cause ----- The SQL query generating the report only looks at standard workdays. Solution -------- In the SQL query, add a left join on `resource.calendar.leaves` and only select dates date that don't overlap with an employee's leave. opw-3509155 Forward-Port-Of: odoo/enterprise#58867 Forward-Port-Of: odoo/enterprise#56847
Fixed an issue where eBay orders were being synced with outdated products instead of the currently active listing. When a product is no longer marked for eBay sale but retains its eBay ID, and a new product is listed to the same eBay listing, orders now correctly sync with the new active product instead of the old one.
Original PR description
Steps to reproduce the problem: - create a product and list it on eBay - uncheck the sell on eBay setting for the product. Don't archive it - create a second product and list it to the existing listing in eBay - sync an order with that product ==> First created product is shown in the sale order The eBay_id stays on the product, even after unchecking the setting. This seems to be voluntary as when relisting a product, after some time without selling it on eBay for instance, this id will then be used. We now take the first product that is checked as used in eBay. opw-3503924 Forward-Port-Of: odoo/enterprise#58852
This fix resolves a system error that occurred when disposing of an asset after it had been increased in value. The issue was caused by incorrect variable usage in the code logic. This fix ensures that asset disposal transactions complete successfully without errors, improving the reliability of asset management operations.
Original PR description
When disposing of an asset after an increase, we have 2 assets in the recordset. Where we should have used `asset`, we used `self` Forward-Port-Of: odoo/enterprise#58838
This update fixes incorrect customs value calculations in FedEx shipments that were causing warning messages from FedEx. The system was calculating customs values per unit instead of for the entire package, which has now been corrected. This ensures accurate shipping rates and prevents FedEx from overriding the declared customs values.
Original PR description
The Customs values for a commodity needs to be the values of the entire package. Currently, the value per unit is set which results in the following warning. ``` { 'Severity': 'WARNING', 'Source':…
The Customs values for a commodity needs to be the values of the entire package. Currently, the value per unit is set which results in the following warning.
```
{
'Severity': 'WARNING',
'Source': 'crs',
'Code': '448',
'Message': 'The sum of internationalDetail commodities customs value amounts do not the equal the internationalDetail customs value amount; the greater customs value amount was used to rate.',
'LocalizedMessage': 'The sum of internationalDetail commodities customs value amounts do not the equal the internationalDetail customs value amount; the greater customs value amount was used to rate.',
'MessageParameters': []
}
```
A previous fix https://github.com/odoo/enterprise/pull/38056 missed to correct the value for rating api so a following fix https://github.com/odoo/odoo/pull/116068 was made, which made the first fix obsolete + incorrect. The followup PR missed adjusting the FedEx value to match its change (i.e. other carriers were checked, but FexEx was overlooked) This commit corrects this issue and sets the correct commodity value for FedEx.
This corrects the sequence of arguments passed to the method
`_fedex_update_srm` The method on the super class is intended to be
overridden to add additional information on the Fedex Request.
The incorrect sequence of arguments restricts it from being overridden
correctly.
Forward-Port-Of: odoo/enterprise#58734This update fixes an issue in the Argentine localization module where not all available web services were being properly checked during configuration. The fix ensures that the system now validates all web services available for electronic invoicing, improving the reliability of the EDI setup process for businesses operating in Argentina.
This update addresses multiple design and functional issues across the event website platform, including improved button positioning, clearer editor options, better heading hierarchy, and enhanced responsiveness. The changes ensure a more polished and consistent user experience when managing and viewing events on the website.
Original PR description
Address several design and functional issues in prod. See sub commits, each of them addressing a different issue. Task-3718417 part-of task-3698364
This fix corrects an issue where push notifications were displaying the wrong profile picture. When employees request time off, administrators receive notifications with an incorrect image because the system was looking up the profile picture from the wrong user field. This update ensures the correct profile picture is shown in all push notifications.
Original PR description
Steps to reproduce: --- 1. Install hr_holidays 2. Connect as Admin 3. Go to the profile 4. Check Handle in Odoo in Notification 5. In a private browser, connect as Demo 6. Go to Time Off 7. Take a day off 8. A push notification for Admin pops-up 9. The profile picture is wrong Cause of the issue: --- author_id is linked to res.partner not res.users Fix: --- Backport of: https://github.com/odoo/odoo/commit/1244c9c02d6242d34a37aa27168229e9d3939cb4 opw-3684987 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects how the expected shipping date is displayed on Point of Sale receipts. Previously, the shipping date was not appearing on receipts when customers selected a shipping date during checkout. The issue has been resolved by correcting the reference to the shipping date field in the receipt template, ensuring customers now see their expected delivery date on their receipt.
Original PR description
**Steps to reproduce:** 1- Install Point of sale module 2- Allow shipping later configuration 3- Create a POS order with a shipping date **Current behavior before PR:** The expected shipping date was not printed in the pos receipt. This was happening because it was getting called wrong in xml file where it was called 'props.shippingDate'. By checking the JS file we found that the props object structure as follows https://github.com/odoo/odoo/blob/17.0/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/order_receipt.js#L16:L19 **Desired behavior after PR is merged:** The expected shipping date is printed not if exists. As we it is now getting called correctly 'props.data.shippingDate' opw-3746053
This fix resolves an issue where invoices with fixed taxes could not be confirmed when using electronic invoicing formats (NLCIUS and Peppol). The system was looking for a missing data field that wasn't always present, causing the invoice posting to fail. Now the system checks for the correct field that exists in all cases, allowing invoices to post successfully.
Original PR description
**Current behavior:** Creating a fixed tax with the edi formats ubl_bis3 and nlcius_1 then creating an invoice with this tax tied to a product will cause a traceback when a user tries to confirm the…
**Current behavior:**
Creating a fixed tax with the edi formats ubl_bis3 and nlcius_1
then creating an invoice with this tax tied to a product will
cause a traceback when a user tries to confirm the invoice.
**Expected behavior:**
The invoice will post as any other might.
**Steps to reproduce:**
1. Create a NL company with l10n_nl_edi accounting
2. Create a tax with the following field values:
*tax computation: fixed*
*affect base of subsequent taxes: True*
*base affected by previous taxes: True*
3. In the customer invoices journal for the created company,
go to the 'Advanced Settings' notebook tab and enable the
NLCIUS and Peppol options under 'Electronic Invoicing'
4. Create a new invoice with some product and attach the newly
created tax to it, then try to confirm the invoice to see
the traceback
**Cause of the issue:**
The edi format tags invoke different instances of the
get_invoice_line_allowance_vals_list() method. This method
returns a dict list where the dicts only sometimes contain the
key 'allowance_charge_reason_code'. A subsequent expression
expects this key in the dict which can cause a KeyError.
**Fix:**
Check instead for a 'charge_indicator' key, which is present in
both the ubl_bis3 and nlcius_1 val dicts, allowing the correct
total to be summed and reflected in the EDI document output.
opw-3680527
Forward-Port-Of: odoo/odoo#157221
Forward-Port-Of: odoo/odoo#152229This fix removes references to the partner autocomplete feature from the project module to prevent server errors when the partner autocomplete module is uninstalled. The project module will now gracefully fall back to a default widget if the partner autocomplete feature is unavailable, ensuring shared projects work reliably for all users regardless of which optional modules are installed.
Original PR description
Issue: ------ The `partner_autocomplete` module is an automatically installed module. This module is not included in the dependencies and can therefore be uninstalled. If `partner_autocomplete` is uninstalled and we go to a shared project with a portal user for example, we get an internal server error, as we don't have access to the `partner_autocomplete` files. Solution: --------- Remove the `partner_autocomplete` files from the manifest file of the `project` module. Note: If the widget is not found (in the very rare case of uninstalling the `partner_autocomplete` module), we will use the default widget (and create a log). opw-3774575 Forward-Port-Of: odoo/odoo#157865 Forward-Port-Of: odoo/odoo#157411
This fix prevents inactive or archived taxes from being selectable when creating or editing purchase orders. Previously, inactive taxes could still be applied to new purchase order lines, which was incorrect behavior. Now, only active taxes will appear in the tax selection dropdown, while taxes already applied to existing orders remain visible for reference.
Original PR description
Issue: Currently if we have taxes for our Purchase no matter if we set the tax to inactive or we archive it, we will have access to it on the purchase_order_line.
Steps to reproduce:
- Install Purchase
- Create a new Tax and set it to inactive.
- Now create a new RfQ and in the lines add any product.
- Try to change the tax for this product.
Solution: since commit 8ff6747 we got rid of an odd domain which was allowing us to always get every tax no matter if they were active or not. In order for this domain to work we needed to set `context={'active_test': False}` which we no longer need and It's creating a bad behavior on how we want the active field on tax to act.
opw-3776871This update improves the clarity and usefulness of email notifications sent to managers when employees request time off. The changes simplify the message format by removing unnecessary context and using clearer date formatting, so managers receive more readable and actionable information without needing to open the system to understand the request details.
Original PR description
**Description of the issue/feature this PR addresses:** - Remove context which came from the calendar action to only show short name in activity message - ~Add the start and end datetime for notification of the manager, otherwise the manager has a useless email which would need to open a browser to get the notified information (waste of time)~ - Replace date connector with - as a / does not help to better understand the data given **Current behavior before PR:** Incomplete information in the notification emails for time off approvals **Desired behavior after PR is merged:** A better and at least valuable information provided to the manager in a stable way to fix things. Info: @wt-io-it In relation to: - OPW-3628915 - OPW-3764283 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157891 Forward-Port-Of: odoo/odoo#155900
This fix corrects an issue where manufacturing orders were created with incorrect quantities when a bill of materials contains the same component multiple times. Previously, when a product appeared in multiple places in a BOM structure, the system would only create manufacturing orders for 1 unit instead of the correct total quantity needed. This fix ensures accurate quantity calculations so manufacturing orders are generated with the proper amounts.
Original PR description
Steps to reproduce: - - Create 4 products: Final product (FP), Product 1,2,3 (P1,P2 and P3) - Set routes to manifacture on each product - For P1, P2, P3 add a 0:0 reordering rule. - Add a BOM for P2…
Steps to reproduce:
-
- Create 4 products: Final product (FP), Product 1,2,3 (P1,P2 and P3)
- Set routes to manifacture on each product
- For P1, P2, P3 add a 0:0 reordering rule.
- Add a BOM for P2 with 1 unit of P1 as components
- Add a BOM for P3 with 1 unit of P2 as components
- Add a BOM for FP with 1 unit of P3 and of P2 as components The MO overview of a FP should look like this :
```
FP
/\
/ \
P3 P2
| |
P2 P1
|
P1
```
- Create and confirm a manufacturing order for a FP
Current behavior:
-
As the quantity on hand is not sufficient to manufacture a FP, manufacturing orders are automatically created for P3, P2 and P1. However, the quantity on each of these MOs is of 1 unit.
Expected behavior:
-
Since 2 units of P2 and of P1 will be required to manufacture the FP the quantity of their respective MOs should be at 2.
Cause of the issue:
-
Confirming the MO for FP will call the trigger_scheduler() on its raw stock move:
https://github.com/odoo/odoo/blob/79813f08e5a2f0188ac7d184d000486f25319503/addons/mrp/models/mrp_production.py#L1291
https://github.com/odoo/odoo/blob/f3ef40da0406bb0fd683dce3a08739e247fd6dfc/addons/stock/models/stock_orderpoint.py#L495
In this method, we compute the qty to order for the orderpoints of P2 and P3. Since these ones are positive, procurement will be run for both of these leading to the creation of 2 new MO's via the manufacture route. The post process of the scheduler is then run https://github.com/odoo/odoo/blob/f3ef40da0406bb0fd683dce3a08739e247fd6dfc/addons/stock/models/stock_orderpoint.py#L550
An override of this method in mrp will then find the created MO and confirm these, triggering the above process once more but now for the MO's of P3 and P2 rather than FP: we start by computing the qty to order for the orderpoints of P2 and P1 to manufacture P3 and P2. However, to compute this quantity, we look at the forecast of these quantities and this is where the problem comes in:
https://github.com/odoo/odoo/blob/f3ef40da0406bb0fd683dce3a08739e247fd6dfc/addons/stock/models/stock_orderpoint.py#L284
With the orderpoint of P2:
- `virtual_available` is at a value of -1 since there is currently 2 stock moves taking this product (one to manufacture FP and one to manufacture P3) and one stock move bringing one unit of this product (the one coming from the MO of P2 we are currently trying to confirm).
- `orderpoint._quantity_in_progress()` has a value of 1 due to the MO of P2 that we are currently confirming.
Adding these quantities to one an other, the forecasted qty of P2 is at 0. This is a mistake since the incoming stock move for P2 is counted twice in the forecast qty: once in each term. As a result no new procurement will be generated for P2 hence the issue.
FIX:
-
Since this `_quantity_in_progress()` seems to have been introduced to improve purchase flows rather than to interact with manufacturing flows: https://github.com/odoo/odoo/commit/943da6df0f1d39e8e10869b25c5ba8cc13a2aa54
We decided to ignore its contribution during our manufacturing flow for the forecast qty to be correctly computed.This requires to ignore the contribution of each mo triggering the scheduler and those that already triggered the scheduler since the confirmation of the MO of FP.
Notes: The test sets a little more complex MO overview than the above use case to be sure to catch corner cases situations.
opw-3689920
-
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#153400This fix resolves a crash that occurred when users refreshed the page too quickly while the Website Preview was still loading. Previously, a recent update allowed users to stay in the backend while refreshing, but it didn't handle the case where the preview wasn't fully loaded yet. Now the system gracefully falls back to a standard refresh in these situations, preventing the error.
Original PR description
Commit [1] made it possible to stay in the backend while refreshing the page with F5 or CTRL+R when viewing a Website Preview. Pressing it too fast when the page is still loading and the iframe isn't loaded yet triggers a traceback. This commit falls back to the default refresh in such cases. [1]: https://github.com/odoo/odoo/commit/e69c6eaed4e82e08d6bbf807cf4698f6327a9cdd task-3795143 Forward-Port-Of: odoo/odoo#157129
This fix ensures that when public holidays are added or removed within a leave period, the leave duration displays correctly in both the list view and form view. Previously, the duration would update in the form view but not in the list view, causing confusion. The fix ensures both views stay synchronized by properly triggering duration recalculation whenever relevant leave data changes.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Create a leave spanning multiple days; 2. create a public holiday that falls inside that leave; 3. check leave in list view & form view. Issue ----- The leave's duration no longer matches between the two views. In form view, the duration was updated, in list view, it remained unchanged. Cause ----- The field in form view uses a non-stored computed field `number_of_days_display`, whereas the field used in the list view is the stored computed field `duration_display` which depends on the non-stored one. As a consequence, changes to the non-stored field don't trigger a recomputation of the stored field, leaving it unchanged. Solution -------- Call `_compute_duration_display` from the compute methods of its dependents, and add the dependents to the view as invisible fields to trigger recomputation. opw-3642500 Forward-Port-Of: odoo/odoo#157210
Fixed an issue in the web editor where table cells remained selected even after using arrow keys to move the cursor. Users can now properly deselect cells by navigating with arrow keys, improving the editing experience when working with tables.
Original PR description
**Current behaviour before commit:** After selecting cells in table, moving cursor through arrowkeys doesn't deselect cells. **Desired behaviour after commit:** Now cells are getting deselected. task-3718716 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153365
Project update descriptions can now be edited collaboratively by multiple team members, just like other project fields. This improvement was previously overlooked when the collaborative editing feature was implemented, and this fix ensures consistency across all project update fields.
Original PR description
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#157954 Forward-Port-Of: odoo/odoo#157817
When a sales invoice is reversed through a credit note, the customer portal now correctly displays a "Reversed" badge instead of incorrectly showing "Waiting Payment". This ensures customers see accurate payment status information for their orders in the portal.
Original PR description
Steps: - Install sales app. - Create SO and add a product. - Confirm that SO and create invoice and post it. - Reverse that invoice via adding credit note. - Go to portal view of that SO. Issue: - `Waiting Payment` badge is displaying instead of `Paid` as invoice is reversed Cause: - Only to payment status added to display `Paid` badge. Fix: - Add `Reversed` badge in portal and display reversed badge when payment_state is in reversed state. opw-3677622 Forward-Port-Of: odoo/odoo#158149 Forward-Port-Of: odoo/odoo#157693
Fixed an issue where radio button filters on mobile devices weren't responding to clicks on the button itself, only on the label. This update ensures customers can easily interact with filter options on their phones and tablets. Additionally, improved the visual contrast of tag filters for better readability.
Original PR description
Before this commit, radio buttons in the offcanvas filters (displayed on mobile) were not working as they should: clicking on the label worked fine but the click on the radio itself did not trigger anything. We impeach input's `pointer-event` so, the `<a>` becomes main and only interaction This commit also fixes an contrast issue in the tag filter in the offcanvas task-3649662 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147129
This update fixes the calculation of box 200 in the Swiss tax report to accurately represent the gross taxed amount. The fix removes purchase-related boxes (382 and 383) that were incorrectly included, and adds boxes 205 and 289 to provide the correct total. This ensures that box 299 properly reflects the net amount for tax reporting purposes.
Original PR description
With this PR https://github.com/odoo/odoo/pull/129717 we fixed multiple problems of the Swiss tax report but the 200 box is still not correct. Fix the computation of the box 200 of the Swiss tax report. We remove 382 and 383 boxes that are for purchases and shouldn't be included. We add box 205 and 289 so that the box 200 somehow represent the "gross" taxed amount, and 299 is therefore the "net" amount. 200 = 302 to 343 + 205 + 289 opw-3766215 Forward-Port-Of: odoo/odoo#158406 Forward-Port-Of: odoo/odoo#158008
This fix resolves an issue where sharing a webpage to social media (like X/Twitter) would fail when a custom SEO title was set without the standard website name separator. The update prevents the sharing feature from crashing when it cannot find the expected website name in the page title, allowing users to share forum posts and other pages with custom SEO titles without errors.
Original PR description
Since [1] when the social share widget was introduced, a hashtag is generated from the name of the website that is found inside the page title. This fails when the page title is replaced through the SEO feature. This commit prevents the failure but not extracting the website name if it is missing from the title. Steps to reproduce: - Install website_forum. - Go to a forum post. - Set SEO title to a value without `|` (pipe). - Share to X. => An error popup was shown. [1]: https://github.com/odoo/odoo/commit/1c91e27c8c8cb7492d26f03e27c4991b53a1675d opw-3799914 Forward-Port-Of: odoo/odoo#158064
This update removes the background color from CRM enrichment email messages so they display properly in both light and dark mode themes. This improves the visual consistency and readability of automated enrichment emails sent to users regardless of their interface theme preference.
Original PR description
Removed background color of crm enrich mail messages, so that they look good on both light and dark mode Related task: 3541419 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#158119 Forward-Port-Of: odoo/odoo#158003