Odoo Changelog — 2024-10-18

Friday, October 18, 2024

25 changes · saas-17.4

Bug Fixes(2)

Resolved issues and error corrections

[FIX] web_editor: remove border-color from forced grouped styles

Coresaas-17.4web_editor

This fix prevents table border colors added in dark mode from being saved in a way that looks wrong after switching back to light mode. It helps keep chatter messages visually consistent and avoids environment-dependent test failures between Odoo editions.

Original PR description

Issue: ====== - The border-color of the table is different in light mode and dark mode. - convert_inline_test which have the border-color fails because it depends if we are in enterprise or…

Issue:
======
- The border-color of the table is different in light mode and dark mode.
- convert_inline_test which have the border-color fails because it depends
  if we are in enterprise or community. Issue [1].

Steps to reproduce the issue:
=============================
- Go to any record with chatter
- Switch dark mode
- Add a table
- Log it
- Switch light mode
- The border-color is different than a table added in light mode.

Origin of the issue:
====================
We already have a commit [2] that removes the border-colors from the
cssRules since it really depends on the mode. After this [3] we forced
to apply the border-color from the computed value which will be wrong.

Solution:
=========
We remove the border-color from the forced styles.

[1]: https://runbot.odoo.com/web#id=103155&view_type=form&model=runbot.build.error&menu_id=405&cids=1
[2]: https://github.com/odoo/odoo/commit/16ab970fa33119a4fc1a9c5dd249ca467ff3b2c8
[3]: https://github.com/odoo/odoo/commit/1e654e8f7e0a403a25b595be410614dfc8a69179

#dark-mode#tables#chatter#visual-consistency

[FIX] mrp: prevent error when clicking on Done button in WorkOrder

PR #183170

Coresaas-17.4mrp

This fix prevents an error when users click Done on a newly added work order before saving the manufacturing order. It improves reliability in manufacturing workflows by avoiding a crash and keeping the user action from triggering invalid processing.

Original PR description

When the customer creates the workorder for MO and clicks on the Done button without saving the record, a traceback will appear. Steps to reproduce the error: - Create one MO > Work Orders > Add a…

When the customer creates the workorder for MO and clicks on the Done button
without saving the record, a traceback will appear.

Steps to reproduce the error:
- Create one MO > Work Orders > Add a line > Click on Dropdown > Click on Done

Traceback:
```
IndexError: tuple index out of range
  File "odoo/http.py", line 2364, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1891, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1954, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 137, in retrying
    result = func()
  File "odoo/http.py", line 1921, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2168, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 330, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 728, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 35, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 517, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "home/odoo/src/enterprise/18.0/mrp_workorder/models/mrp_workorder.py", line 876, in action_mark_as_done
    self.button_finish()
  File "home/odoo/src/enterprise/18.0/mrp_workorder/models/mrp_workorder.py", line 303, in button_finish
    return super().button_finish()
  File "addons/mrp/models/mrp_workorder.py", line 661, in button_finish
    workorder.with_context(bypass_duration_calculation=True).write(vals)
  File "home/odoo/src/enterprise/18.0/mrp_workorder/models/mrp_workorder.py", line 114, in write
    res = super().write(values)
  File "addons/mrp/models/mrp_workorder.py", line 475, in write
    if workorder == workorder.production_id.workorder_ids[0] and 'date_start' in values:
  File "odoo/models.py", line 7004, in __getitem__
    return self.browse((self._ids[key],))
```

https://github.com/odoo/odoo/blob/a082495359a2e6a2bf25cc3744eb80fd6899f5d1/addons/mrp/models/mrp_workorder.py#L462 Here, when customer clicks on the Done button without saving the record,
``workorder_ids`` will be empty, so it will lead to the above traceback.

https://github.com/odoo/odoo/blob/a082495359a2e6a2bf25cc3744eb80fd6899f5d1/addons/mrp/static/src/components/wo_list_view_dropdown/wo_list_view_dropdown.js#L52-L61
Here, ``ids`` is ``false`` because the record is not saved yet,
It will call the ``action_mark_as_done`` method with ``false`` ids,
eventually, it will generate the above traceback.

