Daily updates from Odoo
Navigate
Branch
Monday, March 18, 2024
71 changes
21 changes
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 the 'dropship' option was missing from the 'Deliver To' dropdown in RFQs. The change ensures users can correctly select dropshipping for new purchase orders, aligning with previous functionality. This improves the user experience for dropshipping workflows.
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
This update resolves a bug in the Website Editor that prevented users from correctly resizing columns within the editor iframe. The issue stemmed from a change in how the editor's preview was structured, specifically after version 16.0. This fix ensures proper column resizing functionality.
Original PR description
**[FIX] web_editor: fix resize column outside of the iframe** Steps to reproduce the bug: - Enter Website edit mode. - Drag and drop an "Image-Text" snippet onto the page. - Grab the right edge of…
**[FIX] web_editor: fix resize column outside of the iframe** Steps to reproduce the bug: - Enter Website edit mode. - Drag and drop an "Image-Text" snippet onto the page. - Grab the right edge of the right column of the snippet and extend it to the right until it overflows the iframe and hovers over the editor panel. - Release the mouse, then hover over the iframe again. - Bug: The "mouseUp" event was not triggered, and the column resizing still occurs. This bug occurs because the "mouseUp" event was attached to the <body> of the iframe and not to the window of the iframe. Indeed, for mouse events to be triggered outside of an iframe, they need to be attached to the iframe's window. This fix is not necessary before the version 16.0. Before V16.0, the page preview and the options panel shared the same window. It's only since this commit [1], where we moved the page preview into an iframe, that the bug occurs. [1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b taks-3562970 Forward-Port-Of: odoo/odoo#157627 Forward-Port-Of: odoo/odoo#156529
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 ensures website images automatically adjust to different screen sizes, preventing overflow issues when the default thumbnail style is removed. By adding the 'img-fluid' class, images will now scale correctly, providing a better user experience across devices. This is a simple fix that improves visual consistency.
Original PR description
Add `img-fluid` class so that image remains responsive when `Shape: Thumbnail` is not applied. task-3266862 Forward-Port-Of: odoo/odoo#118916
This update fixes an issue where changing the label of a link within the website editor would remove any associated styling. The fix ensures that style changes to link labels are correctly preserved, improving the user experience when customizing website content. This resolves a visual inconsistency and allows for more flexible content design.
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
This update fixes a technical issue preventing users from correctly configuring newsletter subscription blocks. Specifically, the 'Display Thanks Button' option was causing errors when combined with certain 'On Success' settings. This change ensures a smoother user experience when setting up newsletter forms.
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 update resolves an issue where submenus wouldn't display properly when the website's navigation switched to 'Hover' mode. The fix adjusts the offset settings within Bootstrap to ensure submenus appear as expected when hovering over menu items, improving the user experience.
Original PR description
Steps to reproduce: - Go to website > Switch the navbar to "Hover" mode (see: `Submenus` > `On Hover`). - Create a submenu and drag it under a navbar menu item > The submenu will always disappear…
Steps to reproduce: - Go to website > Switch the navbar to "Hover" mode (see: `Submenus` > `On Hover`). - Create a submenu and drag it under a navbar menu item > The submenu will always disappear before being reached after the hover. Since Bootstrap does not provide a built-in way to use the "hover" as a dropdown trigger, a custom implementation was used to handle the "show on hover" scenario (see: `hoverableDropdown`). This code also relies on the submenus being correctly positioned on hover. Starting from [1], the public `menuDirection` widget was completely removed (used to align website navbar submenus in an optimal way) and was replaced by a patch that allows Bootstrap to position dropdowns dynamically inside a navbar (using Popper). A side effect of this patch is the use of BS default offset config to set the positions, leading to a small gap that automatically hides the submenus when hovered. The goal of this commit is to prevent this issue by simply forcing the offset to 0 when the dropdowns are inside a navbar. [1]: https://github.com/odoo/odoo/commit/8689241f86e2d4ddb4e4510951f92b80e115b914 opw-3766516 Forward-Port-Of: odoo/odoo#157804 Forward-Port-Of: odoo/odoo#157281
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 fixes an issue where PDF attachments uploaded via the chatter's drag-and-drop feature weren't correctly displayed in the PDF viewer. The fix ensures that attachments uploaded through the dropzone are properly loaded, improving the user experience when viewing invoices.
Original PR description
Steps to reproduce ================== - Go to Accounting > Customer Invoices - Open any record with no attachments - Drag & drop a pdf attachment on the chatter => The PDF viewer is empty Cause of the issue ================== When uploading an attachment from the FileUploader, the parent view is reloaded. This is not the case when uploading an attachment from the dropzone. opw-3748853 Forward-Port-Of: odoo/odoo#157232
This update fixes a bug where the product configurator wasn't shown for products with only custom attributes, preventing users from customizing these items when adding them to their cart. Now, the configurator will automatically open for any product with configurable attributes, streamlining the customization process for simple products.
Original PR description
Before this commit, the product configurator dialog was not shown when adding to the cart, a product with only no variant attribute values, using the buy button on the '/shop' page. Now, if the product has configurable attributes, the product configurator dialog is shown. opw-3736469 Forward-Port-Of: odoo/odoo#157737
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
This update resolves an issue where the calendar month view incorrectly displayed event start times before 9:00 AM. The fix ensures that event start times are accurately shown, regardless of the event creation time, by setting the event duration. This improves the overall usability of the calendar feature.
Original PR description
The `test_calendar_month_view_start_hour_displayed` makes sure that start hour is displayed in calendar month view. The test was failing before 09:00 AM because after creating the event, it sets the start time to 10:00 without setting the stop time or duration. So when creating this event before 09:00 with a default duration of 1 hour, the stop time would be before 10:00, and it would raise an error. This commit aims to fix this issue by adding a step to set the duration of the event, avoiding the potential error. fixes runbot-59850 Forward-Port-Of: odoo/odoo#157263
A technical issue preventing users from opening the P&L report when using a specific grouping option has been resolved. This fix corrects a typo in a database constraint, ensuring the report functionality works as intended. The change was a result of a minor oversight during a report improvement.
Original PR description
Steps to reproduce: - accounting report > P&L > net profit: set the 'groupby' to 'account_id' - save - try to open the P&L -> Invalid Operation Cause: During the improvement of the report a small change has been forgotten The `groupby` has been changed to `user_groupby` https://github.com/odoo/enterprise/commit/99c82df3d24209de12e2442fd15d2472d9e968f6#diff-bc8d6ed5aa6dab6b7ba46566170cdb7297104580d9b8d6c7081f72e3c2a5a9c4R187-R191 and we forgot to change the `api.constrains`'s args opw-3714626 Forward-Port-Of: odoo/odoo#156879
This update ensures that employees and users automatically have an avatar displayed when a picture isn't manually set. Previously, a blank space was shown. This enhancement provides a more professional and consistent user experience, especially for new internal users.
Original PR description
Improve avatar picture : if no picture is set, initials will be displayed. task : 3637523 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147446
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 fixes an issue where notes on sale orders weren't consistently formatted in the sale order report. The change ensures that notes are properly aligned and readable, improving the clarity and professionalism of the reports generated for sales data. This enhances the user experience when reviewing sales information.
Original PR description
opw-3725405 Forward-Port-Of: odoo/odoo#157859
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
This update fixes a visual issue where 'false' was incorrectly displayed next to recipients in the system when their email address was missing. Now, users without email addresses are shown with their name followed by '(no email address)', improving the user experience and ensuring accurate recipient information is presented.
Original PR description
'false' is displayed in the popover next to the recipients in the absence of an email address as well as the title of the recipients If the partner has no email, it should show something like "[name] (no email address)]" task-3787703 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157850 Forward-Port-Of: odoo/odoo#157431
21 changes
New functionality added to Odoo
Adds Latvia-specific Balance Sheet and Profit & Loss reports, including Latvian translations. This helps businesses operating in Latvia access localized financial reporting directly in Odoo.
Original PR description
Add the Balance Sheet and Profit & Loss reports for Latvia, as well as the translation for the module. task-3640443
Enhancements to existing features
This update standardizes the wording from “canceled” to “cancelled” across Helpdesk, Field Service, timesheet-related Helpdesk sales views, and Sales Planning. It improves consistency in customer-facing labels and messages without changing functionality.
Original PR description
*=helpdesk_fsm,helpdesk_sale_timesheet This PR renames the remaining occurrences of "canceled" to "cancelled". Task-3713873
The Planning app receives several usability improvements that make scheduling clearer and easier to act on. Users get clearer email wizard wording, better filters, improved popovers and progress displays, more helpful overlap warnings, and quick actions in their planning list.
Original PR description
*_ = planning_holidays, project_forecast, project_forecast, project_timesheet_forecast, sale_planning, sale_timesheet_enterprise, timesheet_grid, web_gantt Purpose of this PR is to improve the generic UX of the planning app. So, in this PR: - change send planning by email wizard names. - rename filter name from non billable to non-billable. - set placeholder for the planning_role_ids. - make 'plan services' false when creating services on the fly. - add start_date and end_date filter. - improve front-end popover UI. - change progress bar value hour format. - change Gantt view progress bar warning. - add a button in the list view of my planning. - change overlap slot message task-2962840
The product catalog has been adjusted so it can better support more complex business flows, such as adding catalog items into different sections that share the same parent or base record. This makes it easier for future Odoo features and customizations to reuse the catalog in manufacturing, field service, and sales-related scenarios without duplicating logic.
Original PR description
- Take arguments passed into product catalog related rpc calls into a separate function to make them patchable. - Add kwargs to product catalog mixin methods in order to allow more versatility with passing arguments Use cases: - Adding product catalog to sections having same parent (e.g. components and byproducts inside mrp.bom) - Adding product catalog to sections having same base model (e.g. components and byproducts inside mrp.production are both stock.move) - etc In such cases it is convenient to pass an extra arguments referring to child model or parent model to handle differences on the backend. Task: 3640422
Peruvian invoice PDFs now include the SPOT withholding amount and the bank account where customers must make the related payment. This makes required payment information visible directly on the invoice document instead of only in the electronic XML file, reducing confusion and helping customers pay correctly.
Original PR description
In Peru we have the SPOT system, where a customer may have to pay a withholding on the invoice he receives in a specific bank account. Currently some of the required information is only available in the XML of the electronic invoice, but not on the PDF representation. In this commit, we add the withholding amount and the bank account number on which they have to pay to the PDF, as well as format all the information in a clear way. [task-3413744](https://www.odoo.com/web#id=3413744&model=project.task&view_type=form&cids=1)
Austrian financial reports were updated so their labels and report codes are clearer and better translated. The change also adds missing accounts to reduce empty report categories, improving report completeness for local accounting users.
Original PR description
Changed from tag formula to code formula. Added new accounts to fill empty categories. Translated everything to English, with po/pot added for German Should be good except 22-23-24 where I don't know what to do
Messaging channels now avoid updating every member whenever a new message is posted. This improves scalability and responsiveness for large conversations, including WhatsApp-related discussion channels, without changing the intended user experience.
Original PR description
In `message_post()`, there is a LOC to write to all members of the channel on `is_pinned` and `last_interest_dt`, which cannot possibly scale well.
This commit removes the writing to all members and instead uses:
1. add `channel.last_interest_dt` and only do writing to the channel
when doing the `message_post`.
2. remove writing to the `channel_member.is_pinned` and add
`channel_member.unpin_dt`. Making the `is_pinned` a computed field
instead.
task-3624265
https://github.com/odoo/odoo/pull/155569Chilean and Dutch accounting reports were updated to keep working after underlying account fields were changed from stored values to calculated values. This helps maintain accurate reporting while also standardizing related accounting query handling to avoid formatting issues.
Original PR description
The fields `include_initial_balance` and `internal_group` are not stored anymore.
Resolved issues and error corrections
The project sharing list now hides the customer/partner column when it does not apply to the project type. This reduces confusion for users viewing shared field service projects by only showing relevant information.
Original PR description
Before this commit, the `hide_partner` context was passed by the python method returning the main action for project sharing feature to be able to hide the `partner_id` column in the main view when the project is not billable and nor fsm one. This commit overrides the list view to add that condition in `column_invisible` attribute of `partner_id` field. task-3615844
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.
The preparation display tests were reorganized so each screen only loads the test files it actually needs. This prevents unnecessary dependencies from causing errors and helps keep point of sale and preparation display checks stable.
Original PR description
The `pos_preparation_display` launches tours both in the `point_of_sale` and in `pos_preparation_display` interfaces. Previously, it was importing all the tours files from pos, which is not needed and which lead to erros. For example if one of the tours in pos has a dependency in a different folder, than the preparation display would have to bring this dependency too. The solution is to split the test files in the `pos_preparation_display` module into `point_of_sale` and `pos_preparation_display` folders.
Miscellaneous changes
Replace outdated realpath usage with odoo tools.file_open. Allows file_open to locate file from addons path rather than looking up through realpath. This will resolve potential issues with realpath not finding the proper path of files in certain situations (like a symlink). Worth noting that file_open uses abspath instead of realpath anyway. Forward-Port-Of: odoo/enterprise#58766 Forward-Port-Of: odoo/enterprise#58305
Original PR description
Replace outdated realpath usage with odoo tools.file_open. Allows file_open to locate file from addons path rather than looking up through realpath. This will resolve potential issues with realpath not finding the proper path of files in certain situations (like a symlink). Worth noting that file_open uses abspath instead of realpath anyway. Forward-Port-Of: odoo/enterprise#58766 Forward-Port-Of: odoo/enterprise#58305
Issue ---- This commit fixes an argument passed in the wrong format, resulting in isFlexibleHours always returning False. isFlexibleHours is expecting a resource's id as an argument in order to find whether the resource's working calendar is flexible or not. However, the argument passed to the function was not the resource id, but the resource itself. As the `!!` operator was used in the function, the returning value was always False (!!undefiend == False) This commit fixes this by passi
Original PR description
Issue ---- This commit fixes an argument passed in the wrong format, resulting in isFlexibleHours always returning False. isFlexibleHours is expecting a resource's id as an argument in order to find whether the resource's working calendar is flexible or not. However, the argument passed to the function was not the resource id, but the resource itself. As the `!!` operator was used in the function, the returning value was always False (!!undefiend == False) This commit fixes this by passing the id instead of the object. related Task: 3762895 Forward-Port-Of: odoo/enterprise#58750
Steps to reproduce: - - Go to Field Service app and create a new task. - Use the smart button to access the catalog and add a product. - Go back to the task and use the smart button to access the SO. - Set the unit price of the added product to zero. - Create the associated invoice. **You are allowed to create the invoice and aline will be displayed for the SOL corresponding to the products with a unit price of zero.** Notes: This is the expected behavior for invoices generated from
Original PR description
Steps to reproduce: - - Go to Field Service app and create a new task. - Use the smart button to access the catalog and add a product. - Go back to the task and use the smart button to access the SO.…
Steps to reproduce: - - Go to Field Service app and create a new task. - Use the smart button to access the catalog and add a product. - Go back to the task and use the smart button to access the SO. - Set the unit price of the added product to zero. - Create the associated invoice. **You are allowed to create the invoice and aline will be displayed for the SOL corresponding to the products with a unit price of zero.** Notes: This is the expected behavior for invoices generated from regular SO. However, AJU the PO of the Field Service application decided to change this behavior for invoices generated from SO coming from field services see task 3266856 and commit 849241e (the SOL invoice status should be 'no'). Cause of the Issue: - When you create an invoice from a sale order, the `invoiceable_lines` are computed at this point: https://github.com/odoo/odoo/blob/96a06df867fcef1fd24a1798bd5d6decc423933b/addons/sale/models/sale_order.py#L1251-L1258 by the `_get_invoiceable_lines` method. As one can see in this method: https://github.com/odoo/odoo/blob/96a06df867fcef1fd24a1798bd5d6decc423933b/addons/sale/models/sale_order.py#L1220 if the `qty_to_invoice` of SOL is positive, the SOL will therefore appear in the `invoiceable_lines` and the associated invoice line will be created a few lines below to appear on the invoice: https://github.com/odoo/odoo/blob/96a06df867fcef1fd24a1798bd5d6decc423933b/addons/sale/models/sale_order.py#L1276-L1279 Fix: - In order for the SOL to not generate an`invoiceable_line` we set the `qty_to_invoice` to zero when the SOL comes from a field service task and display a product with a unit price of zero. Notes: To keep the flow coherent between the `qty_to_invoice` and the `invoice_status` of SOL for field services SO and since `price_unit` is a float that should not be compared using an `==` we also changed the float comparaison of the `_compute_invoice_status` method introduced in the commit 849241e. opw-3776475 --- Forward-Port-Of: odoo/enterprise#58609 Forward-Port-Of: odoo/enterprise#58057
Steps to Reproduce: - install helpdesk module - under configuration, click on helpdesk teams - In helpdesk teams form view enable automatic assignment Issue: - under automatic assignment, the 'team members' label is misaligned Cause: - in member_ids field class contains overflow-hidden, because of that it is misaligned Solution: - if we remove that overflow-hidden, the issue is solved. task-3683976 Forward-Port-Of: odoo/enterprise#54399
Original PR description
Steps to Reproduce: - install helpdesk module - under configuration, click on helpdesk teams - In helpdesk teams form view enable automatic assignment Issue: - under automatic assignment, the 'team members' label is misaligned Cause: - in member_ids field class contains overflow-hidden, because of that it is misaligned Solution: - if we remove that overflow-hidden, the issue is solved. task-3683976 Forward-Port-Of: odoo/enterprise#54399
Before this commit, when a salesperson canceled a renewal quotation, and reset it to draft, the subscription_state '2_renewal' was lost. It would affect the sale_order_log upon confirmation of that renewal and the sale.order.log would not be correct. In that case, there would be a missign transfer log. taskid: 3651477 Forward-Port-Of: odoo/enterprise#58490
Original PR description
Before this commit, when a salesperson canceled a renewal quotation, and reset it to draft, the subscription_state '2_renewal' was lost. It would affect the sale_order_log upon confirmation of that renewal and the sale.order.log would not be correct. In that case, there would be a missign transfer log. taskid: 3651477 Forward-Port-Of: odoo/enterprise#58490
Steps to reproduce: - Create a child company/branch - Create a child Bank Journal for the Child Company - Set on demo use the default company as the child company - Connect with demo - In the Accounting Dashboard try to open the Child Bank Issue: Access Error opw-3746324 Forward-Port-Of: odoo/enterprise#57145
Original PR description
Steps to reproduce: - Create a child company/branch - Create a child Bank Journal for the Child Company - Set on demo use the default company as the child company - Connect with demo - In the Accounting Dashboard try to open the Child Bank Issue: Access Error opw-3746324 Forward-Port-Of: odoo/enterprise#57145
Forward-Port-Of: odoo/enterprise#58592
Original PR description
Forward-Port-Of: odoo/enterprise#58592
Steps to reproduce: ------------------- - being in Europe/Brussel timezone; - create a contract based on attendance from 1st to 31st January; - create two attendancescfot the employee linked to this contract: - 5th January from 8am to 4pm for example (A) - 31st January from 00:30am to 8:30pm (B) - create a payslip for the employee from 1st to 30th January; Issue: ------ The attendance count on the smart button on the payslip and the number of records on the list view (when th
Original PR description
Steps to reproduce: ------------------- - being in Europe/Brussel timezone; - create a contract based on attendance from 1st to 31st January; - create two attendancescfot the employee linked to this…
Steps to reproduce:
-------------------
- being in Europe/Brussel timezone;
- create a contract based on attendance from 1st to 31st January;
- create two attendancescfot the employee linked to this contract:
- 5th January from 8am to 4pm for example (A)
- 31st January from 00:30am to 8:30pm (B)
- create a payslip for the employee from 1st to 30th January;
Issue:
------
The attendance count on the smart button on the payslip and the number of records on the list view (when the smart button is clicked) are not the same.
Cause:
------
The domain that determines attendance uses a condition on the `check_in` field, which is a datetime field, and compares it with a date. For attendance B, we will compare 2024-30-01 23:30:00 with 2024-30-01 23:59:59.
As a result, attendance B will validate this condition.
Solution:
---------
Make this information consistent by using the same logic and taking account of timezones.
Add a method that allows you to retrieve all attendances linked to a payslip. Use this to generate the domain that will select the correct records (based on their id) in the list view.
Note:
-----
`_read_group` manages timezones and therefore
`check_in:day` for attendance B returns 2024-31-01.
opw-3794161
Forward-Port-Of: odoo/enterprise#58587
Forward-Port-Of: odoo/enterprise#58431`discount` field on `sale.order.line` model is configured in sale_subscription to be recomputed when the order `subscription_state` is modified. Therefore, updates to that field should be avoided unless necessary. Nevertheless, in the override of `action_confirm`, the subscription state was always updated to False for non subscription orders, leading to an unexpected recomputation of discounts. opw-3740645 See also: https://github.com/odoo/odoo/pull/157699 Forward-Port-Of: odoo/ent
Original PR description
`discount` field on `sale.order.line` model is configured in sale_subscription to be recomputed when the order `subscription_state` is modified. Therefore, updates to that field should be avoided unless necessary. Nevertheless, in the override of `action_confirm`, the subscription state was always updated to False for non subscription orders, leading to an unexpected recomputation of discounts. opw-3740645 See also: https://github.com/odoo/odoo/pull/157699 Forward-Port-Of: odoo/enterprise#58673
Steps to reproduce: - Install l10n_hk_hr_payroll Current behaviour: - Time off type name contain year value Expected behaviour: - Time off type name should not contain year value Explanation: - Year changed will not update the time off type name, therefore better to not include the year value inside the name X-original-commit: 224aa76 Forward-Port-Of: odoo/enterprise#58717
Original PR description
Steps to reproduce: - Install l10n_hk_hr_payroll Current behaviour: - Time off type name contain year value Expected behaviour: - Time off type name should not contain year value Explanation: - Year changed will not update the time off type name, therefore better to not include the year value inside the name X-original-commit: 224aa76 Forward-Port-Of: odoo/enterprise#58717
29 changes
New functionality added to Odoo
A new statement of account report has been added to the Malaysia localization module's follow-up reports feature. This enhancement enables businesses to generate detailed account statements for their customers, improving financial reporting and customer communication capabilities in Odoo 17.0 and above.
Original PR description
Impacted Version: - 17.0 and above This commit improve below features: - Create statement of account reports in follow-up reports task-3610441
Enhancements to existing features
This update improves how Odoo fetches bank statements from CodaBox when users have multiple bank accounts. Previously, the system would download files based on the oldest inactive account, resulting in unnecessary downloads of old statements. Now, each account tracks its own last statement date, allowing the system to fetch only relevant recent files for each account separately. This makes the import process faster and more efficient.
Original PR description
Currently we send a list of ibans, and a single date from which to fetch the files. This is a bit problematic if the user has multiple journals and one of which is not used. In such a case, this old journal won't have transactions for months. Then we'll use the date of this old journal as the one from which to start fetching. So a journal that is up to date and gets documents everyday will still use this old date. Therefore we'll download lots of files (3 months or historic) even though the vast majority will not be used (only skipped because already imported) From now on, for each journal, we send the date of the last bank statement along with the IBAN of the journal, so that on IAP's side, we can filter out older bank statements. This allows faster fetching of the files. IAP: https://github.com/odoo/iap-apps/pull/771 task-id 3762743
IoT devices can now automatically send their logs to the Odoo server instead of requiring manual log file collection from customers. This improvement enables faster support troubleshooting by eliminating the need for customers to manually retrieve and share IoT logs, which previously required on-site access to the local network. The feature can be toggled on or off through the Handlers configuration page.
Original PR description
Before this commit: IoT logs are kept in an IoT log file. Any time the support would need IoT log information, we are forced to ask the customer to send it to us as it requires to be in the LAN.…
Before this commit: IoT logs are kept in an IoT log file. Any time the support would need IoT log information, we are forced to ask the customer to send it to us as it requires to be in the LAN. After this commit: Relevant* log lines will be automatically send out to the server using an HTTP route. This feature can be toggled within the Handlers list page  preview:  *: Relevant = - Any odoo logs (depending on the level set in the handlers list, see: https://github.com/odoo/odoo/pull/134174 ) - Any other logs (werkzeug, python libraries, etc.) except /hw_proxy/hello Note: IoT logs received by the server will ALWAYS be logged regardless of it level. So an Odoo server set in INFO which receive a DEBUG log from the IoT will log it in its log with the DEBUG level Related odoo PR: https://github.com/odoo/odoo/pull/150920 opw-3696519 Forward-Port-Of: odoo/enterprise#57836 Forward-Port-Of: odoo/enterprise#55055
This update improves how event registration confirmation emails are sent by allowing them to be processed asynchronously instead of immediately. When many people register for an event at the same time, this change prevents the system from slowing down by deferring email generation to scheduled background tasks. This is especially beneficial for events with high registration volumes.
Original PR description
This PR introduces a new configuration parameter 'event.event_mail_async' forcing registrations-based communication to be asynchronous. Instead of directly sending communication it triggers the cron to be run as soon as possible. When having large volume of registrations, and especially concurrent registrations it saves a DB to avoid generating tickets and preparing emails synchronously to the registration creation. Task-3764894: Event: Allow using cron triggers for communication Part of Task-3084943: Event: Improve communication scheduler scalability
IoT devices can now automatically send their logs to the central server instead of requiring manual log file collection from customers. This improvement enables faster support troubleshooting by eliminating the need for customers to manually share IoT logs, and includes a toggle to enable or disable this feature from the Handlers configuration page.
Original PR description
Before this commit: IoT logs are kept in an IoT log file. Any time the support would need IoT log information, we are forced to ask the customer to send it to us as it requires to be in the LAN.…
Before this commit: IoT logs are kept in an IoT log file. Any time the support would need IoT log information, we are forced to ask the customer to send it to us as it requires to be in the LAN. After this commit: Relevant* log lines will be automatically send out to the server using an HTTP route. This feature can be toggled within the Handlers list page  preview:  *: Relevant = - Any odoo logs (depending on the level set in the handlers list, see: https://github.com/odoo/odoo/pull/134174 ) - Any other logs (werkzeug, python libraries, etc.) except /hw_proxy/hello Note: IoT logs received by the server will ALWAYS be logged regardless of it level. So an Odoo server set in INFO which receive a DEBUG log from the IoT will log it in its log with the DEBUG level Related enterprise PR: https://github.com/odoo/enterprise/pull/55055 opw-3696519 Forward-Port-Of: odoo/odoo#155944 Forward-Port-Of: odoo/odoo#150920
The Indian localization module now automatically fills in the PAN (Permanent Account Number) field when users enter a GST number, since the PAN is already embedded within the GST number. This eliminates duplicate data entry and reduces the chance of mismatches between the two fields, making the process faster and more accurate for Indian businesses.
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
This pull request updates the Account module with improvements to logos, login templates, and custom addons configuration. The changes include updates to multiple language translation files and module manifest, ensuring the accounting system is properly localized and branded across all supported languages.
Original PR description
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
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 update improves the performance of the Brazilian EDI module by fixing how certain features are calculated and displayed. The changes separate visibility logic from email field processing and remove unnecessary system triggers, resulting in faster and more efficient document handling without affecting user-facing functionality.
Original PR description
- Whether the option is visible or not shouldn't depend on the `mail_extra_fields` compute. Use a separate compute to avoid useless processing. - Wrong moves used in the warning computation. - Remove useless trigger in `api.depends` to avoid unecessary computations.
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 update corrects the positioning of the message that appears when marking timesheets as billable or non-billable in project tasks. The message was appearing in the wrong location due to an imprecise technical selector, which has now been fixed to display correctly.
Original PR description
Versions: --------- - 17.0 Issue: ------ Message for flag timesheet from project as billable/non-billable is misplaced. Cause: ------ Xpath given for Message placed in sale_timsheet is not very specific. Solution: --------- Give accurate xpath for message div. task-3630449
This update corrects the display order of company identification numbers in Czech Republic reports to match local standards. The Company ID (IČO) now appears before the VAT ID (DIČ), and the label has been clarified to "Company ID" for better clarity. This is a minor formatting adjustment to report templates with no impact on system functionality.
Original PR description
In Czech republic, the standard is to first render Company ID (IČO), and then to render VAT ID (DIČ). What I did in this commit is: - changing the position to before (not after), so company ID renders before VAT ID - I changed a label from ID to Company ID (so it is obvious in what ID it is) - This should not cause any harm, as we are just doing tiny changes in a view, not changing any logic. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects the display order of company identification fields on Czech invoices to comply with local standards. The Company ID (IČO) now appears before the VAT ID (DIČ), and the label has been clarified to "Company ID" for better clarity. This is a minor formatting adjustment to the invoice report template with no impact on business logic or data.
Original PR description
In Czech republic, the standard is to first render Company ID (IČO), and then to render VAT ID (DIČ). What I did in this commit is: changing the position to before (not after), so company ID renders before VAT ID I changed a label from ID to Company ID (so it is obvious in what ID it is) This should not cause any harm, as we are just doing tiny changes in a view, not changing any logic. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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 update fixes a test that was failing intermittently due to timing issues. The test now properly waits for WebSocket connections to be fully established before checking results, ensuring more reliable testing and fewer false failures in our quality assurance process.
Original PR description
Before this commit, the `test_websocket_instances_weak_set` was sometimes failing. Indeed, this test doesn't wait for the connection to be fully established before making its assertions. This commit fixes this issue. fixes runbot-55037,55035 Forward-Port-Of: odoo/odoo#157433
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 update fixes the display order of company identification numbers on Czech invoices to match local standards. Company ID (IČO) now appears before VAT ID (DIČ), and the label has been clarified from "ID" to "Company ID" for better clarity. This ensures invoices comply with Czech business practices.
Original PR description
In Czech republic, the standard is to first render Company ID (IČO), and then to render VAT ID (DIČ). - Changing the position to before (not after), so company ID renders before VAT ID. - Changed label from "ID" to "Company ID" (so it is obvious in what ID it is). Original fixes by @cunivca: odoo/odoo#149339, odoo/odoo#149340, merged into one. Related: https://github.com/odoo/odoo/commit/d0704a19de31e0251d343081ae6b3da9991a248e
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
Documentation and clarification updates
A contributor has signed the Odoo Individual Contributor License Agreement (CLA) on March 4, 2024. This is a standard legal requirement that allows Odoo to use contributions from community members while protecting both the contributor and the company.
Original PR description
Sign the Odoo CLA
A new contributor (hari1119) has signed the individual Contributor License Agreement (CLA) required to contribute to the Odoo project. This is a standard legal requirement that allows the contributor to submit code changes to the repository.
Original PR description
Signed a individual CLA
A contributor has signed the Odoo Contributor License Agreement (CLA), which is a legal requirement for all code contributions to the Odoo project. This signature confirms the contributor's agreement to the terms and conditions for submitting code to the repository.
Original PR description
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
A contributor has signed the Contributor License Agreement (CLA) required to contribute to Odoo. This is a standard legal requirement that allows the contributor to submit code changes to the Odoo project. The signature has been recorded in the CLA documentation.
Original PR description
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
A contributor (santiagopim) has signed the Odoo Contributor License Agreement (CLA), which is a legal requirement for all code contributions to the Odoo project. This enables the contributor to submit code changes to the repository going forward.
Original PR description
Description of the issue/feature this PR addresses: Sign CLA agreement for santiagopim Current behavior before PR: No CLA signed Desired behavior after PR is merged: CLA signed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr