Tuesday, February 25, 2025
13 changes · 17.0
Enhancements to existing features
The Mexican localization now includes a default ISR 1.25% withheld tax for RESICO-related use cases. This helps businesses using Odoo in Mexico apply the correct tax setup more easily and reduces manual configuration.
Original PR description
This commit adds new tax ISR 1.25 witheld RESICO for mexican localization target: 17 -> master task-4486643 Linked PR: [odoo/enterprise#80081](https://github.com/odoo/enterprise/pull/80081) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Mexican localization now includes the ISR 1.25% withholding tax as default data. This helps companies in Mexico apply the correct tax setup more easily and supports compliance with local reporting requirements.
Original PR description
This commit adds new tax ISR 1.25 witheld for mexican localization target: 17 -> master task-4486643 Linked PR: [odoo/odoo#195346](https://github.com/odoo/odoo/pull/195346)
Resolved issues and error corrections
Disconnecting Wi-Fi on the POS box now updates the current configuration file instead of trying to remove an outdated file. This prevents stale settings from remaining and helps ensure network changes apply reliably.
Original PR description
The Wi-Fi disconnection method was still unlinking an old configuration file, which is now replaced by the `odoo.conf` file. This fix replaces the file unlinking by a coniguration file update. Task: 4592796
Miscellaneous changes
config['demo'] is always set at runtime, there is no point in saving it as it is basically ignored from the config file. Forward-Port-Of: odoo/odoo#189032
Original PR description
config['demo'] is always set at runtime, there is no point in saving it as it is basically ignored from the config file. Forward-Port-Of: odoo/odoo#189032
Uploading an invalid PDF as quotation header pages no longer causes an unexpected system error. The system now catches unreadable PDF files and shows a validation message, helping users correct the upload without disruption.
Original PR description
Currently, an error occurs when uploading an invalid PDF as a quotation header pages. Step to produce: - Install the 'sale_pdf_quote_builder' module. - Open a sales configuration, And unload an invalid pdf file as a 'Header pages' in the 'Quotations & Orders' section ```PdfReadError:EOF marker not found``` An error occurs when the system tries to read file content through the PDF file reader at [1]. But it is invalid. Link [1]: https://github.com/odoo/odoo/blob/32c521820e77f67966fa71c7ecabde09d2ab27d4/addons/sale_pdf_quote_builder/utils.py#L11 To handle this issue, Add a try-except block to ensure that if an error occurs during the pdf file read it raises a validation error. Sentry-5879869841 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now create a new contact directly from an approval request without encountering a Missing Record error. The approval form no longer passes approval-specific category information into the contact creation flow, preventing incorrect data from blocking the action.
Original PR description
Issue: When the user tries to create a contact from the approval form, they get a "Missing Record" error. Steps to reproduce: - Install the Approvals app - Create a new Approval Type with Contact set as either 'Required' or 'Optional' - When creating a new Request from the created Type, try to create a new Contact Cause: Both Approvals and Partners have a 'category_id' field. In the approval form, the context has the approval's value for 'category_id', which is being used for the partner creation. Solution: In the approval form view, change the context used by the partner field to not have a default 'category_id'. Ticket: opw-4328371
Belgian payroll calculations now use the updated private car reimbursement rates through February 2025. This helps ensure employee payslips and related payroll accounting reflect the latest applicable reimbursement amounts.
Original PR description
…2025
The CRON has to search for documents that are not in error because they are filtered out in _process_jobs. Without that, the documents are retrieved, not processed but the cron is triggered again and again endlessly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198973
Original PR description
The CRON has to search for documents that are not in error because they are filtered out in _process_jobs. Without that, the documents are retrieved, not processed but the cron is triggered again and again endlessly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198973
Backport a part of 40da85aab905fd4accf8c01887e62b07537ccd2f. Make some of the ORM methods private for the sake of correctness and to prevent people from using incorrect RPC calls. We are targeting methods that return recordsets that are not returned in the correct format in RPC. This commit doesn't strictly follow our stable policy, but it's unlikely to break anything. Small change to the original version: we are not directly modifying odoo.api.call_kw(), as it is used by _eval_xml() and w
Original PR description
Backport a part of 40da85aab905fd4accf8c01887e62b07537ccd2f. Make some of the ORM methods private for the sake of correctness and to prevent people from using incorrect RPC calls. We are targeting…
Backport a part of 40da85aab905fd4accf8c01887e62b07537ccd2f. Make some of the ORM methods private for the sake of correctness and to prevent people from using incorrect RPC calls. We are targeting methods that return recordsets that are not returned in the correct format in RPC. This commit doesn't strictly follow our stable policy, but it's unlikely to break anything. Small change to the original version: we are not directly modifying odoo.api.call_kw(), as it is used by _eval_xml() and we don't want to change that in stable (or we need to backport part of https://github.com/odoo/odoo/pull/182709). #### Original commit message Explicitly prevent calling non-public ORM methods via RPC, without breaking the API The ORM contains a series of API methods found on Models and recordsets, next to the main CRUD methods. Those utility methods are very commonly used in server-side business logic code, and were historically named without the usual underscore prefix that should mark them as private (e.g. `_private_method()` vs `public_method()`). Examples: - the `browse()` method returns a recordset from a list of IDs, which is really just a proxy object prepared for other recordset operations ; - the `fetch()` and `search_fetch()` methods populate the transactional in-memory cache for a set of fields and record ; - and many more... The lack of prefix makes writing business logic code a bit simpler, but causes confusion because these methods look like they are public. Of course, calling such internal methods over RPC doesn't make sense, and may crash or cause unexpected results. This commit marks those internal methods and prevents calling them over RPC. This is preferred over renaming them with an underscore prefix, as that would break a lot of existing code without a good reason. All business logic code must still follow the best-practicce convention of prefixing non-public method with underscores, by default and by design, to avoid mixing different conventions. The `@api.private` decorator is reserved for exceptions for ORM methods. task-4505030 https://github.com/odoo/enterprise/pull/79382 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197783
Steps to reproduce: ------------------- - being in a multi-company environment; - have one product made that is first in alphabetical order of "Internal Reference" throughout the database (e.g. [AAA]); - make this product specific to one of the companies (set the "Company" field on the product template) - go into a different company within the database (not the one set on this product); - create a new discount & loyalty record, and set the "Program Type" to "Discount Code". Issue: ----
Original PR description
Steps to reproduce: ------------------- - being in a multi-company environment; - have one product made that is first in alphabetical order of "Internal Reference" throughout the database (e.g. [AAA]); - make this product specific to one of the companies (set the "Company" field on the product template) - go into a different company within the database (not the one set on this product); - create a new discount & loyalty record, and set the "Program Type" to "Discount Code". Issue: ------ An access rights error occurs. Cause: ------ When creating a `promo_code` program, we use the first product that can be sold in the default reward values. Solution: --------- Take into account the company in the domain that retrieves the default product. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198460
Before this patch, if a billing user (without any administration settings level) tried to cancel a posted invoice and clicked on the "Process now" button, they got an exception. In particular, it happened because those users shouldn't have access to stuff such as the certificate, its password or the contents of the sent EDI attachment. However, they should be able to post the documents using whatever configuration the sysadmin saved. Thus, I use some `sudo()` calls and add a test to assert
Original PR description
Before this patch, if a billing user (without any administration settings level) tried to cancel a posted invoice and clicked on the "Process now" button, they got an exception. In particular, it happened because those users shouldn't have access to stuff such as the certificate, its password or the contents of the sent EDI attachment. However, they should be able to post the documents using whatever configuration the sysadmin saved. Thus, I use some `sudo()` calls and add a test to assert it won't break anymore. **How to test functionally:** 1. Configure a Spanish company. 2. Install `l10n_es_edi_tbai` and configure it. 3. Switch to a user that only has "Invoicing / Billing" permissions. 4. Post an invoice. 5. Send it to tbai. 6. Request EDI cancellation. 7. Send it to tbai. 8. It should work now. @moduon MT-8894 OPW-4535149 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195981
`odoo.models.check_method_name` is softly deprecated, replace usages by the new method. task-4505030 https://github.com/odoo/odoo/pull/197783 Forward-Port-Of: odoo/enterprise#79382
Original PR description
`odoo.models.check_method_name` is softly deprecated, replace usages by the new method. task-4505030 https://github.com/odoo/odoo/pull/197783 Forward-Port-Of: odoo/enterprise#79382
Problem --------- Follow-ups can be configured to execute multiple type of follow-ups (email, whatsapp, sms, ...) One of those is to print a letter, but it's not the most used. When you try to execute a follow-up manually, a wizard opens and follows the setup of the to-be-executed level ; so for example if the next level is configured to send a SMS, SMS should be ticket by default. But the "Print" option is always ticked, even if the "Letter" option is not selected in the configuration
Original PR description
Problem --------- Follow-ups can be configured to execute multiple type of follow-ups (email, whatsapp, sms, ...) One of those is to print a letter, but it's not the most used. When you try to execute a follow-up manually, a wizard opens and follows the setup of the to-be-executed level ; so for example if the next level is configured to send a SMS, SMS should be ticket by default. But the "Print" option is always ticked, even if the "Letter" option is not selected in the configuration of the level. This always generates an additional PDF that is often not needed. Objective --------- Do not tick "Print" by default when manually executing a follow-up level, unless "Letter" is ticket in the configuration of the level. Solution --------- Set "Print" default value in the wizard to the "Letter" value of the follow up line instead of leaving it as True (which is the default). task-4574971 Forward-Port-Of: odoo/enterprise#79829