sentry-5973943945

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Other(23)

Miscellaneous changes

[FW][FIX] stock: reconcile outgoing moves in forecast

PR #184269

Coresaas-17.4sale_stock

Original PR description

### Steps to reproduce:

- Enable "Multi-steps Routes" in the settings
- Inventory > COnfiguration > Warehouse Management > Warehouses
- Change your warehouse settings to Deliver in 2 steps
- Create a Storable product P with 10 units in stock
- Create and confirm an SO for 1 unit of P
> A pick and a ship deliveries were created.
- Unreserve the PICK deliveries
- Go to the forecast of your product avaialbility
#### > the SO is unreconcilled and the product is treated as unavailable

### Cause of the issue:

Since you unreserved the PICK delivery, the demand of the outgoing move is not null in the forecast lines computations:
https://github.com/odoo/odoo/blob/91316ec8d55dbc5e1cd712568f614c62539bd807/addons/stock/report/stock_forecasted.py#L278 In addition, since you deliver in 2 steps the outgoing moves are part of a move chain. To generate this chain, the moves were created with an `make_to_order` `procure_method` and as such, the quantity considered to reconcile this move from stock is set to be at 0 here: https://github.com/odoo/odoo/blob/91316ec8d55dbc5e1cd712568f614c62539bd807/addons/stock/report/stock_forecasted.py#L283-L287 Furthermore, since there is no incoming moves made to reconcile this outgoing move (whcih happen for real "MTO" moves and not these flagged as MTO because they were part of a chain) the line will be created here and flagged as not repleinshed nor available:
https://github.com/odoo/odoo/blob/91316ec8d55dbc5e1cd712568f614c62539bd807/addons/stock/report/stock_forecasted.py#L295-L299 The forecast error

### Note:

The issue is not reproducible in 16.0 since the forecast datas computed by the `_get_report_lines` was drastically prior to the 17.0 version.

opw-4164403
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#183914
Forward-Port-Of: odoo/odoo#183211

Issue: ====== - The border-color of the table is different in light mode and dark mode. - convert_inline_test which have the border-color fails because it depends if we are in enterprise or community. Issue [1]. Steps to reproduce the issue: ============================= - Go to any record with chatter - Switch dark mode - Add a table - Log it - Switch light mode - The border-color is different than a table added in light mode. Origin of the issue: ==================== We already have a commit [2] that removes the border-colors from the cssRules since it really depends on the mode. After this [3] we forced to apply the border-color from the computed value which will be wrong. Solution: ========= We remove the border-color from the forced styles. [1]: https://runbot.odoo.com/web#id=103155&view_type=form&model=runbot.build.error&menu_id=405&cids=1 [2]: https://github.com/odoo/odoo/commit/16ab970fa33119a4fc1a9c5dd249ca467ff3b2c8 [3]: https://github.com/odoo/odoo/commit/1e654e8f7e0a403a25b595be410614dfc8a69179

