Daily updates from Odoo
Monday, March 18, 2024
19 changes
7 changes
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
1 change
Resolved issues and error corrections
The task planning dialog now handles single task selection consistently with the regular Select action instead of auto-planning unexpectedly. It also prevents an error when planning tasks without assigned people, making scheduling more reliable for project teams.
Original PR description
In the Plan dialog of the project tasks gantt view, you can choose to either plan your tasks according to the selected timespan with the "Select" button, or you can choose to Auto Plan them with the "Auto plan" button. However, when you click on a single line, it gets auto planned, which shouldn't happen, it should be planned with the logic of the "Select" button. Plus there was a traceback when trying to plan only tasks with no assignees, because we would do a division by zero without checking beforehand that it mustn't happen. This PR aims to fix these problems.
11 changes
Resolved issues and error corrections
Users reading Knowledge articles are now redirected back to the article they were viewing after signing in, instead of being sent to the backend or dashboard. This prevents users from losing track of the content they were reading and improves the overall experience when accessing Knowledge articles that require authentication.
Original PR description
When a user reads an article from the frontend view of Knowledge and clicks on the "Sign in" button to sign in: internal users will be redirected to the Odoo backend while portal users will be redirected to the `/my` page. The current redirection process is confusing because users may lose track of the article they were reading. If people re-open Knowledge after being redirected, they may no find the article they were reading as it could be hidden in the sidebar. When people click on the "Sign in" button from Knowledge, we assume that they probably wanted to edit the article, change the permissions, add new members, access their own workspace, etc. So, we will now redirect the user to the article they were reading after they sign in. With that change, portal users can still access the '/my' page from Knowledge by clicking on the home icon of the sidebar and internal users can view all apps of the backend by clicking on the home button of the Odoo navbar. task-3776350
Fixed a formatting issue in US check printing where complete address information would overlap with the check memo when using the TOP print format. The address font size has been reduced to prevent this overlap and ensure checks print correctly with full address details.
Original PR description
## Issue: - If a Contact record has a complete Address record (Street 1, Street 2, City, State, Zip, and Country) and the Check Print Format is set to TOP then the Address and the check memo overlap (see screenshot). ## Steps To Reproduce: - Create a contact with a long name and long address. - Be in a company set up under l10n_us. - Set your check printing to be Print Check (Top) - US. - Issue a Vendor Payment to the contact - Add a memo and print check. - The address overlaps the reference ## Solution: - Adjust the font size of the address to make it slightly smaller, thereby avoiding overlap. opw-3735486
This fix resolves an issue where manually adjusted discounts on sales orders were being overwritten by pricelist discounts during confirmation. The problem occurred because a recent change to handle subscription states was triggering an unintended recalculation of discount fields. The fix ensures discount protection is applied before subscription state modifications are made.
Original PR description
Versions -------- - saas-16.4+ Steps ----- 1. Create a pricelist wich shows discounts; 2. create a SO using this pricelist; 3. add a non-subscription-based product; 4. modify its discount; 5. confirm the SO. Issue ----- The manually modified discount gets overwritten by the pricelist one. Cause ----- Commit 71f15a9af4063bfb960b4706c3f237e69dd28e16 started protecting the discount field in `action_confirm` to protect it from recomputation when a start date would be added. This was adequate for earlier versions, but commit 4ac62c700826ce1b38307641f91b7c9ce4f91d54 added a line setting `subscription_state` to `False` for any SO that isn't an upsell or subscription. As this field is also a dependent of `_compute_subscription`, a recompute is triggered. Solution -------- Move the `with self.env.protecting` clause up, before the for-loop which modifies `subscription_state`. opw-3646915 Forward-Port-Of: odoo/enterprise#58437
This fix corrects how the "CFDI to Public" status is calculated when a point-of-sale order is converted to an invoice in Mexico. Previously, the system incorrectly marked invoices as public (using a generic RFC) even when a customer provided their actual tax ID. Now the system properly recalculates this field based on the customer's actual information, ensuring invoices are submitted to Mexican tax authorities with the correct customer details.
Original PR description
How to reproduce: - in point of sale, enable "Generate a code on ticket" - create a pos_order, save the ticket - using the code on the ticket, request an invoice through the portal and fill the information as if you were a mexican company => An invoice is generated and sent successfully to the SAT, but "CFDI to Public" is True on the invoice. Hence, the receptor's RFC will be "XAXX..." instead of the RFC filled in the portal. Reason: The pos_order has "CFDI to Public" to True, and this value is copied on the invoice. Fix: Recompute the value for the "CFDI to Public" field on the pos_order when the partner_id is filled. It should only be True when the Receptor's RFC is "XAXX...". Note that the new compute for "CFDI to Public" on the pos_order now resembles the one on the account_move. opw-3767576
This fix removes the automatic activation of the US tipping feature for all new Point of Sale systems. Previously, new customers outside the US were getting the tipping option enabled by default, which was not appropriate for their business needs. Now, the tipping feature will only be enabled when explicitly configured for the customer's country.
Original PR description
In SaaS, the DB is pre-prepared with the generic chart of accounts before the new user finishes the form. Since the default country of the generic chart of accounts is the US, then `set_tip_after_payment` option in the pre-created pos.config is set to True. Now, when the form is submitted, the country is identified but the said option remains to be True. This is a problem because not all customers are creating an odoo instance for a US company. So customers from other countries will have the option activated by default which is not a good default for them. We introduced this behavior in aa1c5b53bf131c6df96ad621e00bd2ee3d44c6c0 and in this commit we won't set the option by default anymore.
This fix resolves an error that occurred when users tried to preview email marketing templates on mobile devices while in debug mode. The preview feature was not functioning properly due to a recent code change, preventing users from seeing how their emails would appear on mobile devices before sending.
Original PR description
Current behavior: --- When trying to preview a mailing template with the debug mode enabled, there is an error: Invalid props for component Steps to reproduce: --- 1. Enable debug mode with assets 2. Go to Email Marketing 3. Create a new Mailing 4. Select a template 5. In the Editor, click on the mobile icon 6. ... 'preview' is not a function Cause of the issue: --- Caused by https://github.com/odoo/odoo/commit/13b3f8af4b55d32912b698ae1672be9e144cb775 opw-3702901 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures that when creating projects, the system now correctly uses the analytic plan selected in the Project settings rather than ignoring that choice. Previously, projects would always use a default plan even after administrators changed the setting to a different plan option like Departments instead of Projects.
Original PR description
Currently, the `plan_id` used to create analytic accounts is not the one set in the settings. Steps to reproduce: ------------------- * Go to the **Settings** * Enable developper mode * Select **User…
Currently, the `plan_id` used to create analytic accounts is not the one set in the settings. Steps to reproduce: ------------------- * Go to the **Settings** * Enable developper mode * Select **User & Companies** > **Groups** * Select `Technical/Analytic Accounting` * Add user * Go to the **Project** app * Select **Configuration** > **Settings** * Under **Time Management**, enable Timesheets * Under **Analytics** > **Analytic Plan**, select Projects * Create a new project * Go into the settings of the project * Under the **Settings** tab, select the internal link for the **Analytic Account** > **Observation**: The Plan is set to Projects * Go to **Conffiguration** > **Settings** * Under **Analytics** > **Analytic Plan**, change Projects to Departments * Create a new project * Go into the settings of the project * Under the **Settings** tab, select the internal link for the **Analytic Account** > **Observation**: The Plan is still set to Projects Why the fix: ------------ When creating, an analytic account, the plan is computed with `_get_all_plans()`. https://github.com/odoo/odoo/blob/e365e22485dc45f1cbe87ae93395b022a4724a3c/addons/project/models/project_project.py#L894-L903 Inside `__get_all_plans()` the plan is computed as follows: https://github.com/odoo/odoo/blob/e365e22485dc45f1cbe87ae93395b022a4724a3c/addons/analytic/models/analytic_plan.py#L106-L107 However, the setting that the user changes in the frontend corresponds to `analytic.analytic_plan_projects`. https://github.com/odoo/odoo/blob/e365e22485dc45f1cbe87ae93395b022a4724a3c/addons/project/models/res_config_settings.py#L18-L22 This seeting is not company-related. It can be used on projects even if they have a `company_id` set to false. We fallback on `_get_all_plans()` if the user did not specifically choose a plan in the settings. opw-3751661
This fix restores the ability to select "Dropship" as a delivery option when creating purchase orders and RFQs. The dropship feature was previously unavailable in the delivery dropdown due to a system update that wasn't reflected in the selection filters. This fix ensures users can properly configure dropship deliveries and specify which customer should receive the shipment.
Original PR description
**Current behavior:** When making a new RFQ, dropship is not an available selection for the 'Deliver To' option. **Expected behavior:** As on previous versions, you should 'dropship' should be selectable here which reveals a sub-selection to select the customer who should receive the shipment. **Steps to reproduce:** 1. Enable `Dropshipping` in Purchase settings as well as `Storage Locations` in Inventory settings 2. Create a new RFQ, observe that in the 'Deliver To' dropdown there is no way to select a dropship option **Cause of the issue:** Dropshipping was made into a discrete `stock.picking.type`.code and the domain that constrains the selection menu options was not updated to accomodate this change. **Fix:** Update the domain to show picking types that have the dropship code. opw-3764617 Forward-Port-Of: odoo/odoo#155529
Fixed an issue in the website editor where updating a button's label would cause any custom styling (font size, color, etc.) to be lost. The problem occurred because the system was incorrectly identifying text elements when updating labels. This fix ensures that custom styles are preserved when users edit button labels from the sidebar.
Original PR description
Issue: ====== When you update the link button label from the sidebar it loses its style. Steps to reproduce the issue: ============================= - Got to website editor - Insert a text block - Added a button in the text block and any label - Click on the button to edit it from the sidebar - Change font size or font color or any style you want - Update the label - The style is lost Origin of the issue: ==================== When updating the label, we search for the first child that has that text, but when we have `ZWS start` it will be considered as the first child and then we update the inner text of the `a` element so we loose the span of the text which has the custom styles. Solution: ========= We search for the first child which is not `ZWS` task-3721686 Forward-Port-Of: odoo/odoo#155038
Fixed a bug in the Newsletter Block snippet where users could encounter an error when configuring the "Thanks" message option with certain "On Success" settings. The fix hides the "Display Thanks Button" option when it's not applicable, preventing configuration errors and improving the user experience.
Original PR description
When configuring a Newsletter Block snippet to display a subscription form, the option to decide whether a message must be displayed is only available when "On Success" is set to "Show Message" through the button beside that option. Unfortunately, the general option for the "Thanks" message is not disabled for other "On Success" values, for which no outcome can display a message. Trying to combine these triggered an error. This commit fixes this problem by hiding the "Display Thanks Button" option when the "Form Subscription" template is selected. Steps to produce: - Install `website_mass_mailing`. - Drop a "Newsletter Block" snippet. - Change template to "Form Subscription". - Click on "Subscribe" button. - Change "On Success" to "Nothing". - Click on "Display Thanks Button". => An error was displayed. task-3748574 Forward-Port-Of: odoo/odoo#157517
This fix ensures that payment term notes appear in the customer portal preview, matching what customers see in the printed sales order. Previously, only the payment term name was shown in the preview while the full note was visible in the printed report, creating a confusing inconsistency.
Original PR description
Description: There is a discrepancy between the printed sale order report and the customer preview when it comes to displaying the Payment Terms. On the SO report, Odoo prints the 'note' field, whereas on the preview, Odoo only displays the 'name' field. Desired behavior after PR is merged: Customer preview now matches the printed report by displaying the payment_term.note field as well opw-3790997 Forward-Port-Of: odoo/odoo#157475