Daily updates from Odoo
Monday, July 29, 2024
18 changes · master
Enhancements to existing features
The event form now places the social menu setting in a dedicated Sub-menu tab. This makes the event setup screen easier to navigate and helps users find related website menu options more quickly.
Original PR description
**Specifications:** Modify event form and move 'social_menu' field to 'Sub-menu' tab. **After this commit:** 'social_menu' field will be moved in the newly created 'Sub-menu' tab. Please refer the related community PR for better understanding. Task-4010675
Resolved issues and error corrections
Australian payroll users now have a dedicated menu item to access termination payments. This restores easier access after a previous workflow change and keeps payroll forms less cluttered.
Original PR description
Termination flow was removed in a previous commit. https://github.com/odoo/enterprise/commit/9d21446069dfc794fcf7b0f7bb4ced90202cbd05 This commit adds a menu item for the Termination Payments to avoid too many actions on the form view.
Code cleanup and technical improvements
This change reorganizes how extra record details are prepared for Approvals, VoIP, and WhatsApp features. It reduces repeated technical handling behind the scenes, making future maintenance easier without changing the user experience.
Original PR description
\* = approvals, voip, whatsapp This allows to easily set extra values on records without having to repeat the model name or the id in many different places. Part of task-3605717 https://github.com/odoo/odoo/pull/174507
Miscellaneous changes
It turns out we've been sending the wrong value in the state field [1]. This hasn't caused issues for the majority of states, but some states reject invoices if they don't have the right code (e.g. Minas Gerais). opw-4076445 [1] The specification mentions state *code*: https://avataxbr-docs.avalarabrasil.com.br/#/Invoice%20Goods/sendInvoiceGoods Forward-Port-Of: odoo/enterprise#67476
Original PR description
It turns out we've been sending the wrong value in the state field [1]. This hasn't caused issues for the majority of states, but some states reject invoices if they don't have the right code (e.g. Minas Gerais). opw-4076445 [1] The specification mentions state *code*: https://avataxbr-docs.avalarabrasil.com.br/#/Invoice%20Goods/sendInvoiceGoods Forward-Port-Of: odoo/enterprise#67476
Steps to Reproduce: ----------- - Install sale planning. - Create a sale order with a plan product. - Navigate to the Planning app > Schedule > By Resource. - Click on a cell in the "Open Shifts" line. - Select a resource. - Save and close. - Check the shift resource. Issue: ---------- The shift is not being created in the open shift section based on the parameters selected by the user. Fix: ---------- When creating a shift from the open shift section, it
Original PR description
Steps to Reproduce: ----------- - Install sale planning. - Create a sale order with a plan product. - Navigate to the Planning app > Schedule > By Resource. - Click on a cell in the "Open Shifts" line. - Select a resource. - Save and close. - Check the shift resource. Issue: ---------- The shift is not being created in the open shift section based on the parameters selected by the user. Fix: ---------- When creating a shift from the open shift section, it should generate shifts according to the parameters selected by the user, such as resource, date, etc. task-3919549 Forward-Port-Of: odoo/enterprise#67248 Forward-Port-Of: odoo/enterprise#64203
Currently, if a user uses a sale order sequence that contains special characters like `/` (e.g. SO/2024/12/31/01), they do not see such a sale order in suggestions in bank reconciliation if the label doesn't match the name of the sale order exactly. That is, a label `SO/2024/12/31/01 test` would not much this sale order, but a label `SO2024123101 test` would much a sale order with a name `SO2024123101`. This is because we format tokens and filter out special characters and then compare them t
Original PR description
Currently, if a user uses a sale order sequence that contains special characters like `/` (e.g. SO/2024/12/31/01), they do not see such a sale order in suggestions in bank reconciliation if the label doesn't match the name of the sale order exactly. That is, a label `SO/2024/12/31/01 test` would not much this sale order, but a label `SO2024123101 test` would much a sale order with a name `SO2024123101`. This is because we format tokens and filter out special characters and then compare them to names. With this commit, we'll compare names and tokens that are formatted the same way. opw-3964898 Forward-Port-Of: odoo/enterprise#67471 Forward-Port-Of: odoo/enterprise#67176
We should not raise during the Send & Print. Otherwise, when sending a batch of invoices and one of them is raising errors, none will be sent. no task Forward-Port-Of: odoo/enterprise#66326
Original PR description
We should not raise during the Send & Print. Otherwise, when sending a batch of invoices and one of them is raising errors, none will be sent. no task Forward-Port-Of: odoo/enterprise#66326
Speed up the shop floor by drastically reducing the number of refresh calls. We try to avoid a refresh of data from the server as much as possible. If an update is still unavoidable, we try to only refresh the relevant MO. task-4048415 Forward-Port-Of: odoo/enterprise#66898
Original PR description
Speed up the shop floor by drastically reducing the number of refresh calls. We try to avoid a refresh of data from the server as much as possible. If an update is still unavoidable, we try to only refresh the relevant MO. task-4048415 Forward-Port-Of: odoo/enterprise#66898
In Peru, we don't prevent invoices with the same name from being created. Invoices with the same name, same document type and same company RUC will be reported to SUNAT with the same `edi_filename`. SUNAT rejects those invoices as duplicates, which is good. However, our fallback mechanism of retrieving the existing CDR for those invoices and marking the invoice as sent is not good in this situation. Indeed, the user should be notified that the invoice was rejected, prompting them to resequenc
Original PR description
In Peru, we don't prevent invoices with the same name from being created. Invoices with the same name, same document type and same company RUC will be reported to SUNAT with the same `edi_filename`. SUNAT rejects those invoices as duplicates, which is good. However, our fallback mechanism of retrieving the existing CDR for those invoices and marking the invoice as sent is not good in this situation. Indeed, the user should be notified that the invoice was rejected, prompting them to resequence their invoice. Instead, they get the impression that their invoice was correctly sent to SUNAT. To fix this, we don't try to retrieve an existing CDR if an invoice was rejected as duplicate, but there already exists an invoice with the same edi_filename that was sent to SUNAT. opw-3900393 Forward-Port-Of: odoo/enterprise#67161 Forward-Port-Of: odoo/enterprise#65520
Steps to reproduce: - Open the Profit & Loss report - Create a budget using the budget filter - Audit a cell of the report Issue: A traceback occurs, indicating a string or bytes-like object error. Cause: In the previous commit https://github.com/odoo/enterprise/commit/8f19af2335d4199a306d9db489cbac1db656a0cb, the markup of line IDs was modified to include dictionaries for groupby information. However, one 'groupby' was overlooked, causing a traceback due to the system expecting a
Original PR description
Steps to reproduce: - Open the Profit & Loss report - Create a budget using the budget filter - Audit a cell of the report Issue: A traceback occurs, indicating a string or bytes-like object error. Cause: In the previous commit https://github.com/odoo/enterprise/commit/8f19af2335d4199a306d9db489cbac1db656a0cb, the markup of line IDs was modified to include dictionaries for groupby information. However, one 'groupby' was overlooked, causing a traceback due to the system expecting a string instead of a dictionary. Fix: This commit corrects the missing 'groupby' case to handle dictionaries properly,preventing the traceback. Additional Changes: Updated a related comment to reflect the new markup handling for consistency. task-3791247 Forward-Port-Of: odoo/enterprise#67337
With this PR : ========================== - Previously, when producing the entire quantity of a product, new component lines were created, ignoring reserved components. - This change uses the reserved components instead of creating new ones. Task-id : 4012314 Forward-Port-Of: odoo/enterprise#65559
Original PR description
With this PR : ========================== - Previously, when producing the entire quantity of a product, new component lines were created, ignoring reserved components. - This change uses the reserved components instead of creating new ones. Task-id : 4012314 Forward-Port-Of: odoo/enterprise#65559
Before this fix, one couldn't move documents to the parents workspaces. This was due to a check on the 'active' class of the target's child elements and not only on his direct descendant. This commit fix this by adding ':scope > ' to the selector. Task-3999790 Forward-Port-Of: odoo/enterprise#65000
Original PR description
Before this fix, one couldn't move documents to the parents workspaces. This was due to a check on the 'active' class of the target's child elements and not only on his direct descendant. This commit fix this by adding ':scope > ' to the selector. Task-3999790 Forward-Port-Of: odoo/enterprise#65000
- Added missing pot/po files/translations for l10_cl_edi_pos - Converted website_sale file from es_CL => es_419 so the translations will show for other LATAM countries/langs - Added missing pot file + added missing terms/translations to website_sale module opw-4044338 Forward-Port-Of: odoo/enterprise#67429
Original PR description
- Added missing pot/po files/translations for l10_cl_edi_pos - Converted website_sale file from es_CL => es_419 so the translations will show for other LATAM countries/langs - Added missing pot file + added missing terms/translations to website_sale module opw-4044338 Forward-Port-Of: odoo/enterprise#67429
### Steps to reproduce: - Install hr_holidays_contract_gantt module - Create two employees one with a contract and another without - Create a time off for each employee - Check Time Off -> Overview ### Current behavior before PR: The employee who has a contract will have grey cells on weekend days that are coming after his contract start date but the ones before will be white. The employee who has no contract won't have any grey cells neither for his off days nor the weekend days.
Original PR description
### Steps to reproduce: - Install hr_holidays_contract_gantt module - Create two employees one with a contract and another without - Create a time off for each employee - Check Time Off -> Overview ### Current behavior before PR: The employee who has a contract will have grey cells on weekend days that are coming after his contract start date but the ones before will be white. The employee who has no contract won't have any grey cells neither for his off days nor the weekend days. ### Desired behavior after PR is merged: Both employees should show the grey cells in the gantt view whether they have contract or not because if so we fallback on the employee working hours and then company's working hours 'According to the PO' opw-3961873 Forward-Port-Of: odoo/enterprise#67432 Forward-Port-Of: odoo/enterprise#65470
When the customer tries to create an asset for multiple journal items from different companies, a traceback will appear. Steps to reproduce the error: - Create an invoice with Company A - Create an invoice with Company B - Go to Accounting > Journal Items > select both invoice > Create Asset Traceback: ``` ValueError: Expected singleton: res.company(1, 5) File "odoo/http.py", line 2248, in __call__ response = request._serve_db() File "odoo/http.py", line 1823, in _serve_db
Original PR description
When the customer tries to create an asset for multiple journal items from different companies, a traceback will appear. Steps to reproduce the error: - Create an invoice with Company A - Create an…
When the customer tries to create an asset for multiple journal items from
different companies, a traceback will appear.
Steps to reproduce the error:
- Create an invoice with Company A
- Create an invoice with Company B
- Go to Accounting > Journal Items > select both invoice > Create Asset
Traceback:
```
ValueError: Expected singleton: res.company(1, 5)
File "odoo/http.py", line 2248, in __call__
response = request._serve_db()
File "odoo/http.py", line 1823, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1843, 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 1821, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1828, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2053, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 756, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 42, in call_button
action = self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, 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 "home/odoo/src/enterprise/saas-17.2/account_asset/models/account_move.py", line 315, in turn_as_asset
'default_company_id': self.company_id.id,
File "odoo/fields.py", line 5183, in __get__
raise ValueError("Expected singleton: %s" % record)
```
https://github.com/odoo/enterprise/blob/9373f9bac47839e3314a7823e05d4ef61af0b3e3/account_asset/models/account_move.py#L345 Here, When the user creates an asset for multiple journal items from
different companies, Self has multiple 'company_id'.
So it will lead to the above traceback.
sentry-5613448397
Forward-Port-Of: odoo/enterprise#67417
Forward-Port-Of: odoo/enterprise#66806Problem --------- Currently, if you install l10n_xx and update some specific account codes (depending on the localization) and then try to install the corresponding l10n_xx_hr_payroll_account hr module, you are struck with an error that cancels the installation as some accounts are missing. 1. Install l10n_ae for example 2. Switch to AE company 3. Update the account with code 201002 to 701002 4. Install l10n_ae_hr_payroll_account -> Error occurs during the installation Objective ----
Original PR description
Problem --------- Currently, if you install l10n_xx and update some specific account codes (depending on the localization) and then try to install the corresponding l10n_xx_hr_payroll_account hr module, you are struck with an error that cancels the installation as some accounts are missing. 1. Install l10n_ae for example 2. Switch to AE company 3. Update the account with code 201002 to 701002 4. Install l10n_ae_hr_payroll_account -> Error occurs during the installation Objective --------- Be able to install the module even when the account is missing. Solution --------- Log a warning instead of raising an error. opw-3961798 Forward-Port-Of: odoo/enterprise#67345 Forward-Port-Of: odoo/enterprise#67241
Issue: =============== When a manufacturing order (MO) is created, the default components are automatically reserved and are made visible in the barcode module. However, even if these components are later unreserved, they will continue to be displayed in the barcode module. Resolution: ================ To address this issue, we've taken the step to avoid forcefully re-reserving the components when a component is unreserved. This resolves the persistent display of components in t
Original PR description
Issue: =============== When a manufacturing order (MO) is created, the default components are automatically reserved and are made visible in the barcode module. However, even if these components are…
Issue: =============== When a manufacturing order (MO) is created, the default components are automatically reserved and are made visible in the barcode module. However, even if these components are later unreserved, they will continue to be displayed in the barcode module. Resolution: ================ To address this issue, we've taken the step to avoid forcefully re-reserving the components when a component is unreserved. This resolves the persistent display of components in the barcode. Steps to Reproduce: ====================== 1. Create a manufacturing order (MO) and confirm it. 2. Navigate to the barcode module within the manufacturing order. 3. By default, the components are reserved, so they are visible in the barcode module. 4. Go to the form view of the MO in MRP and unreserve the components. 5. Check the barcode module again, and notice that the unreserved components are still visible. Expected Result: ================== After implementing the solution, When we opens the MO in the barcode module only reserved components should be visible. When a component is unreserved, it should no longer be visible in the barcode module for manufacturing order. task-3869731 Forward-Port-Of: odoo/enterprise#66679 Forward-Port-Of: odoo/enterprise#61827
Refs. commits message for steps to reproduce COMMIT 1: ---------------- Issue: ------ One attachment has been removed (not linked anymore to the move). Cause: ------ When switching the main attachment, the versioning is triggered; the new main attachment is set on the document and the previous is added to the history for versioning (and therefore also change the res fields to be linked to the document instead of the move). Solution: --------- When updating the attachm
Original PR description
Refs. commits message for steps to reproduce COMMIT 1: ---------------- Issue: ------ One attachment has been removed (not linked anymore to the move). Cause: ------ When switching the main…
Refs. commits message for steps to reproduce COMMIT 1: ---------------- Issue: ------ One attachment has been removed (not linked anymore to the move). Cause: ------ When switching the main attachment, the versioning is triggered; the new main attachment is set on the document and the previous is added to the history for versioning (and therefore also change the res fields to be linked to the document instead of the move). Solution: --------- When updating the attachment of a document that already have an attachment (normal versioning), we should remove the link between the current document attachment (not the new one) and the related model only if the related model has not a `message_main_attachment_id` field or if the current document attachment is different of the main attachment set on the related model. COMMIT 2: ---------------- Issue: ------ A second document is created. Cause: ------ The issue is when switching the second time the invoice main attachment, the current main attachment is in fact in the versioned attachments (`document.preview_attachment_ids`), and since we search only for document that have as attachment (`document.attachment_id`) the current invoice main attachment, we don't find it and create a new document. Solution: --------- Look also in the versioned attachments when searching for the invoice main attachment in case it has been versioned. opw-4028789 Forward-Port-Of: odoo/enterprise#67464 Forward-Port-Of: odoo/enterprise#66501