When the customer creates the workorder for MO and clicks on the Done button without saving the record, a traceback will appear. Steps to reproduce the error: - Create one MO > Work Orders > Add a line > Click on Dropdown > Click on Done Traceback: ``` IndexError: tuple index out of range File "odoo/http.py", line 2364, in __call__ response = request._serve_db() File "odoo/http.py", line 1891, in _serve_db return self._transactioning( File "odoo/http.py", line 1954, in _transactioning return service_model.retrying(func, env=self.env) File "odoo/service/model.py", line 137, in retrying result = func() File "odoo/http.py", line 1921, in _serve_ir_http response = self.dispatcher.dispatch(rule.endpoint, args) File "odoo/http.py", line 2168, in dispatch result = self.request.registry['ir.http']._dispatch(endpoint) File "odoo/addons/base/models/ir_http.py", line 330, in _dispatch result = endpoint(**request.params) File "odoo/http.py", line 728, in route_wrapper result = endpoint(self, *args, **params_ok) File "addons/web/controllers/dataset.py", line 35, in call_kw return call_kw(request.env[model], method, args, kwargs) File "odoo/api.py", line 517, in call_kw result = getattr(recs, name)(*args, **kwargs) File "home/odoo/src/enterprise/18.0/mrp_workorder/models/mrp_workorder.py", line 876, in action_mark_as_done self.button_finish() File "home/odoo/src/enterprise/18.0/mrp_workorder/models/mrp_workorder.py", line 303, in button_finish return super().button_finish() File "addons/mrp/models/mrp_workorder.py", line 661, in button_finish workorder.with_context(bypass_duration_calculation=True).write(vals) File "home/odoo/src/enterprise/18.0/mrp_workorder/models/mrp_workorder.py", line 114, in write res = super().write(values) File "addons/mrp/models/mrp_workorder.py", line 475, in write if workorder == workorder.production_id.workorder_ids[0] and 'date_start' in values: File "odoo/models.py", line 7004, in __getitem__ return self.browse((self._ids[key],)) ``` https://github.com/odoo/odoo/blob/a082495359a2e6a2bf25cc3744eb80fd6899f5d1/addons/mrp/models/mrp_workorder.py#L462 Here, when customer clicks on the Done button without saving the record, ``workorder_ids`` will be empty, so it will lead to the above traceback. https://github.com/odoo/odoo/blob/a082495359a2e6a2bf25cc3744eb80fd6899f5d1/addons/mrp/static/src/components/wo_list_view_dropdown/wo_list_view_dropdown.js#L52-L61 Here, ``ids`` is ``false`` because the record is not saved yet, It will call the ``action_mark_as_done`` method with ``false`` ids, eventually, it will generate the above traceback. sentry-5973943945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

### Steps to reproduce: - Enable "Multi-steps Routes" in the settings - Inventory > COnfiguration > Warehouse Management > Warehouses - Change your warehouse settings to Deliver in 2 steps - Create a Storable product P with 10 units in stock - Create and confirm an SO for 1 unit of P > A pick and a ship deliveries were created. - Unreserve the PICK deliveries - Go to the forecast of your product avaialbility #### > the SO is unreconcilled and the product is treated as unavailable ### Cause of the issue: Since you unreserved the PICK delivery, the demand of the outgoing move is not null in the forecast lines computations: https://github.com/odoo/odoo/blob/91316ec8d55dbc5e1cd712568f614c62539bd807/addons/stock/report/stock_forecasted.py#L278 In addition, since you deliver in 2 steps the outgoing moves are part of a move chain. To generate this chain, the moves were created with an `make_to_order` `procure_method` and as such, the quantity considered to reconcile this move from stock is set to be at 0 here: https://github.com/odoo/odoo/blob/91316ec8d55dbc5e1cd712568f614c62539bd807/addons/stock/report/stock_forecasted.py#L283-L287 Furthermore, since there is no incoming moves made to reconcile this outgoing move (whcih happen for real "MTO" moves and not these flagged as MTO because they were part of a chain) the line will be created here and flagged as not repleinshed nor available: https://github.com/odoo/odoo/blob/91316ec8d55dbc5e1cd712568f614c62539bd807/addons/stock/report/stock_forecasted.py#L295-L299 The forecast error ### Note: The issue is not reproducible in 16.0 since the forecast datas computed by the `_get_report_lines` was drastically prior to the 17.0 version. opw-4164403 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183914 Forward-Port-Of: odoo/odoo#183211

