Daily updates from Odoo
Navigate
Branch
Thursday, March 16, 2023
11 changes
Enhancements to existing features
Peruvian bank reference data has been moved from the electronic invoicing add-on into the core Peru localization module. This centralizes shared bank information so it can be reused more consistently across Peru-specific workflows.
Original PR description
Full res_bank data moved to 'l10n_pe' Enterprise PR: https://github.com/odoo/odoo/pull/95870 -- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
Features or functions removed from Odoo
This update removes a confusing project-related field from field service task screens and imports. Tasks without a project or parent task are now treated as private, while timesheets use the project from the task or its parent task, making data entry and imports clearer for users.
Original PR description
Before this commit, the `display_project_id` field was a bit confusing for the user to know what is the goal of this field. Also this field is available when the user wants to import his data into Odoo, if he does not know the goal of this field then he could be lost to know which field he should for his data to import (or even export). This commit removes the display_project_id field and so a task will be private one if the project and the parent fields are not set. The project to set to the timesheet will be the one set on the task or the one set on one of its parent tasks. task-3230063
Code cleanup and technical improvements
This update removes outdated setup instructions that controlled whether form screens opened in view or edit mode. Since forms now always open ready for editing, the cleanup keeps related apps aligned with the newer behavior and reduces maintenance risk without changing business workflows.
Original PR description
This commit is the counterpart of odoo/odoo#115172, where we drop the support of the form_view_initial_mode key in context, form views being always in edition now. In this commit, we clean up contexts containing that key. Part of task 3179751
Miscellaneous changes
It is possible to confirm a subscription without choosing a template. When we send an email to the customer with the invoice, it is important to have a default template to avoid sending an empty body. opw-3162564 task-3177575 Forward-Port-Of: odoo/enterprise#38235 Forward-Port-Of: odoo/enterprise#37987
Original PR description
It is possible to confirm a subscription without choosing a template. When we send an email to the customer with the invoice, it is important to have a default template to avoid sending an empty body. opw-3162564 task-3177575 Forward-Port-Of: odoo/enterprise#38235 Forward-Port-Of: odoo/enterprise#37987
before this commit, on clicking the archive button on l10n_mx_edi.payment.method records show the access right warning saying that no user group is allowed to perform this operation. after this commit, the billing user will be able to archive the payment methods. Forward-Port-Of: odoo/enterprise#38046
Original PR description
before this commit, on clicking the archive button on l10n_mx_edi.payment.method records show the access right warning saying that no user group is allowed to perform this operation. after this commit, the billing user will be able to archive the payment methods. Forward-Port-Of: odoo/enterprise#38046
When the test was running near 22:50, almost 2 weeks before the time change day, the test env was losing one hour exactly at the time of the return, thus making the return for the next day instead, which wasn't unavailable as it should have been. With this commit, we avoid using that specific hour. Forward-Port-Of: odoo/enterprise#38188
Original PR description
When the test was running near 22:50, almost 2 weeks before the time change day, the test env was losing one hour exactly at the time of the return, thus making the return for the next day instead, which wasn't unavailable as it should have been. With this commit, we avoid using that specific hour. Forward-Port-Of: odoo/enterprise#38188
### Background In PR #23171, we provided functionality such that when sending an invoice, if the invoice already exists in SUNAT, we catch the error and retrieve the CDR of the existing invoice. This was useful in situations where Odoo encounters an exception after the invoice is sent to SUNAT, which leads to an inconsistent state. However, that PR only implemented this for the IAP service. In this PR, we extend this functionality to the SUNAT and Digiflow services, so that there als
Original PR description
### Background In PR #23171, we provided functionality such that when sending an invoice, if the invoice already exists in SUNAT, we catch the error and retrieve the CDR of the existing invoice. This…
### Background
In PR #23171, we provided functionality such that when sending an invoice, if the invoice already exists in SUNAT, we catch the error and retrieve the CDR of the existing invoice.
This was useful in situations where Odoo encounters an exception after the invoice is sent to SUNAT, which leads to an inconsistent state.
However, that PR only implemented this for the IAP service.
In this PR, we extend this functionality to the SUNAT and Digiflow services, so that there also, if the invoice already exists, we retrieve the CDR.
### Implementation Notes
- We refactor the logic for retrieving the CDR if the invoice already exists:
- previously, the method that sends the invoice checked the error code, and if the code was 1033 or 4000 (document already exists), we would immediately try to retrieve the CDR.
- now, we have moved this logic to the `_post_invoice_edi` method, which reads the error code that was returned by the function that sends the invoice, and if it is 1033 or 4000, calls the method to try to retrieve the CDR.
- As a result, the method that sends the invoice (`_l10n_pe_edi_get_status_cdr_iap_service`) no longer needs to know the `serie_folio` of the invoice (which was only needed when retrieving the CDR). In master, we will therefore remove that parameter from the method definition.
- After retrieving the CDR, we check that the date and partner of the retrieved CDR match those of the invoice. If they don't match, this means that the retrieved CDR does not actually correspond to the invoice that was sent. In this case, we don't save the CDR with the invoice and we show the error to the user.
Forward-Port-Of: odoo/enterprise#37736
Forward-Port-Of: odoo/enterprise#30476The error message of voip is written in black in dark mode making it impossible to read Steps to reproduce: 1. Install VOIP 2. Enable dark mode (top right corner) 3. Go to Settings > General Settings > Integrations > Asterisk (VoIP) and change the VoIP Environment to 'Production' 4. Click on the VOIP icon, the dialing panel opens up but it is not usable (there is an error message but it's written in black on black) Solution: Render the text in white when dark mode is enabled Proble
Original PR description
The error message of voip is written in black in dark mode making it impossible to read Steps to reproduce: 1. Install VOIP 2. Enable dark mode (top right corner) 3. Go to Settings > General Settings > Integrations > Asterisk (VoIP) and change the VoIP Environment to 'Production' 4. Click on the VOIP icon, the dialing panel opens up but it is not usable (there is an error message but it's written in black on black) Solution: Render the text in white when dark mode is enabled Problem: The blockMsg is rendered with the class `text-white` but this sets the color of the text to black when dark mode is enabled opw-3210443 Forward-Port-Of: odoo/enterprise#38127
[FIX] partner_commission: Add 2 record rules to group 'Purchase / Administrator' Reason: When a User's 'Commission' Access Rights are set to either 'All Documents' or 'Own Documents Only', User is no longer able to create or see procurement POs. Fix: The 'Purchase / Administrator' group is missing record rules that allow selected Users to see all purchase_types of POs. Because the record rule domains in groups 'Commissions / All Documents' and 'Commissions / Own Documents Only' restrict to
Original PR description
[FIX] partner_commission: Add 2 record rules to group 'Purchase / Administrator' Reason: When a User's 'Commission' Access Rights are set to either 'All Documents' or 'Own Documents Only', User is no longer able to create or see procurement POs. Fix: The 'Purchase / Administrator' group is missing record rules that allow selected Users to see all purchase_types of POs. Because the record rule domains in groups 'Commissions / All Documents' and 'Commissions / Own Documents Only' restrict to 'commission' types only, this blocks the user from interacting with procurement POs. Adding these record rules to 'Purchase / Administrator' allows for the expected behavior (granting Commission access rather than restricting to it). opw-3199293 Forward-Port-Of: odoo/enterprise#38003
Before this commit, we were not sending all `user_infos` to the parse extract route for the invoices. Forward-Port-Of: odoo/enterprise#38205
Original PR description
Before this commit, we were not sending all `user_infos` to the parse extract route for the invoices. Forward-Port-Of: odoo/enterprise#38205
Check is added to prevent deactivating a currency set on a company. Some tests have to be changed to accommodate this. Task: 2852452 Forward-Port-Of: odoo/enterprise#38148 Forward-Port-Of: odoo/enterprise#37892
Original PR description
Check is added to prevent deactivating a currency set on a company. Some tests have to be changed to accommodate this. Task: 2852452 Forward-Port-Of: odoo/enterprise#38148 Forward-Port-Of: odoo/enterprise#37892