Wednesday, February 5, 2025
22 changes · 17.0
Enhancements to existing features
The payment system's background processing job is now disabled by default and only turns on when a payment provider is enabled. This reduces unnecessary system activity and performance overhead for databases that do not use online payments.
Original PR description
The payment post-processing cron is run every 10 minutes to ensure smooth operations, but waking up crons incurs a non-negligible performance cost. Since the `payment` module is automatically installed with the `account` module, most databases have the `payment` module installed with its cron, even if they didn't enable any provider. This commit disables the cron until a provider is enabled. task-4467217
The test email template now supports customizable message IDs, references, and subjects. This makes it easier for Odoo's teams to reuse the same test data for reply scenarios, improving test coverage without affecting end users.
Original PR description
We add the variable msg_id and references to the test mail template MAIL_EML_ATTACHMENT to allow to use it as a response to another mail. We also add "subject" to allow to use test-related subject. Task-3707821
Resolved issues and error corrections
This fix ensures that when German localization attachments are detached and renamed, their original file extension is preserved. This helps users keep files recognizable and openable after detaching them from records.
Original PR description
Fixes an issue with the renaming of the attachment after detaching to not change the extension. task-4500319
Miscellaneous changes
Deleting a knowledge_behavior element previously caused a traceback due to deleteRange() removing its nodes, leading to an error when attempting to destroy the oKnowledgeBehavior. This fix ensures proper handling of element deletion. Task-4210216 Forward-Port-Of: odoo/odoo#195451
Original PR description
Deleting a knowledge_behavior element previously caused a traceback due to deleteRange() removing its nodes, leading to an error when attempting to destroy the oKnowledgeBehavior. This fix ensures proper handling of element deletion. Task-4210216 Forward-Port-Of: odoo/odoo#195451
The mail failure icon has been replaced with a transparent version so it no longer shows an unwanted white box in dark mode. This improves visual consistency for users without changing how mail features work.
Original PR description
Previously, the Mail Failure icon was a .JPG, which lacked transparency. While this was not noticeable in Odoo Light Mode, it resulted in a visible white background in Dark Mode. This commit replaces the JPG with an SVG, ensuring proper transparency. | Current (17.0) | Fix | |--------|--------| |  |  | |  |  | task-4531425 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could occur when updating the departure reason for multiple employees at once. HR teams can now make these updates without the system failing during the employee record update.
Original PR description
Since the function message_post on mail thread has been built to be called on exactly one record and the function write on employee is for multiple records, we need to call it for each employee we are writing on. It has been introduced in: https://github.com/odoo/odoo/pull/143217 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Mexican electronic invoicing module now handles SAT status responses correctly when the returned status code is already plain text. This prevents an error during CFDI status checks and helps users get accurate invoice status information.
Original PR description
The following `response` was being returned when checking the CFDI status:
```
(Pdb++) response {'CodigoEstatus': 'N - 601: La expresión impresa
proporcionada no es válida.', 'EsCancelable': None, 'Estado': 'No
Encontrado', 'EstatusCancelacion': None, 'ValidacionEFOS': None}
```
Since `CodigoEstatus` is already a string, there is no need to parse it again. Removing the extra line prevents the error that occurred when trying to re-parse text from a string and ensures the SAT status is handled correctly.Uruguay electronic invoice PDFs now remove hidden or special characters from copied terms and addenda text. This prevents unexpected question marks from appearing on customer-facing invoice documents, improving document quality and professionalism.
Original PR description
This PR aims to fix an error on PDF reports on UY invoices, that occurs when copy-pasting the addenda text from an editor in Odoo. It happens that sometimes the text has hidden characters inside and those are printed as ? in the pdf. Steps to reproduce: 1) Install l10n_uy_edi 2) Create or duplicate an e-invoice 3) Copy-paste the following text in the "Terms and conditions" section: Estimated Net Weight: 84.000,00 Kg Estimated Gross Weight: 84.240,00 BL Nº: HLCUPN4240969947 BANK DETAILS: TEST12344 4) Confirm, print and send the invoice. 5) Check the pdf is created like this:  Expected behavior after this PR: The text on the "Adenda" section of the pdf should not print hidden characters.
Uruguayan electronic invoices now use the line label as the item name when no product is selected. This prevents invoices from being sent with a placeholder '-' in the official XML, reducing the risk of incorrect invoice details being submitted to DGI.
Original PR description
Description of the issue/feature this PR addresses: This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label. Current…
Description of the issue/feature this PR addresses:
This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label.
Current behavior before PR:
If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with "-".
Desired behavior after PR is merged:
If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with the product description.
Steps to reproduce the issue:
- Create an electronic invoice on an uruguayan company.
- Add a line without a product and add a label, a unit price, quantity and tax.
- Confirm the invoice and create CFE.
- Check that the field "NomItem" is field with a "-" instead of the product label like this:
```
<Item>
<NroLinDet>4</NroLinDet>
<IndFact>2</IndFact>
<NomItem>-</NomItem>
<DscItem>PRODUCT X</DscItem>
<Cantidad>1.000</Cantidad>
<UniMed>N/A</UniMed>
<PrecioUnitario>20.000000</PrecioUnitario>
<MontoItem>20.00</MontoItem>
</Item>
```This fix makes Belgian payroll calculations use the intended payroll date when looking up the public transport reimbursement limit. It prevents tests and date-sensitive payroll calculations from accidentally using the real current date, improving consistency and reliability.
Original PR description
Issue: in testing with freeze_time if the date is None in `_get_parameter_from_code` arguments it takes the real today's date - change the `date` argument while getting the `public_transport_max_amount` parameter because if it is None is gets the real date not the freeze one Task: 4509216
The salary configurator now avoids a crash when the Belgium-specific salary package is not installed. This helps HR users generate offers reliably even when optional localization features are absent.
Original PR description
Currently below error occurs when Salary Configurator (Belgium) not installed. Error: `KeyError: 'id_card_filename'` ### Steps to reproduce above error :- - Install 'Salary Configurator' - Employees >> Configuration >> Personal Info >> New - Create a new field, enter required fields, set 'Related Field' to 'ID Card Copy' and 'Display Type' to 'Document' and hit 'Save' - Now go to Employees >> Contracts, click any employee >> Generate Offer >> Salary Configurator - The error appears in the log. The error arises because field `id_card_filename` is present in 'Salary Configurator (Belgium)' module, which was not installed. This commit solves the above issue by checking if field `id_card_filename` is present. sentry-6164311636
Steps to reproduce: - Enter edit mode. - Drag and drop a carousel into the page. - Use the arrow keys to slide the carousel. - Bug: a traceback occurs. Just like we disabled Bootstrap for sliding the carousel in edit mode and instead handle it manually (see this commit [1]), in this commit, we also disable sliding the carousel by pressing the left and right arrow keys on the keyboard. [1]: https://github.com/odoo/odoo/commit/93ec3ac285dc9ffd363e185a1dc238c6135d79dd opw-4373535 Fo
Original PR description
Steps to reproduce: - Enter edit mode. - Drag and drop a carousel into the page. - Use the arrow keys to slide the carousel. - Bug: a traceback occurs. Just like we disabled Bootstrap for sliding the carousel in edit mode and instead handle it manually (see this commit [1]), in this commit, we also disable sliding the carousel by pressing the left and right arrow keys on the keyboard. [1]: https://github.com/odoo/odoo/commit/93ec3ac285dc9ffd363e185a1dc238c6135d79dd opw-4373535 Forward-Port-Of: odoo/odoo#196433
**Current behaviour before PR:** When single cell is selected in a table, trying to apply color closes color palette and color is not getting applied on it. This happens because applying color on single cell changes selection and cell gets deselected in `_onSelectionChange`. **Desired behaviour after PR:** Now, it is possible to apply color on a single cell. task-3433784 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Por
Original PR description
**Current behaviour before PR:** When single cell is selected in a table, trying to apply color closes color palette and color is not getting applied on it. This happens because applying color on single cell changes selection and cell gets deselected in `_onSelectionChange`. **Desired behaviour after PR:** Now, it is possible to apply color on a single cell. task-3433784 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173845
Steps to reproduce the bug: - Create two delivery transfers. - Add them to a single batch transfer. - Assign a responsible person to the batch transfer. - The assigned responsible person will automatically be updated in all related transfers. - Now, remove the responsible person from the batch transfer. Problem: When a responsible person is assigned or modified in a batch transfer, the update is correctly reflected in all related transfers within that batch. However, if the responsible
Original PR description
Steps to reproduce the bug: - Create two delivery transfers. - Add them to a single batch transfer. - Assign a responsible person to the batch transfer. - The assigned responsible person will automatically be updated in all related transfers. - Now, remove the responsible person from the batch transfer. Problem: When a responsible person is assigned or modified in a batch transfer, the update is correctly reflected in all related transfers within that batch. However, if the responsible person is removed from the batch transfer, this change is not applied to the individual transfers linked to it. opw-4519994 Forward-Port-Of: odoo/odoo#196333
**Problem**: Removing spaces impacts composed values like (`padding: 10px 20px` → `padding: 10px20px`), making them invalid. **Solution**: Replace multiple spaces with a single space instead of removing them, to ensure composed values remain intact. **Steps to Reproduce**: 1. Open Email Templates > any template. 2. Add `padding: 10px 20px` to a `tr` element. 3. Save the template. 4. Observe that padding is not applied. --- I confirm I have signed the CLA and read the PR guidelin
Original PR description
**Problem**: Removing spaces impacts composed values like (`padding: 10px 20px` → `padding: 10px20px`), making them invalid. **Solution**: Replace multiple spaces with a single space instead of removing them, to ensure composed values remain intact. **Steps to Reproduce**: 1. Open Email Templates > any template. 2. Add `padding: 10px 20px` to a `tr` element. 3. Save the template. 4. Observe that padding is not applied. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196376
Previously, adjusting the width of a form field within a large box resulted in excessive padding being applied above and below the form field. This commit refines the CSS rules, ensuring the padding is applied only to the outer large box and not to the inner elements. task-4370763 Forward-Port-Of: odoo/odoo#193008
Original PR description
Previously, adjusting the width of a form field within a large box resulted in excessive padding being applied above and below the form field. This commit refines the CSS rules, ensuring the padding is applied only to the outer large box and not to the inner elements. task-4370763 Forward-Port-Of: odoo/odoo#193008
**Steps to reproduce**: - Activate recurring revenues and open the form in mobile - The expected revenue, duration and probability is not properly displayed, it's gets out of the container. **After this PR:** - they will displayed currently, plus we'll not show `at` in mobile view. Task-4438997 Forward-Port-Of: odoo/odoo#193060
Original PR description
**Steps to reproduce**: - Activate recurring revenues and open the form in mobile - The expected revenue, duration and probability is not properly displayed, it's gets out of the container. **After this PR:** - they will displayed currently, plus we'll not show `at` in mobile view. Task-4438997 Forward-Port-Of: odoo/odoo#193060
Related to https://github.com/odoo/enterprise/pull/78533 Forward-Port-Of: odoo/odoo#196447
Original PR description
Related to https://github.com/odoo/enterprise/pull/78533 Forward-Port-Of: odoo/odoo#196447
The '/A/ ' prefix in the SEPA files should only be present for belgian salaries payments, or it is always present. This adds another condition, using a payroll context key added in another fix to narrow the cases where the /A/ should be added opw-4459040 Forward-Port-Of: odoo/enterprise#78502
Original PR description
The '/A/ ' prefix in the SEPA files should only be present for belgian salaries payments, or it is always present. This adds another condition, using a payroll context key added in another fix to narrow the cases where the /A/ should be added opw-4459040 Forward-Port-Of: odoo/enterprise#78502
In the tree view of the payslip model, we can do mass edit to create a journal entry. Before, we were able to perform this action on a paid payslip which does not make sense. Now we have an error message if we try to do it. Task: 3874129 Forward-Port-Of: odoo/enterprise#75035
Original PR description
In the tree view of the payslip model, we can do mass edit to create a journal entry. Before, we were able to perform this action on a paid payslip which does not make sense. Now we have an error message if we try to do it. Task: 3874129 Forward-Port-Of: odoo/enterprise#75035
## Description Following odoo/enterprise@c9ceba2cf5982c244fe1ad3054d1463d9eca0e8c, the set of suitable_partners used to determine which products can be associated with a ticket is based on the `commercial_partner_id` of `self`. This works well for form views, where `self` is a singleton. However, since the field `product_id` is present in the list view, which has a domain depending on `suitable_product_ids`, the computation is triggered for all tickets in the list view, making `self` not a sing
Original PR description
## Description Following odoo/enterprise@c9ceba2cf5982c244fe1ad3054d1463d9eca0e8c, the set of suitable_partners used to determine which products can be associated with a ticket is based on the…
## Description Following odoo/enterprise@c9ceba2cf5982c244fe1ad3054d1463d9eca0e8c, the set of suitable_partners used to determine which products can be associated with a ticket is based on the `commercial_partner_id` of `self`. This works well for form views, where `self` is a singleton. However, since the field `product_id` is present in the list view, which has a domain depending on `suitable_product_ids`, the computation is triggered for all tickets in the list view, making `self` not a singleton. This causes the set of suitable partners to be larger than necessary, as it becomes the collective set for *all* tickets referenced in `self`, leading to false positives where products associated with a specific partner's sales/delivery history might appear suitable for another ticket with a different partner. To address this, we split `self` by `commercial_partner`, as the set of products that could be suitable depends on the partner's sales/delivery history, not on individual tickets. ## Reference opw-4444078 Forward-Port-Of: odoo/enterprise#78087
Related to https://github.com/odoo/odoo/pull/196447 Forward-Port-Of: odoo/enterprise#78533
Original PR description
Related to https://github.com/odoo/odoo/pull/196447 Forward-Port-Of: odoo/enterprise#78533