Daily updates from Odoo
Monday, December 30, 2024
11 changes
2 changes
Resolved issues and error corrections
This fix ensures customers requesting Mexican POS invoices must provide their RFC/VAT and zip code, preventing invoices from being incorrectly issued to the generic public customer. It also corrects portal billing field handling so the required information is validated consistently.
Original PR description
Manual forward port of https://github.com/odoo/odoo/pull/187674 In the l10n_mx localization, the field RFC(VAT) and zipcode should be required to prevent the field from being defaulted to "public en…
Manual forward port of https://github.com/odoo/odoo/pull/187674 In the l10n_mx localization, the field RFC(VAT) and zipcode should be required to prevent the field from being defaulted to "public en general". How to reproduce: -Install l10n_mx and pos -Activate the option "Generate a code on ticket" -Go to POS and sell an article to generate the ticket -Go to the POS portal to request an invoice (/pos/ticket/) -Fill all the fields except for RFC -Odoo does not request this field and allows the client to submit the information -The invoice will be generated to "public en general" and not to the client requesting the invoice (Expected when there is no RFC) In addons/portal/views/portal_templates.xml, zip was used which was not part of OPTIONAL_BILLING_FIELDS in addons/portal/controllers/portal.py. This forces us to manually inject data['zipcode'] to data['zip'] in `details_form_validate` opw-4332357 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Refreshing the Inventory Replenishment page now restores the correct menu context. This prevents the top navigation from disappearing, helping users continue their work without confusion or extra navigation steps.
Original PR description
**Problem**: In saas-17.2, the new URL structure no longer includes `menu_id`, which was previously used to set the current menu upon page refresh: https://github.com/odoo/odoo/blob/1443e5503c7396512a078f9f52fd4cb31b62e202/addons/web/static/src/webclient/webclient.js#L76 This change causes issues for actions like `action_orderpoint_replenish`, which are not directly tied to any `ir.ui.menu` and lack a `menu_id` in the URL: https://github.com/odoo/odoo/blob/535a02565f9e9142f0ef1fe9f44d1935f7b42075/addons/web/static/src/webclient/webclient.js#L59-L65 As a result, the menuId becomes `undefined`, leading to the top menu not being loaded properly. **Solution**: Add a path to action to ensure that it is properly reloaded. **Steps to reproduce**: 1. Navigate to *Inventory > Replenishment*. 2. Refresh the page. 3. Observe that the top menu disappears. opw-4350871
1 change
Resolved issues and error corrections
The point of sale receipt screen now prevents sending the same receipt multiple times to the same WhatsApp number. This reduces accidental duplicate messages to customers and helps keep receipt communication cleaner.
Original PR description
Previously, it was possible to send a receipt to the same whatsapp number multiple times from the receipt screen. This update addresses that issue by restricting users to send the receipt to each whatsapp number only once. related: https://github.com/odoo/odoo/pull/180602
4 changes
Resolved issues and error corrections
This fix ensures copied databases using Indian localization settings are neutralized so they do not contact live government or production services. It helps support teams investigate issues safely without risking real-world effects on customers or production records.
Original PR description
Since [1], the filed `l10n_in_edi_production_env` has been moved from module `l10n_in_edi` to `l10n_in`. `l10n_in_gstin_status` needs to be neutralized to not hit the production servers, but it does…
Since [1], the filed `l10n_in_edi_production_env` has been moved from module `l10n_in_edi` to `l10n_in`. `l10n_in_gstin_status` needs to be neutralized to not hit the production servers, but it does not depend on the `l1on_in_edi` module which holds the neutralization script. Even if the `l10n_in_gstin_status` does not end up performing operation that require a strict neutralization, future modules that also depend solely on `l10n_in` might not be so lucky, rendering this change absolutely necessary. The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] https://github.com/odoo/odoo/pull/175290
The HTML editor color picker now correctly shows which text or background color is already applied when users open it. This makes formatting clearer and avoids duplicate or missing custom color entries, reducing confusion while editing content.
Original PR description
**Current behavior before PR:** When there is a text having a text-color or background color, opening color selector doesn't highlight the button matching with that selected color in solid color tab. **Desired behavior before PR is merged:** Opening color selector highlights the button matching with that selected color in solid color tab. task-4341528 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix updates an automated test for the self-ordering point-of-sale feature so it selects the intended product directly. This makes test results more reliable and avoids failures caused by products appearing in a different order.
Original PR description
**Problem**: The product created during the tour test was not explicitly selected. It was selected implicitly because it appeared first in the product list. **Solution**: Explicitly select the product created during the test in the tour to ensure proper functionality and remove dependency on list order. runbot-110904 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Reloading the Colombian DIAN configuration no longer crashes when a required certificate is missing. Instead, users receive a clear validation message so they can add or restore the certificate and continue configuration.
Original PR description
Currently, An error occurs when reloading the DIAN configuration in an account journal to obtain the security token of a certificate, if no certificate is available. Step to produce: - Install the `l10n_co_dian` module. - Navigate to Settings and click on Certificates under the Certificates and Keys section. - And delete a 'Demo DIAN Certificate'. - Open any Journals and click on a 'Reload DIAN configuration'. `IndexError: tuple index out of range` The error occurs because the system attempts to access the certificate's token from a company at [1], but it is not available. Link [1]: https://github.com/odoo/enterprise/blob/a354a19060338084df35a14ed7f21defc3c05c11/l10n_co_dian/xml_utils.py#L123 To resolve this issue, Raise a validation error if a certificate is not found when the system attempts to retrieve its security token. Sentry-6165073693
4 changes
Resolved issues and error corrections
A technical issue preventing users from printing session reports has been resolved. The problem stemmed from outdated, unused code related to pro forma orders. This update removes the problematic code, ensuring the session report printing function works correctly.
Original PR description
Issue: ==================== - A traceback occurred when attempting to print the session report from the reporting menu. - The issue was caused by unused code related to pro forma orders left over from the refactoring in version 17.0. Fix: ==================== - Removed the unused code related to pro forma orders. - Ensured the session report can be printed without errors. Task-4438550
This update resolves a display issue where the Timesheets grid would show a 'No Timesheets Found' banner and disable navigation when viewing older timesheets. The fix ensures users can seamlessly browse and navigate through their timesheet data, regardless of age.
Original PR description
Issue:
- When an employee has timesheets older than 2 weeks, opening timesheets for a new week displays a "No Timesheets Found" banner, and the ability to navigate the grid to the previous week or display a month is disabled.
Steps To Reproduce:
1. Go to the Timesheets app.
2. Ensure there are only timesheets older than 2 weeks.
3. Exit the Timesheets app and reopen it.
5. Notice the "No Timesheets Found" banner is displayed.
6. Observe that the ability to navigate to previous weeks or display a month is disabled.
Solution:
- this issue was fixed here: https://github.com/odoo/enterprise/pull/64792/commits/1f2ef9fd9200045b556a6dbcefd2dd3f57098cc8 this is a simple backport of the fix to the 17.0 branch.
opw-4238024This update resolves an issue preventing users from exporting tax reports as PDFs. The previous fix introduced a widespread update requirement, now it's reverted to its original state, ensuring PDF export functionality is restored for all users. This allows for easier report generation and distribution.
Original PR description
**Issue:** Tax reports can't be exported as PDFs.  **Expected:** Users…
**Issue:** Tax reports can't be exported as PDFs.  **Expected:** Users should be able to generate tax reports PDFs. **Steps to reproduce:** - Activate Accounting app; - Install the Argentina localization; - Move to the Argentine company; - Go to `Accounting` > `Reporting` > `Tax Report`; - Change selection to display some lines (or add invoice lines); - Print PDF report. **Cause:** A fix (https://github.com/odoo/enterprise/commit/4c45cd704a7ddd46c93a1d8b8f5f3cf6934215a4#diff-8eb5e11a8f74f533b8999b3a5382c0d750bc87d2acc16ff5b4225775ba3ddd86L50) badly backports a correction for Argentine reports. This implies all Odoo users need to update their `account_reports` module to update the report view. **Fix:** Revert backport and keep useless currencies' display removal in subheaders only.  opw-4431015 opw-4430982 opw-4427336 opw-4430855 opw-4430735
This update resolves an issue where document filters wouldn't apply after archiving a document. The fix ensures that the correct filter criteria are used when loading documents, guaranteeing that users only see documents matching their selected activity filters. This improves the reliability and accuracy of the Documents app.
Original PR description
To reproduce ============ - Go to Documents app - schedule some activities on different documents for Mitchel Admin and Marc Demo - Go to the activity view, and set filter to Activities assigned to Mitchel Admin - only documents with activities assigned to Mitchel Admin should be shown - select one of them and move it to the trash -> the filter won't be applied anymore, and all documents with activities will be shown Problem ======= after archiving a document, the `load` method is called without `searchParams` where `domain` should be defined, so a default domain is used. Solution ======== set the `searchParams` in the `load` method with domain of the current filter opw-4354175