Monday, July 15, 2024
10 changes
4 changes
Resolved issues and error corrections
The generate serials/lots dialog in Manufacturing now receives the correct quantity value when used from the shop floor. This prevents users from seeing an undefined Quantity Received value and avoids errors when creating lot numbers for tracked components.
Original PR description
Issue: ============================ There is an 'undefined' value for the 'Quantity Received' field in the generate lot number dialog. When attempting to generate a lot number for a component from…
Issue: ============================ There is an 'undefined' value for the 'Quantity Received' field in the generate lot number dialog. When attempting to generate a lot number for a component from the shop floor, the 'Quantity Received' field displays as 'undefined', leading to an error. Steps to Reproduce: ============================ 1. Install the 'mrp_workorder' module. 2. Create a Bill of Materials (BoM) in the Manufacturing module with manual consumption components tracked by lot. 3. Create a Manufacturing Order (MO) for the product. 4. Open the 'detailed operation' wizard for a component with lot tracking in the shop floor module. 5. Click on 'Generate Serials/Lots'. 6. Verify that the Quantity Received field displays the 'undefined' value. Resolution: ============================ Currently, the "quantity received" field displays 'undefined', causing an error when generating a lot number for a component. This issue occurred due to not getting a quantity field in the shop floor module. Added the "quantity" field to the relevant view to ensure that the "quantity received" field gets an actual quantity field value, preventing the error. Expected Result: ============================= This fix resolves the error and allows for efficient lot number generation of products in the shop floor module.
Fixes a visual glitch in the test status spinner when HOOT tests run on small or mobile screens. This makes the testing interface more stable and readable for teams checking software quality on different device sizes.
Original PR description
This commit fixes a glitch in the animated spinner when running HOOT tests on small/mobile screen. Note: adding flex grow/shrink variants for consistency's sake. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a recruitment applicant is created with both a name and an email address, the related contact will now be named after the applicant instead of the email address. This keeps contact records clearer and avoids confusing duplicate-looking entries based on email addresses.
Original PR description
STEP TO REPRODUCE:
==================
1- Go on recruitment application
2- Click on applications/All applications
3- Click on new
4- Write this in the form view :
A- "manager" in subject/application
B- "Milly" in Applicant's name
C- "thefunnyguys@example.com" in Email
5- Save it
6- Go in contact application
7- search thefunnyguys
Current Behaviour:
===================
You will find a partner with this name and this email.
Expected Behaviour:
===================
The name of this partner should be "Milly" not the email adress.
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes the GCC Arabic-English invoice report so it uses the correct current report language setting. It prevents issues caused by an outdated internal reference, helping invoices render reliably with right-to-left text ordering.
Original PR description
Problem: The `l10n_gcc_invoice.arabic_english_invoice` report was recently updated to fix (https://github.com/odoo/odoo/pull/169267) an issue related to RTL ordering. However, this fix uses the `_lang_get_direction` method. While fine on theoriginally targeted version, in 17.2 this method was reworked into a new api `_get_data`. FW ports for 17.2+ had this older method still. Purpose: Swap `_lang_get_direction` with new `_get_data` method in report opw-4045879
6 changes
Resolved issues and error corrections
This fix corrects a display issue where the Sign Report button was not appearing when using Worksheets without Field Service enabled. The condition that controlled the button's visibility was incorrectly requiring Field Service to be active, even though Worksheets can function independently. This change allows users to properly sign worksheet reports regardless of Field Service status.
Original PR description
Steps to reproduce: - Install "Field Service" - Open "Project" - Open the settings of a random project - Then click on the "Settings" tab - Disable "Field Service" and enable "Worksheets" - Create a new task with a worksheet - Click on start then stop and save - Click on "Sign Report" Issues: The sign button is not displayed due to the condition in the template which required previously to have `is_fsm` enabled. https://github.com/odoo/enterprise/blob/4d0a467220fba5253fb4a6f38844861d9ed4e442/industry_fsm/views/project_portal_templates.xml?plain=1#L42 opw-4032692 Forward-Port-Of: odoo/enterprise#66057
This fix improves the Field Service navigation feature by using actual addresses instead of GPS coordinates when generating navigation links. Previously, Google Maps would convert coordinates back to addresses, which could result in discrepancies. Now users will navigate to the correct address consistently.
Original PR description
Steps to reproduce: - Install "Field Service" - Open a random task - Click on "Navigate To" Issues: The link is constructed using the coordinates, however Google will convert those coordinates back to an address which will cause a potential discrepancy between the two. opw-4004846 Forward-Port-Of: odoo/enterprise#66611 Forward-Port-Of: odoo/enterprise#65893
This fix prevents demo content from the report editor from appearing in actual printed reports. Previously, when employees had empty fields (like missing resume descriptions), placeholder text from the editor would show up in printed documents instead of remaining blank. The solution introduces a new demo-only attribute so placeholder content only displays in the editor, not in real reports.
Original PR description
Steps to reproduce ================== - Install hr_skills,web_studio - Go to Employees - Open any record - Add a new resume entry without description - Save - Click on the actions gear - Print >…
Steps to reproduce ================== - Install hr_skills,web_studio - Go to Employees - Open any record - Add a new resume entry without description - Save - Click on the actions gear - Print > Print Resume => `Odoo India pvt. Ltd` is displayed in the report in place of the missing description Cause of the issue ================== With the new report editor in 16.4, some demo data have been added directly inside the report templates as default content. The assumption was that it would be displayed inside the report editor, but outside, since the field would have a value, the value would take over. The default content if displayed when the field value is falsy. In this case, the default content is used instead of the empty description. Solution ======== Introduce a new attribute, data-oe-demo, to be used inside the report editor. This doesn't have the drawbacks of the default content as we can choose to only display it inside the report editor --- [commit]: https://github.com/odoo/odoo/commit/a45c6c545ffdcee3bb50b3455884b8296e5d6a7c opw-4033434
This fix ensures that rental transfer pickings are properly created when portal or public users confirm rental orders, regardless of their user permissions. Previously, the system was checking the current user's settings instead of the database owner's settings, causing transfers to be skipped when external users placed orders. Now the system correctly uses the order creator's settings to determine whether transfers should be generated.
Original PR description
**Current behavior:** If a portal or public user causes a rental order to get confirmed, rental transfer pickings won't get created if the DB user has the setting enabled. **Expected behavior:** The transfer should be created with respect to the user of the database, not the external users. **Steps to reproduce:** 1. Enable rental transfers 2. Create a rental order to a portal user 3. In a fresh browser, open the preview link as the portal user 4. Sign & Pay for the order 5. See that no transfers got created **Cause of the issue:** We use the `env.user` to determine whether the transfers should be generated. **Fix:** Use the creator of the order to decide to create the transfer. opw-3933511
This update resolves multiple issues in the manufacturing shop floor system that were preventing proper data entry and barcode scanning. Key fixes include saving quantity and lot information during quality checks, improving the clarity of the quality check interface, correcting barcode trigger recognition, and updating the barcode PDF generation to resolve scanning problems. These changes ensure that shop floor operations run more smoothly and reliably.
Original PR description
This addresses several issues: - on 'register_consumed_materials' & 'register_byproducts' quality checks, the quantity entered and the selected lot were not saved - make this view clearer by separating the product and the other fields - 'print' & 'next' barcode triggers were sometimes capitalized, making them inoperant - fix component remaining quantity when no producing quantity has been set - generate a new pdf for barcodes: add print barcode & new ghostscript version seems to solve some erratic scanning problems task: 3987346
This update fixes visual alignment issues in the sign module where text and icons were inconsistently positioned in both the customer portal and backend interfaces. The fix ensures a polished, professional appearance with consistent alignment across all sign-related screens, improving the overall user experience.
Original PR description
Before this PR: In the sign module, there are inconsistencies with the alignment of texts and icons, in both the portal and backend interfaces. After this PR: This fix addresses alignment issues and ensures consistency between the portal and backend interfaces. Now, texts and icons in the sign appear aligned and consistent across both interfaces.