Thursday, October 10, 2024
14 changes · 17.0
Resolved issues and error corrections
This fix resolves an issue where email messages sent through aliases were not showing proper sender details in the document chatter. Previously, only "Odoobot" appeared as the sender. Now users can see the actual sender's email address, name, subject line, and email body along with any attachments, making it easier to track communication history.
Original PR description
Before this commit: The information of message sender using email alias was not shown, instead only mail subject with name Odoobot was displayed in chatter. After this commit: The information of sender such as email address, name, subject of email and email body is not displayed in chatter along with the attachment. Task - 4008634
This fix resolves an error that occurred when users tried to add products to tasks in field service projects without an existing sales order. The system now properly requires and automatically assigns the company information when the "Products on Task" feature is enabled, allowing products to be added to tasks without errors.
Original PR description
Problem: When the user enables allow_material on a project, they encounter a ValidationError when adding products on a task that has no sale order. Odoo tries to create a sale order for the task, but there is no company_id passed into the values. Solution: The company_id should be required when allow_material is enabled and the company should be computed once enabled. Steps to Reproduce on Runbot: 1. Install Sales, Field Service, Projects 2. Create a project and enable "Products on Task" 3. Create a task and assign a customer that has no sales order 4. Add products on the task and the ValidationError occurs opw-4000580
This fix corrects a bug where too many quality checks were being created when products matched multiple quality points with different category filters. The system now properly validates product categories when determining which quality checks to create, ensuring the correct number of checks are generated during receipt confirmation.
Original PR description
Steps to reproduce the bug:
- Create two Storable product:
- “P1” -> product category A
- “P2” -> product category B
- Create a quality point:
- picking type: receipt
- product category: Cat A & Cat B
- Measure: by quantity
- Create a second quality point:
- picking type: receipt
- product category: Cat A
- Measure: by quantity
- Create a receipt of one unit of P1 and P2
- Confirm
Problem:
Four quality checks are created instead of three because we check if the quality point corresponds to the picking type and if the quality point has no product selected. However, we don't verify if a product category is also not set.
opw-4240859This fix corrects how overseas transactions are reported in GST spreadsheets. Previously, overseas sales with GST taxes (CGST/SGST) were incorrectly appearing in the export spreadsheet even though they shouldn't be included. The fix removes these tax components from overseas transactions to ensure accurate GST reporting that matches official GSTR-1 filings.
Original PR description
Before this PR, overseas transactions with GST were shown in the spreadsheet, but not in GSTR-1. After this PR, overseas transactions with GST will no longer be shown in the spreadsheet. **Technical Reason:-** In the `_get_exp_json` method, we retrieve journal items that meet the exp domain criteria. However, the `tax_details` are linked from `move_id` using `tax_details_by_move`, which applies the hsn domain. Consequently, all journal items are retrieved, necessitating the exclusion of those involving CGST and SGST, as these are not relevant for overseas transactions. **Task**-4008149 Forward-Port-Of: odoo/enterprise#65280
This fix resolves an error that occurred when creating invoices in branch companies in Chile. The system was looking for tax groups only in the branch company, but they are actually defined in the parent company. The fix now properly checks parent companies for tax group information, allowing invoices to be created successfully in branch companies.
Original PR description
**Steps to reproduce:**
- Install Accounting and l10n_cl_edi_boletas
- Switch to a Chilean company (e.g. CL Company)
- Create a branch company for it
- Create a product with a tax from "ILA" group
- Switch to the branch company
- Create an invoice with the created product
- Confirm it
**Issue:**
A traceback is raised while trying to fetch some tax groups:
- self.env.ref(f'account.{cid}_tax_group_ila')
- self.env.ref(f'account.{cid}_tax_group_retenciones') where {cid} is the id of the branch company.
**Cause:**
There is no tax group defined in the branch company. The taxes and the tax groups are defined in the parent company.
**Solution:**
Do not raise an error if the XMLID cannot be found and also check tax groups from parent companies as the taxes could come from them.
Use the "ref" method defined in "account.chart.template" model that is doing it.
opw-4227241
Related comminity PR: https://github.com/odoo/odoo/pull/182798This fix addresses two issues in the manufacturing shopfloor module: the count of manufacturing orders no longer updates correctly when orders are closed, and work order timers continue running after being marked as done, resulting in inaccurate time recordings. The update ensures the MO count refreshes properly and timers stop immediately when work orders are completed.
Original PR description
There's no refresh when closing a MO on the 'All MO' tab of the shopfloor. Because of that, the MO fades away but the total count is still the same. This PR forces a refresh to make sure that the count is corresponding to the number of MOs shown. When marking a workorder as done with the timer running, the timer doesn't stop and the value registered contains the time it takes to fade away. E.g. if you mark a WO as done at 1 min 33 sec, the real duration registered will be around 1 min 36-37 sec. This fix ensures the timer stop effectively and visually when closing a WO.
This fix resolves an issue where Australian ABA payment files were rejected by validators when vendor names contained special characters like curly apostrophes. The problem occurred because special characters take up more space when converted to UTF-8 encoding, causing the file format to exceed the required row length. The fix now properly calculates character length in UTF-8 before formatting the file, ensuring all generated ABA files pass validation.
Original PR description
**Steps to reproduce:** - Install l10n_au_aba - Switch to an Australian company (e.g. AU Company) - Configure batch payments according to this…
**Steps to reproduce:** - Install l10n_au_aba - Switch to an Australian company (e.g. AU Company) - Configure batch payments according to this [documentation](https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/australia.html#aba-files-for-batch-payments) - Create a vendor with a special character in the name (e.g. a curly apostrophe `’`) - Configure a bank account for the vendor - Create a bill for that vendor - Confirm the bill - Register a payment with "ABA Credit Transfer" as payment method - Go to the payments list - Select the created payment and create a batch payment - Validate it - Download the generated ABA file - Try to validate the file on an online [ABA validator](https://www.bcu.com.au/business-banking/payments/internet-banking/aba-file-validator/) **Issue:** The online ABA file validator finds an error because the accepted length for a row is not respected. **Cause:** Each row information is encoded with a specific number of characters where blank characters are added to reach that length. In this case, the name of the account holder is containing a special character that corresponds to 3 characters when converted to utf8 and too many blank characters are added. **Solution:** Compute the length in utf8 before adding the blank characters. opw-4059837 Forward-Port-Of: odoo/enterprise#71351
This update fixes a visual problem with popovers when using Dark Mode in Odoo. The popover background color was incorrectly set to a very light shade, which made it difficult to see and broke its proper layering. The fix restores the correct background color so popovers display properly and maintain their visual hierarchy in the Dark Mode interface.
Original PR description
The popover was set to bg-100 during darkmode redesign but it creates more issue than having it at 300. The initial issue was the button light behavior inside popover, but setting it to 100 doesn't solve the button light and breaks the elevation. Steps to reproduce (any popover): - Apply the Dark Mode - Go in CRM app - Open a lead - Clic the cog in the control panel next to the breadcrumb - Select "Add Properties" (it opens the popover) task-3593302
This update resolves an issue where automated tests in the restaurant point-of-sale module were running three times unnecessarily, wasting testing time and resources. The fix reorganizes the test code structure to eliminate this duplication while maintaining the same test coverage.
Original PR description
Currently since TestFrontend has test methods and is imported/inherited, the same test is executed three times. Fixing it by extracting setup to an utility class
This fix corrects the GSTR-3B tax report for Indian businesses to properly handle Point of Sale (POS) transactions. Previously, POS entries were incorrectly included in sections 3.1 and 4 of the report. Now, only miscellaneous entries from POS are counted in section 3.1, and POS entries are excluded from section 4, ensuring accurate tax reporting.
Original PR description
This commit https://github.com/odoo/enterprise/pull/67520/commits/ed431cd78dea4ad40e0e6a82eb3ffd9f44026d71 adds `move_type = entry` on the `3.1 a,b,c,e` report lines, but only `misc` entries coming from the POS should impact the line. PoS entries are also considered in section 4, but they shouldn't. To determine which moves are from the PoS we use the l10n_in_pos_session_ids field from module l10n_in_reports_gstr_pos, so we had to inherit the report in that module to add the condition. [Task link](https://www.odoo.com/odoo/project/69/tasks/4224066) task-4224066 Forward-Port-Of: odoo/enterprise#71315
This fix ensures that the snailmail cost field is properly calculated when creating follow-up reminders for customers with multiple contacts. Previously, the system was incorrectly showing only 1 stamp regardless of how many follow-up contacts a partner had, which could lead to inaccurate postage cost tracking in your accounting follow-up process.
Original PR description
Problem: The snailmail_cost field was not being computed because the compute method was not being called. Note: this will only work for newly created `account_followup.manual_reminder`. Steps to reproduce: - Enable "SnailMail" in Settings. - Navigate to Accounting > Follow-up Reports. - Open a report. - Follow up on the report. - Observe that the stamps count is 1, even if the partner has multiple follow-up contacts. opw-4160083 Forward-Port-Of: odoo/enterprise#71530
This fix allows users to filter spreadsheet views using the ID field when setting up global filters. Previously, when creating a filter based on a related record (like filtering a project list by project ID), the ID field was not available as a filtering option. Now users can select the ID field to properly filter their spreadsheet data.
Original PR description
Steps to reproduce: - Insert a pivot view of timesheet - Insert a list view of project - Add a new global filter based on project => you actually cannot select id for the list view of project, but we should be able to filter the list view based on the project id. This commit adds the id field to the allowed fields for the relation global filters. Task: 4228916
This fix corrects how shipping prices are handled in the Sendcloud delivery service when no price information is available. Previously, missing prices were incorrectly stored as numbers instead of text, which caused sorting and display issues. The update ensures prices are stored in the correct format for proper system functionality.
Original PR description
Before this commit: In a recent commit to allow sendcloud to generate labels without having to fetch rates. When the returned value for field `price` is `None` it was set as `0.0` with datatype `float` when it should be `str`. After this commit: Added a check when setting price to make sure correct datatype is set. opw-4222636
This fix corrects an error in the Holiday Attestation (N-1) document used in Belgian payroll processing. The end date was incorrectly calculated and has been fixed to properly align with the notice period end date. This ensures employees receive accurate holiday attestation documents when their employment ends.
Original PR description
The end date on the Holiday Attest (N-1) was wrong. It should be the same as the end of the notice period.