Monday, December 30, 2024
7 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
3 changes
Enhancements to existing features
VoIP users now see an “In call” status when the widget is closed during an active call, so they know the call is still ongoing. If an incoming call is dismissed by closing the widget, the ringing stops while the VoIP icon gives a subtle vibration to keep the user aware of the call.
Original PR description
1. When you close the VoIP widget while you are in a call, it won't hang up but there is nothing to show that you are still in a call. So, this commit solves this by adding an "In call" status next to the voip icon when you are in a call. 2. When someone is calling you and you are busy, you close the widget, the call will stop ringing and a small vibration is added to the voip icon to show that there's an incoming call. Task-4398564 Subtask-4416855
2 changes
Resolved issues and error corrections
This 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
The shop floor now uses one consistent manual consumption flow when operators register consumed components. This reduces confusion between separate consumption methods, improves the consumed component wizard, and adds barcode scanning support for faster shop floor entry.
Original PR description
In this commit: ===================== - Currently, there are two ways of registering component consumption in the shop floor interface: component moves (manual consumption) and component consumption steps. - Now we use the move mechanism (manual consumption) for the register component consumption type step. task-3976734
IoT Boxes now avoid re-downloading device handlers when they already have the latest version. They also receive only the handlers relevant to their platform, reducing unnecessary data transfer and startup work.
Original PR description
We currently download handlers from db on every restart of odoo service, even if they are up to date. We now compute the sha256 hash of the handlers, compare it with the one the IoT Box saved the first time it downloaded it and return a 304 (Not Modified) if they are already the latest version. We now also avoid sending handlers not corresponding to the platform (we don't send Windows drivers to physical IoT Box or Linux drivers to Windows IoT Box anymore). Community PR: [https://github.com/odoo/odoo/pull/190245](https://github.com/odoo/odoo/pull/190245) Task: 4107538
**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