Adhoc-task: 40503 Description of the issue/feature this PR addresses: 1- We removed the following taxes to avoid duplication: "ex_tax_retencion_suss_sufrida", "WTH SUSS I", which is already located here(https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06168a41e3a1a031fcfc467322ae0d78483523R2) "ex_tax_retencion_ganancias_sufrida", "WTH Earnings I", which is already located here (https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06168a41e3a1a031fcfc467322ae0d78483523R7) and here (https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06168a41e3a1a031fcfc467322ae0d78483523R12) 2- We moved the taxes from files to match the same structure as l10n_ar Current behavior before PR: After downloading l10n_ar_withholding and checking the taxes, we realized there were some duplicates. [[FIX]l10n_ar_withholding: repeated taxes in chart of accounts.webm](https://github.com/odoo/odoo/assets/109111493/56776d61-86f1-4632-98a4-c9e192cc5f3a) Desired behavior after PR is merged: The taxes are no longer duplicated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168945

There are two paths for a successful login via web_totp 1. The user has a cookie saved which saves them from having to enter the TOTP 2. The user is a new device / browser, enter the TOTP and a form is submitted Both call self._login_redirect but only the latter updates the env and context. This is a snippet to reproduce the bug: ```python @http.route() def web_totp(): response = super().web_totp(*args, **kw) if not request.env.user or request.env.user.is_public: return response do_something() ... ``` This would call `do_something` only when a user successfully logs in by putting the TOTP explicitly but not when they log in thanks to a cookie being set. Description of the issue/feature this PR addresses: Makes web_totp consistent for the 2 flows (submit totp or use cookie) Current behavior before PR: A code logic that works for web_login does not work for web_totp, or rather, it works only for one flow but not the other Desired behavior after PR is merged: A code logic that works for web_login also works for web_totp --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183838

This commit implements the changes needed after receiving the first feedback of the new `l10n_ro_efactura` module. (Send CIUSRO-XML to the SPV). It's also commonly known as "Romanian EDI" (`l10n_ro_edi` in master) Purpose: Index key (received and saved as `key_download`) is an important number that should be displayed so that the customer can easily reference the invoice in the SPV. For some customer, the state flow of E-Factura in Odoo is confusing as it doesn't match what they're used to in the SPV. This might be caused by the state name. Changes: - After receiving the `key_download`, log it in the invoice's chatter. - Save the `key_download` data and pass it in-between documents, to make sure that relevant documents displays the index. (and the idx doesn't get lost when "sending" document is deleted) - Change the display name of the statuses of the document. - Add a tooltip on the E-Factura status fields (move & document). The create document function helpers are changed to have one dictionary as the param signature so that we can pass on the new `key_loading` data (and any other important data in the future, for easier stable fix), and also to make it general (the same for all ro-documents) task-id: 4059522 Forward-Port-Of: odoo/odoo#179278

Bug Fixes(2)

[FIX] web_editor: remove border-color from forced grouped styles

[FIX] mrp: prevent error when clicking on Done button in WorkOrder

Other(23)

[FW][FIX] stock: reconcile outgoing moves in forecast

Bug Fixes(2)

[FIX] web_editor: remove border-color from forced grouped styles

[FIX] mrp: prevent error when clicking on Done button in WorkOrder

Other(23)

[FW][FIX] stock: reconcile outgoing moves in forecast

[FW][FIX] l10n_ar_withholding: repeated taxes in chart of accounts

[FW][FIX] auth_totp: update environment on successful login in web_totp

[FW][FIX] web_editor: ensure CSS consistency in printed PDFs

[FW][FIX] mail: avoid exception on closing composer

[FW][FIX] web: fix showing empty option when selection is required

[FW][FIX] event_registration: handle novel description field updating leads

[FW][FIX] l10n_sk: order of company values on reports

[FW][FIX] analytic: prevent test crash due to hr.timesheet

[FW][FIX] auth_totp_portal: allow revoking single devices

[FW][FIX] hr_timesheet: missing demo data on test_analytic_plan_setting

[FW][FIX] point_of_sale: correctly load last order after refresh

[FW][FIX] http_routing: don't consider path prefixed by _ as a lang during match

[FW][FIX] {google, microsoft}_calendar: fix traceback for rapid clicks calendar view

[FW][16.0][SEC] point_of_sale: add multi company rule for pos order line

[FW][IMP] l10n_ro_efactura: show document index, rename state display

[FW][FIX] helpdesk_sale_timesheet: restrict helpdesk ticket's SOL domain

[FW][FIX] iot: add missing sudo calls to `_default_token`

[FW][FIX] account_asset: propagate analytic distribution on depreciation …

[FW][FIX] account_online_sync: remove readonly for auto_sync

[FW][IMP] l10n_be_coda: allow easier override of CODA file parsing

[FW][FIX] account_avatax: create taxes on parent company

[FW][FIX] documents_project: fix label of use_documents field in project