Thursday, October 10, 2024
22 changes
1 change
Enhancements to existing features
Project managers can now see the critical path directly in the Gantt view, highlighting the sequence of dependent tasks that must stay on schedule. This helps teams focus attention on the work that most affects the overall project deadline.
Original PR description
Purpose ======= The critical path shows those tasks that must be completed on time. It is the longest chain of tasks between the start and end dates of your project that cannot be compromised. It helps to know what sequence of tasks requires special attention, and how much it takes to complete your project on time. Implementation ============== The critical path is the longest path of dependent tasks of a given project. This commit introduces: - Backend methods to get the critical path of a group of tasks (based on a domain) - Frontend methods to display the critical path of a project in the Gantt view - Testing for those methods task-3391988
8 changes
Resolved issues and error corrections
Point of Sale users can once again find products by searching for their internal reference code. This restores expected search behavior from the previous version and helps cashiers locate items faster at checkout.
Original PR description
Problem: In the PoS interface, searching for products using the `default_code` (internal reference) does not return any results, while this functionality was available in version 17.0. Steps to reproduce: - Open PoS. - Attempt to search for any product using its `default_code` (internal reference). - No results are displayed. opw-4232415 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
13 changes
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
Creating an employee from a candidate with recorded skills no longer triggers an error. This prevents duplicate skill records during employee creation, helping recruiters complete the hiring workflow without interruption.
Original PR description
Steps --- * Create a candidate * Give them a skill * *Create Employee* * => Traceback -> "Two levels for the same skill is not allowed" Cause --- * on `hr.employee.skill` we have a unique constraint on the skill employee pair * but when creating an employee we would attempt to create the skills twice, once through regular create and once from the override of `_update_employee_from_candidate` call in the write
Installing a chart of accounts could fail for companies that already had Point of Sale payment methods. The fix ensures related POS payment records are handled correctly, allowing accounting setup to complete without blocking the user.
Original PR description
When trying to install a CoA on a company that already have pos payment methods the installing would fail because it's trying to delete a journal linked to the payment methods
Steps to reproduce:
-------------------
* Create a new company, do not install CoA
* Create a PoS payment method
* Install any CoA
> Observation: You get an error saying you cannot delete some records
Why the fix:
------------
When we are unlinking account_journal records with this context `{MODULE_UNINSTALL_FLAG: True}` we make sure to also delete the pos_payment_method and pos_payment linked to that journal. This is done here https://github.com/odoo/odoo/blob/854c3b27aa5476c208572f19e64f8f3364bfc381/addons/account/models/chart_template.py#L202
opw-4245944
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes a Time Off issue where accrual plans that grant leave at the start of a period did not immediately credit the current period when an allocation began. Employees can now see and request newly accrued leave correctly, including allocations that started at zero days but have since earned time off.
Original PR description
Steps to reproduce: - Time off > Configuration > Accrual Plan > New - Set 'Accrued Gain Time' to 'At the start' - New Milestone > Set 'Milestone reached' to 0 days after... - Accrue 1 day Monthly on…
Steps to reproduce:
- Time off > Configuration > Accrual Plan > New
- Set 'Accrued Gain Time' to 'At the start'
- New Milestone > Set 'Milestone reached' to 0 days after...
- Accrue 1 day Monthly on the last day of the month > Save
- Management > Allocations > New
- Tick 'Accrual allocation' > Set the 'Accrual Plan' to your newly created plan
- Set the start date to today
- 0 days of allocation for 'Time off type' of your choice > Validate
- My time > Dashboard > Use 'Balance at the mm/dd/yyyy'
The accrual grants 1 day of leave for the upcoming month on the last day of each month, you will however notice that no leave is granted for the current month until we reach its last day. According to the logic of our accrual, 1 leave day should have been granted on the last day of the previous month so we should get our partial credit for the current month immediately instead.
The first step is to simply add the leave days of the corresponding period but this leads to other issues. When computing accruals that are granted at the start of start of the accrual period we use the already_accrued flag to avoid recomputations, but this flag can be raised by a call chain in the write method of hr.leave.allocation starting from _get_consumed_leaves.
This call chain passes through _process_accrual_plans, and invalidates the cache on its way out though _get_future_leaves_on. This notably happens when computing leaves_taken in _process_accrual_plans which can mess with the record's fields, including but not limited to the already_accrued flag which induces errors in the number_of_days we are trying to compute.
Also, the domain we use to restrict the leaves type that can be picked when asking for a leave prevents us from using allocations that start with 0 days. ('max_leaves', '>', 0) rules out these leaves, even after they have accrued enough time off to legitimately request a leave of this type. Disabling max_leaves = 0 does not seem to serve much purpose as a non-accrual leave starting with 0 days should only be able to fulfill the other conditions if it has 'allows_negative', in which case we would want it to show up anyway.
opw-4192703
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes an issue where visitors booking appointments could be blocked from creating a contact record. Appointment scheduling now works more reliably for public users, reducing failed bookings and support friction.
Original PR description
Due to recent change introduced in 8b9a1a4462453bf64e7bc1307ededd0d127a27fa The customer variable can be non sudo for the public user when only using appointment module. Add a sudo to ensure contact creation. Task-4247116
This update improves manufacturing workflows by making Shop Floor entry behave consistently, showing clear pending status instead of a blank timer, and correcting weekly planning headers when weeks cross month boundaries. These fixes reduce confusion for production teams and make manufacturing planning displays more accurate.
Original PR description
Various v18 bugfixes for MRP before the feature freeze. Current behaviour: 1. Entering the Shop Floor from a WO searches the WOs in that workcenter by state by default. 2. The timer field is blank if the WO is in ready or pending states. 3. The month substring in the weekly MPS display column header shows the month of the starting date if the given period straddles two months. Desired behaviour: 1. Entering the Shop Floor from a WO reflects the same behaviour as entering from MO, which is the suppression of the default filter. (Depends on #68419) 2. 'Pending' text is displayed if the WO is in pending state. 3. It shows the month of the end date instead. Task ID: [4154879](https://www.odoo.com/odoo/966/tasks/4154879)
This fixes an issue where return transfers created from the Barcode app could fail because quantities were left empty. The app now pre-fills return quantities from the original transfer, helping warehouse staff process returns without errors.
Original PR description
Commit odoo/odoo@57b8b2487def4 make the return wizard fill the product quantity to 0 default. This break the return flow in the stock_barcode application as the return picking is created on the fly but empty so an error is raised. To encounter this, returns created via stock_barcode app have their quantities set to the original stock move ones. The return picking is thus fill according to the need.
This update corrects when Group S payroll options are shown for Belgian companies and improves related error handling. It helps payroll users see the right contract and work entry settings while reducing confusing errors.
Original PR description
In this commit, fixes visibility and error handling for belgium companies. task-4213306
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 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.