Monday, March 18, 2024
8 changes · saas-17.1
Enhancements to existing features
This update automatically fills the PAN number when a GSTIN is entered, streamlining the process for users in India. Previously, users had to manually input the PAN, even after providing the GSTIN, leading to potential errors. This change simplifies tax compliance and reduces manual data entry.
Original PR description
Previously, users were required to enter their PAN number even after manually inputting their GSTIN, even though the PAN is inherently part of the GSTIN (spanning from the 3rd to the 12th character). Furthermore, there was no mechanism to alert users if the manually entered PAN did not match the PAN segment within the GSTIN. This commit automates the filling of the PAN based on the entered GSTIN. Now upon entering a GSTIN, the corresponding PAN is auto-filled. Task link: https://www.odoo.com/web#model=project.task&id=3767627 task-3767627 Forward-Port-Of: odoo/odoo#157006
Resolved issues and error corrections
This update fixes an issue where time off request details weren't visible when viewing attachments. Now, when you approve a time off request and attach a document, the request's information will be correctly displayed within the attachment preview, ensuring users have complete visibility into approved time off.
Original PR description
Steps ----- 1. Create a time off request, approve it and add a document. Issue ----- The details of the time off request are not visible when the attachment preview is displayed. **opw-3792894** Forward-Port-Of: odoo/odoo#157024
This update fixes a reporting issue where the Point of Sale sales report incorrectly displayed the total sales amount including VAT. The fix ensures the 'Total (VAT Excl)' column accurately reflects the sales amount excluding VAT, providing more precise financial reporting for sales transactions. This change impacts the accuracy of sales data analysis.
Original PR description
Current behavior: The pos sale report is showing the wrong value in the "Total (VAT Exl)" column. The value acutally shown is the total tax included. Steps to reproduce: - Create a product with a tax included in price - Create a pos order with this product - Validate the order - Close session and print the pos sales report - Check the value in the "Total (VAT Exl)" column. opw-3684937 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157753 Forward-Port-Of: odoo/odoo#157451
This update corrects a bug where the time off duration was incorrectly set to zero when a related contract was expired. The fix ensures accurate time off calculations by properly handling contract status changes, preventing misleading data and improving the reliability of time off reporting.
Original PR description
Purpose ======= The time off duration is set to 0 when the related contract is set as expired, then we remove the end date and set the contract back to running. That's because the check was done before calling super, hence the contract is excluded from the candidates because it is still expired without end date, which would make no sense when trying to retrieve the related calendar. TaskID: 3806342 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-pr Forward-Port-Of: odoo/odoo#157681
Managers can now see the description of new allocation requests. Previously, the system required managers to manually name each allocation to proceed with validation. This update ensures consistency in how allocations are created and viewed, improving the manager workflow.
Original PR description
Currently when a manager goes to validate an allocation, the name/description of the allocation is not displayed. This introduces the need for manager to name each allocation manually to be able to…
Currently when a manager goes to validate an allocation, the name/description of the allocation is not displayed. This introduces the need for manager to name each allocation manually to be able to validate them. Steps to reproduce: ------------------- * Open **Time off** app * On the dashboard, select **New allocation Request** * Save the allocation as it is * Select **Management** > **Allocations** > Observation : The description field of the new allocation is not filled. * Select the new allocation * Validate > Observation: Unable to validate, description field required. Why the fix: ------------ The description of an allocation corresponds to the field `name` in the model `hr_leave_allocation`. https://github.com/odoo/odoo/blob/e2ad568e6cd4de2d721149eb76d04f58c8510191/addons/hr_holidays/models/hr_leave_allocation.py#L40-L45 In the compute method of this field, the name gets actualy computed in the context of `is_employee_allocation`. https://github.com/odoo/odoo/blob/e2ad568e6cd4de2d721149eb76d04f58c8510191/addons/hr_holidays/models/hr_leave_allocation.py#L169-L177 We are in the context `is_employee_allocation` either by asking a new allocation from the dashboard, either by being on the `hr_leave_allocation_action_my` view. https://github.com/odoo/odoo/blob/2bcccbfb910609f6cf54d607d198aae4c5b28b86/addons/hr_holidays/static/src/views/hooks.js#L62-L65 https://github.com/odoo/odoo/blob/2bcccbfb910609f6cf54d607d198aae4c5b28b86/addons/hr_holidays/views/hr_leave_allocation_views.xml#L456 On those two views, the description is computed AND readonly. Since the name is readonly, it means that the inverse of the compute method will not get called, thus never setting `private_name`. https://github.com/odoo/odoo/blob/2bcccbfb910609f6cf54d607d198aae4c5b28b86/addons/hr_holidays/models/hr_leave_allocation.py#L182-L186 When a manages goes to approve an allocation, he goes through **Management** > **Allocations**. The views used are either `hr_leave_allocation_view_tree` or `hr_leave_allocation_view_form_manager`. On those views, we are not in the context `is_employee_id`, the allocation name is no more readonly AND the name is required in order to validate the allocation. For a manager to be able to see anything in the description, the field `private_name` must be set. https://github.com/odoo/odoo/blob/2bcccbfb910609f6cf54d607d198aae4c5b28b86/addons/hr_holidays/models/hr_leave_allocation.py#L164-L178 This fix aims to create consistency in the creation of allocations. We can observe that the name is not in `vals` in the `web_save` function when creating an allocation through the dashboard or the tab **My Time** > **My allocations**. However, when creating an allocation through **Management** > **Allocations**, name can be found in `vals`. https://github.com/odoo/odoo/blob/764088d6d5a5a18be451ec26b886691718bef835/addons/web/models/models.py#L69-L69 `vals` corresponds to `changes` in this function: https://github.com/odoo/odoo/blob/764088d6d5a5a18be451ec26b886691718bef835/addons/web/static/src/model/relational_model/record.js#L1045-L1051 To have the name added to `changes`, we ultimately need the following condition to be false. https://github.com/odoo/odoo/blob/764088d6d5a5a18be451ec26b886691718bef835/addons/web/static/src/model/relational_model/record.js#L592-L599 In the manager flow, this is the case as `name` is not readonly. As a regular employee, the only possible way to have this false while keeping the `name` readonly, is to make it an active field. `name` in now in `vals` and thus in `vals_list` in the create method. This now allows to set `private_name` through the inverse function of name. opw-3722093 Forward-Port-Of: odoo/odoo#155767
This update resolves an issue where down payment order lines were failing due to a recent change that removed product settings from down payments. The code has been updated to properly handle down payment lines without a product, ensuring these orders can be processed correctly. This improves the reliability of the sales order creation process.
Original PR description
Since 9aa52dd6418e5881adc2d96d15d062b55d6150c5, down payments are created without any product (and dp product settings have been removed). Nevertheless, the SOlines views were not adapted and the product was still required in the view, even if the line was a down payment. This commit makes sure that a down payment line without a product is considered valid client-side. opw-3798379 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a crash that occurred when deleting sheets within the spreadsheet feature. The fix ensures that charts are properly removed from the system when a sheet is deleted, preventing outdated chart references from causing errors. This improves spreadsheet stability and reliability.
Original PR description
__Current behavior before commit:__ When a sheet is deleted, `charts` from `OdooChartCorePlugin` are not being updated. Therefore, since the commit [`905d856`][1], `getOdooChartIds` returns some chart ids that do not exist on any sheet anymore. This induces a crash when opening a spreadsheet that contains such charts. __Description of the fix:__ Handle `DELETE_SHEET` event in `OdooChartCorePlugin` by removing Odoo charts that don't belong to any sheet. __Steps to reproduce the issue on runbot:__ - Insert a Odoo graph inside a spreadsheet (starting from any app) - Add a sheet to it to the new spreadsheet - Delete the sheet that contains the chart - Leave the spreadsheet - Go to Documents app and try to open the spreadsheet -> Traceback opw-3783745 [1]: https://github.com/odoo/odoo/commit/905d8565ad2fae3f7ff96606352ee3ab86ee78cb Forward-Port-Of: odoo/odoo#157847 Forward-Port-Of: odoo/odoo#157728
This update resolves a bug preventing users from correctly generating lot/serial numbers when registering by-products on the Shop Floor. The fix adds missing location IDs to the context, ensuring the manufacturing process functions as intended. This improves the reliability of lot/serial tracking within the production workflow.
Original PR description
### Steps to reproduce issue: 1. Create a Product with Lots/Serials tracking 2. Create a BoM with an operation and add Product as By-Product 3. Create a Manufacturing Order using the BoM, click on…
### Steps to reproduce issue: 1. Create a Product with Lots/Serials tracking 2. Create a BoM with an operation and add Product as By-Product 3. Create a Manufacturing Order using the BoM, click on Confirm then Plan 4. Go to Shop Floor, click on "Register [the By-Product]" - Not the button with the units 6. Click on either "Import Lots" or "Generate Serials" 7. Enter a Lot/Serial number and click on "Generate" 8. Traceback error: > loc_dest = self.env['stock.location'].browse(default_vals['location_dest_id']) > KeyError: 'location_dest_id' ### Explanation: When going through the Shop Floor, the context is missing a lot of elements that are normally passed in the manufacturing order form. https://github.com/odoo/odoo/blob/338173e231355d265ddc88bcef5e9b0a608e248e/addons/mrp/views/mrp_production_views.xml#L432-L437 ### Suggested fix: `default_dest_location_id` is the missing element causing the traceback but fixing it reveals that `default_location_id` is also missing, we then add it to the context as well. Test is done in Enterprise while fix is in Community. opw-3719439 Forward-Port-Of: odoo/odoo#155846