Daily updates from Odoo
Navigate
Branch
Tuesday, October 1, 2024
222 changes
New functionality added to Odoo
Odoo now includes a new Just Eat integration through UrbanPiper for point-of-sale restaurant delivery operations. This helps businesses manage Just Eat orders more directly within their existing Odoo POS workflow, reducing manual handling across delivery channels.
Original PR description
After this commit: ========== A new pos_urban_piper_justeat module added to support Just Eat integration with Urbanpiper. task: 4191020
Odoo Point of Sale now includes a new module to connect Mrsool delivery through UrbanPiper. This helps businesses using Mrsool manage delivery orders more directly within their POS workflow.
Original PR description
After this commit: ================= A new pos_urban_piper_mrsool module added to support Mrsool integration with Urbanpiper. task: 4197030
A new Deliveroo integration module has been added for Odoo Point of Sale through UrbanPiper. This helps restaurants manage Deliveroo orders more directly from their existing POS workflow, reducing manual handling and supporting smoother delivery operations.
Original PR description
After this commit: ================= A new pos_urban_piper_deliveroo module added to support Deliveroo integration with Urbanpiper. Task-4190888
A new Glovo connector has been added for Point of Sale through UrbanPiper. This enables businesses using Odoo POS delivery integrations to include Glovo as an available delivery provider, expanding online ordering channel support.
Original PR description
After this commit: ================= A new pos_urban_piper_glovo module added to support Glovo integration with Urbanpiper. Task-4191056
A new module adds support for connecting NoonFood delivery orders through UrbanPiper in Odoo Point of Sale. This helps restaurants manage NoonFood as another delivery channel from within their existing POS workflow.
Original PR description
After this commit: ================= A new pos_urban_piper_noonfood module added to support NoonFood integration with Urbanpiper. Task-4190968
This update adds a new Talabat connection through UrbanPiper for point-of-sale delivery orders. It helps restaurants manage Talabat orders in Odoo and also avoids creating duplicate payment entries for the same order.
Original PR description
After this commit: ================= - A new pos_urban_piper_talabat module added to support Talabat integration with Urbanpiper. - prevent duplicate creation of payment line Task-4190314
A new Hungerstation integration is added for Point of Sale through UrbanPiper. This enables restaurants using Odoo to connect with Hungerstation delivery orders more directly, improving delivery channel coverage and order handling.
Original PR description
After this commit: ================= A new pos_urban_piper_hungerstation module added to support hungerstation integration with Urbanpiper. Task-4190877
A new Cari integration is now available through UrbanPiper for point of sale delivery operations. This expands the supported delivery provider options, helping businesses connect Cari orders into their existing Odoo POS workflow.
Original PR description
After this commit: ================= A new pos_urban_piper_cari module was added to support Cari integration with Urbanpiper. Task-4190934
This change adds a new Odoo module that connects point-of-sale delivery workflows with Grubhub through UrbanPiper. Businesses can expand supported online ordering channels and manage Grubhub orders through the existing UrbanPiper integration setup.
Original PR description
After this commit: ================= A new pos_urban_piper_grubhub module added to support Grubhub integration with Urbanpiper. Task-4190773
This adds a new ChowNow connector for Odoo Point of Sale through UrbanPiper. Businesses can use it to receive and manage ChowNow delivery orders alongside their existing POS delivery workflows.
Original PR description
After this commit: ==== A new pos_urban_piper_chownow module added to support ChowNow integration with Urbanpiper. Task-4190837
A new DoorDash integration module has been added for Point of Sale delivery operations through UrbanPiper. This enables businesses using UrbanPiper to connect DoorDash as a delivery provider, expanding delivery channel options from Odoo.
Original PR description
After this commit: ================= A new pos_urban_piper_doordash module was added to support Doordash integration with Urbanpiper. Task-4190787
Enhancements to existing features
The call action in mail discussions now turns green when users hover over it. This makes it clearer that selecting the button will immediately start a call, helping users avoid accidental actions.
Original PR description
This makes it more obvious that clicking on this button will start the call immediately, compared to all other thread actions that have a significantly lower level of commitment. 
Website pages and reusable building blocks now include clearer labels, image descriptions, and link text for search engines and assistive technologies. This helps improve page quality checks, accessibility compliance, and the experience for visitors using screen readers.
Original PR description
[IMP] http_routing, website: improve seo of website pages The goal of this commit is to improve the seo of website pages. To do so: - An `aria-label` has been added on generated iframe map. - The…
[IMP] http_routing, website: improve seo of website pages The goal of this commit is to improve the seo of website pages. To do so: - An `aria-label` has been added on generated iframe map. - The `role="img"` has been removed from the next icon of the carousel snippet to avoid an aria error of type `Uses ARIA roles on incompatible elements`. - Since [this commit] `alt=" "` has been added on images of the `image gallery` and `images wall` snippet. The idea was to force screen readers to not skip those images when describing the snippet. The problem is that it raises an accessibility error of type `Image elements do not have [alt] attributes`. They are so replaced by `alt=""` as those images are default images meant to be changed. - An aria label has been added on the facebook preview iframe. - An aria label has been added on anchors to avoid an error of type "Links do not have a discernible name". - An `aria-level` attribute has been added on elements with the "heading" role to follow the [heading role documentation]. - The `aria-label` attribute has been moved on elements with the `progressbar` role. - The `img` role has been removed from the 'next' icon of the "carousel intro" snippet. - An `aria-label` has been added on the carousel indicators. - An `alt` attribute has been added on images when missiging. - The link text of some anchors has been adapted in order to avoid an error of type "Links do not have descriptive text". Indeed, as per [the link text documentation], `more` is flagged as generic link text by the performance tool. [this commit]: https://github.com/odoo/odoo/commit/fb2296adec1fd151397da3b73ed882058f1ecdfc [heading role documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/heading_role [the link text documentation]: https://developer.chrome.com/docs/lighthouse/seo/link-text/?utm_source=lighthouse&utm_medium=devtoo task-3866469
The website theme switch flow now avoids showing preview screens that may contain outdated theme images. This helps users avoid confusion while Odoo continues to rely on the main website configurator, which provides up-to-date personalized previews.
Original PR description
The theme previews on `themes.odoo.com` website are not up-to-date. While waiting for them, skipping the preview screen if you were to reach the switch theme screen (it is not the main flow: using the configurator the preview is a SVG with user-related colors, text and images and those are up-to-date).
The website page creation dialog now has a simpler, more consistent design by removing an unnecessary template button and aligning its interaction elements with the snippet library modal. The blank page option also has a more polished placeholder, improving the page setup experience for website editors.
Original PR description
This PR removes the unnecessary "Use this template" button and refines interaction elements' design in order to achieve a visual result consistent with the snippet-library modal. It also slightly improve the "Blank Page" placeholder for a better visual result. task-4224057 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Dashboard JSON files can no longer be downloaded from list views in debug mode when the file may not reflect the latest dashboard revisions. Users now see a warning instead, helping avoid confusion or use of outdated dashboard data.
Original PR description
When downloading a dashboard's json file in debug mode, we get the initial version of the dashboard file and not the latest (without the revisions). This commit's goal is to prevent downloading the dashboard's json file and displaying a warning message to the user. task-4196930 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Accounting users can now create and manage shared accounts across multiple companies more smoothly, including setting company-specific account codes from the start. The update also improves visibility and controls around company mappings and makes it easier to split shared accounts when users have the right access.
Original PR description
- We provide a default value for the account code/company mapping at the initial onchange, meaning the user can create an account with multiple companies and codes from the start. - We make the mapping visible for all of the user's companies. We make it invisible if the user only has access to one company. - We make the `companies` field read-only in the accounts list view. - We don't prevent the user from unmerging accounts if they have access to all the account's companies, even if all the companies aren't selected in the company selector. - We let users unmerge several accounts that are selected in the CoA list view. task-4191362
The manufacturing overview now shows work center workload based on each work order’s own planned start date. This gives planners a more accurate weekly view when one manufacturing order spans multiple weeks, helping them better assess capacity and scheduling needs.
Original PR description
This commit improves the accuracy of the workcenters load graph shown in the overview page of MRP module. Previously, if the workorders of a manufacturing order were planned over different weeks, they were all shown as a part of the load of the first week of the manufacturing order. After this commit, the start date of each workorder is considered, and not necissariy linked to the start date of the manufacturing order if the order is planned. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes dropdown and sortable column indicators easier to see and better positioned when text is crowded. Users benefit from clearer visual cues while navigating autocomplete fields and list views, with small usability improvements in accounting and general web screens.
Original PR description
This PR improves various carets of the autocomplete dropdown and the list view sortable columns. It improves it's visibility and saves space when it overlaps with text. Task: [4170216](https://www.odoo.com/odoo/project/133/tasks/4170216) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Warehouse dispatch batches now better support dock and vehicle planning, with smarter dock selection and clearer scheduling views. Putaway rules are also easier to adjust for storage categories, helping teams manage warehouse flows with less manual correction.
Original PR description
Enterprise PR: odoo/enterprise#70099 Task-4173210 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The HTML editor’s command search now supports extra keywords, making relevant tools easier to find. Users can type “AI” to quickly access the ChatGPT command, reducing friction when using AI writing assistance.
Original PR description
[IMP] html_editor: search keywords for powerbox commands [IMP] html_editor: AI as alias to ChatGPT command task-4207516
Users now go directly to event registration desk and attendance kiosk screens without an extra pop-up step. The relevant screens also include an install button, making setup easier and reducing friction for front-desk and attendance workflows.
Original PR description
**Specifications:** Events - remove modal when user click on registration desk and directly open desk view. - Add an Install button in desk view Attendance - remove modal when user click on kiosk mode and directly open kiosk view. - add an install button in kiosk view **After this PR:** Modals will be removed while opening kiosk mode in respective modules. Task-4161336
Dashboard JSON files can no longer be downloaded from list views in debug mode because those files may show outdated dashboard content. Users now receive a warning instead, reducing confusion and preventing reliance on incomplete dashboard versions.
Original PR description
When downloading a dashboard's json file in debug mode, we get the initial version of the dashboard file and not the latest (without the revisions). This commit's goal is to prevent downloading the dashboard's json file and displaying a warning message to the user. task-4196930
Resolved issues and error corrections
This fixes a visual flicker on status icons when users hover over items in the compact Discuss sidebar. The change makes the interface feel steadier and more polished without changing any workflow or functionality.
Original PR description
Mouse-hovering items when discuss sidebar is compact result in some style flickering on im status icon. This happens because the items are button and they need `bg-inherit`. Due to CSS specificity, however, the classname is not enough, so we need `!important` in CSS, which is what this commit does to fix the issue. Before / After (see status of 3 items at the bottom while mouse-hovering)  
Website editors can now drag blocks near the bottom of a long page and have the page scroll as expected. This restores smoother page editing when building longer website pages.
Original PR description
Steps to reproduce the bug: - In website edit mode. - Add enough blocks to the page so that a vertical scrollbar appears. - Drag a block and move it to the bottom of the page to scroll down. - Bug:…
Steps to reproduce the bug: - In website edit mode. - Add enough blocks to the page so that a vertical scrollbar appears. - Drag a block and move it to the bottom of the page to scroll down. - Bug: The page does not scroll. This bug was introduced because the scroll element is now the `<html>` instead of the "#wrapwrap" element (Since this commit [1]). The issue arises because "getBoundingClientRect()" gives the distance from the top of the element to the viewport, excluding the scroll position, while the `<html>` element accounts for scrollTop to define its Y position. In this commit, we also fixed the "dragStart" function, which didn't return the HTML element as the scroll element when it was the drag and drop container. The issue is that the "closestScrollableY" function don't consider an element with "overflow: visible" as scrollable. At first, we tried to modify "closestScrollableY" to consider an element with "overflow: visible" as scrollable, but this caused several errors in the "drag and drop" QUnit tests and we couldn't find the cause. This needs further investigation. To fix the issue, we updated the "dragStart" function to check if the "drag and drop" container is the "ownerDocument.scrollingElement". If it is, we use that element as the scrollable element for the "drag and drop". [1]: https://github.com/odoo/odoo/commit/189a7c96e6e26825dc05c0c6466576fe63aa091e task-4190506
Opening the Dashboard app no longer triggers an access error for newly created non-admin users. This ensures users without administrator rights can access dashboards as expected in a fresh database.
Original PR description
Steps to reproduce - install a fresh database, without any demo data - create a new user which shouldn't have admin rights - connect as this new user - open the Dashboard app => Access Error The `ir.model` cannot be read by anyone, except admin users. Task: 4224689 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resetting a payment to draft now also resets its linked journal entry, and deleting a payment removes the linked journal entry too. This prevents orphaned accounting entries and keeps payment records synchronized with the accounting ledger.
Original PR description
Reset to Draft and Payment deletion should impact the linked Journal Entry as well, or we'll just leave a bunch of created entries that will be lost in Accounting. Reset it to draft => Reset to Draft the Journal entry as well, no error message. Delete the payment => Delete the Journal entry We also revert the suppression of the synchronisation of the payment to move. And in the _get_trigger_fields_to_synchronize we remove is_internal_transfer since the field is no longer there. (https://github.com/odoo/odoo/commit/01b87f1230beac0568f4e3b1b76e547909506892) task: https://github.com/odoo-dev/odoo/commit/4215217583c566cc5188d71dcbbd7b1cd860b3ae --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website page properties menu no longer shows a publishing option that could make pages appear unpublished while still leaving them in the sitemap. This avoids misleading website managers until a more reliable solution is available.
Original PR description
Commit [1] introduced the possibility to publish/unpublish "any route" by using the visibility and groups fields available on the rendered view. This obviously had its limitations, indeed the route…
Commit [1] introduced the possibility to publish/unpublish "any route" by using the visibility and groups fields available on the rendered view. This obviously had its limitations, indeed the route and the view are independent (e.g. a same URL could lead to different views depending on values in the database for example) but allowing to "unpublish" the "current rendered page the user is seeing" seemed like a good first improvement anyway. However, the sitemap was forgotten... and it is proving difficult to fix in a way that makes sense. It would mean saving the info of the URL that was used to reach the "unpublished" *view* in the first place somehow somewhere... and if it were to be possible, controllers with parameters, or controllers that lead to different views depending on some configuration would really be a problem. We choose to disable the feature for now (keeping its code but just not showing the possibility via the UI). We will revisit this later. In the end [2] added the possibility to properly "unpublish the whole shop" (not just one page), which is the main demand when it comes to unpublishing controllers (funny enough, the sitemap was also forgotten for that feature, before fixes [3] and [4]). [1]: https://github.com/odoo/odoo/commit/e3b1ff6e25ecc71c9242d3826cee09c636bc465a [2]: https://github.com/odoo/odoo/commit/5bde2e42c8ec5e943a779ad4b3e1b7142f2d2fcf [3]: https://github.com/odoo/odoo/commit/0738e0210207397429826ab3c4b3760b3a4dff44 [4]: https://github.com/odoo/odoo/commit/eb14c1f401d5d09a1d906346a4a4cd494bb47628
Fixes issues in the website page properties dialog so users can clone or delete pages successfully. It also makes redirect options appear immediately when editing a page URL, reducing confusion during website page setup.
Original PR description
Moved out of https://github.com/odoo/odoo/pull/181224
The Discuss sidebar call icon now has better spacing when displayed with a border. This small visual fix makes the interface look cleaner and easier to scan for users.
Original PR description
Before / After <img width="296" alt="Screenshot 2024-10-01 at 16 26 22" src="https://github.com/user-attachments/assets/b7b23378-b778-4610-ba8d-83f3219e7234"> <img width="299" alt="Screenshot 2024-10-01 at 16 25 57" src="https://github.com/user-attachments/assets/08cf20af-fb75-4ddf-ae25-3d5f5d1c241a">
This fixes an issue in Point of Sale where floating orders were not listed alphabetically by their assigned names. The system now uses the current order name field, making it easier for staff to find and manage multiple open orders.
Original PR description
Steps to reproduce : -------------------------- - Install the point_of_sale module. - Place orders on two or more floating orders. - Give the orders some name. Issue : --------- The floating orders are not sorted according to alphabet properly. Cause : ---------- The field containg floating order name is changed but, at this place still try to sequence by old name. [Referance PR](https://github.com/odoo/odoo/pull/175535) Fix : ----- Now updated the field name properly from note to floating_order_name.
The HTML editor no longer shows advanced text style options that are not currently supported in the website builder. This reduces confusion by hiding controls that are not relevant until the website builder moves to the new editor.
Original PR description
Currently, showExtendedTextStylesOptions are still displayed. Before the new editor (html_editor), it was only used by the website builder. The website builder still doesn't use html_editor, so we're going to disable them. We'll reintroduce them when the website builder uses html_editor. 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
Manufacturing orders now correctly treat BOM lines linked to an operation as manually consumed components. This prevents materials from being consumed automatically when an operation-specific component should be handled manually, improving production accuracy.
Original PR description
When an operation is added to a BOM line, it will be treated as a manual consumption component. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Purchase quotation accept and decline actions now consistently use the same secure portal flow, whether users click from an email or the portal sidebar. This prevents sidebar actions from failing and makes the confirmation feedback clearer for users.
Original PR description
There is two ways of confirming/declining a reception mail through the portal. Either by clicking on the sidebar or clicking on the button in the mail. While it works correctly when going through the mail link, as it goes through the controller that checks the access rights before preparing the order if the access token is good. However this didn't happen when using the buttons from the portal sidebar, as we don't go through the controller in this case. Unified both ways to always go to the controller. Also changed the feedback for accepted/declined quotations, so that's more visible for the user. Task-4207380 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website editor building blocks now have more accurate keywords, making it easier for users to find the right content elements. Keywords that are no longer useful after the sidebar search removal were also cleaned up, reducing maintenance noise without changing business workflows.
Original PR description
This PR updatsd snippets keywords ensuring they accurately reflect the associated content. It also removes inline-snippets' keywords' because, following the removal of the sidebar's search, these are no longer necessary. task-4063510 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Starting an onboarding tour from a direct URL now correctly loads its step-by-step guidance. This prevents users from seeing an incomplete tour and helps onboarding flows work as expected.
Original PR description
When starting tour by url, if the tour was an onboarding tour (info in db and steps in registry), the steps were missing. Now, if the steps are missing, I search them in the registry. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update streamlines several automated walkthrough tests by removing repeated or unnecessary actions and reducing waiting time between checks. It helps the test suite run faster and more reliably without changing business features or user workflows.
Original PR description
In this commit, we : - Remove redondant steps (multiple click on the same element) - Remove unuseful clicks (default action is now "nothing") - Impose checkDelay so that tours go faster (checkDelay is 750ms by default)
Sale orders created from completed repair orders now carry over the actual quantity completed in the repair. This ensures customers and staff see accurate delivered quantities when confirming those sale orders.
Original PR description
Steps to reproduce: - Create a repair order. - Add a stock move to it with any quantity. - Confirm, start and end the repair order. Make sure that quantity done is positive. - Generate a sale order from the repair order. - Confirm the sale order. Expected result: `qty_delivered` of the generated sale order line should be the same as the quantity done of the move in the repair order. Current result: `qty_delivered` is zero. 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
This fix ensures tax totals stay accurate when a currency's rounding settings have been changed. It also corrects price-included reverse charge tax calculations, reducing small invoice discrepancies that could affect accounting totals.
Original PR description
The test was computing: 20000 * 2.82 / 1.1726 = 48098.24 48098.24 * 0.21 ~= 10100.63 When splitting to tax repartition lines, we get 10100.65 because of the rounding set on the currency. The error is computed as 10100.63 - 10100.65 = -0.02 so 2 x -0.01 to distribute. Before this commit, we had the time to fix only one rounding error so: 10100.65 - 0.01 = 10100.64 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The dashboard edit option is now only provided by the edition module that supports it. This prevents users from seeing an error when opening a dashboard in installations that do not include the editing add-on.
Original PR description
Steps to reproduce: - Install spreadsheet_dashboard without spreadsheet_dashboard_edition - Go to a dashboard - Click on the edit button => Traceback This commit moves the edit button to the right module (spreadsheet_dashboard_edition). Note that to avoid overriding DashboardAction (component, template and entry in the registry), we introduce a new registry with the aim to contains the edit button. 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
This update fixes how tax totals appear on invoice PDFs and corrects related tax total handling for Hungary. It also makes global rounding the default for Mexican localization, helping invoices follow local expectations more consistently.
Original PR description
[FIX] account: Fix wrong condition to display tax_totals on PDF [IMP] l10n_mx: round_globally in mexico by default Now the round globally is fully managed, let's enforce it in Mexico. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Project and timesheet task cards now display footer details more neatly. Assignee names are shortened when space is limited, the remaining-hours indicator blends better with the page, and outdated styling was removed for a more consistent look.
Original PR description
**Before this commit:** - The assignee's name would overflow instead of truncating in the footer. - The remaining hour's widget displayed an unusual grey background. - classes with the prefix `oe_` were present for styling. **After this commit:** - The assignee's name will now truncate after a specific width in the footer. - The remaining hour's widget has a transparent background. - removed class `oe_kanban_align` from the code base. Task-4207390
Website dynamic snippets now keep a balanced layout when they show only one item, such as a product or appointment. This prevents the item from stretching too wide or becoming overly tall, improving page appearance and readability.
Original PR description
Prior to this this commit, when a single element was fetched in the dynamic snippet, it took the entire width and became too tall according to the page height. (e.g. Products or Appointments snippet) To limit the height of this snippet, this commit forces the same size to be used as when two elements are fetched. task-4215773 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Using the Manufacture button from a Bill of Materials overview now creates a manufacturing order without incorrectly moving serial-numbered products into an in-progress state. This keeps the workflow consistent with creating a manufacturing order manually and then selecting the same Bill of Materials.
Original PR description
The Manufacture button added in the BoM Overview prepares a new manufacturing order using the bom. However for serial products this has a drawback of changing the state to 'in progress'. This is not the case when creating a new manufacturing order and then selecting the same bom. The origin is within '_onchange_producing / _set_qty_producing' and the way the record is initialized: - from 'Manufacturing orders / New' all fields have their default values - from 'BoM Overview / Manufacture' the bom_id and related fields are set. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The table editing menu now includes the missing Reset Size option again. This helps users quickly return tables to their default sizing after editing, improving consistency in content editing.
Original PR description
The Goal of this commit is to add the “Reset Size” table menu item that had been omitted during conversion to html_editor.
This change fixes how saved text is loaded into forum and profile text areas. It avoids an extra server lookup, helping these pages show existing content more reliably and efficiently.
Original PR description
This is a partial revert of [1] and proposition of another solution. Instead of doing an extra orm call we just add the content as attribute to the textarea and retrieve it directly from there. opw-4148163 [1]: https://github.com/odoo/odoo/commit/82fbc0c30848763d6a55d4e5e78b0b34ff6c8245
This fix makes the editor's command search close properly when users press Escape. It prevents the search panel from unexpectedly reopening when the user continues typing, making text editing smoother and less confusing.
Original PR description
Before this commit, pressing “escape” when the powerbox is open did not stop the current search. Adding a new character reopened it. 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
This fixes the Time Off accrual plan view so the carry-over validity value is no longer shown when no validity period is configured. It reduces confusion for HR users by only displaying relevant leave policy information.
Original PR description
in this commit, fixes a issue where carry over validity isn't set value is still visible in view. task-4207945 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
This update corrects how expected working hours are recalculated when overtime records are updated. It helps keep attendance and overtime figures accurate for employees and payroll-related reviews.
Original PR description
Expected hours were not recomputed properly on the _update_overtime method
This fixes a display issue in Frontdesk kiosk mode where the landing page did not fill the full browser window. The change improves the visitor check-in experience by making the kiosk screen look complete and consistent.
Original PR description
This PR addresses a styling issue in the kiosk mode of Frontdesk. Before this pr, the landing page would not fill the height of the window causing the whole user experience to be strange. task-4213241
This fixes an issue where links to employee documents were missing or incorrect in HR document communications. Employees and HR teams can now access the intended documents more reliably from the related messages or pages.
Original PR description
We forgot to add the field. We'll go for a model method in this fix, this can be cleaned to a field in master. Task-4216195
Copying previous weeks in Planning now handles open shifts without errors, including shifts spanning multiple days. Shifts outside an employee's normal schedule are copied as open shifts unless the employee is fully flexible, making schedule duplication more predictable.
Original PR description
Before this commit, when the user copy shifts of the previous weeks and in that previous week he has an open shift, he will have a traceback will be raised because we check if the resource of the shift is flexible or not to be able to correctly compute the allocated hours of the splits generated with the split to split. The problem is an open shift has no resource so it is no needed to check if the resource is flexible. This commit checks if the shift is an open shift or not before checking if the resource is flexible or not. This commit also fixes another when we try to copy previous an open shift planned during 2 days, the allocate hours is computed based on the company schedule instead of the real time span between the date end and date start as we do in the `_compute_allocated_hours` method. task-4207839
This update corrects tax total display on Ecuador withholding PDFs and stabilizes Mexico electronic invoicing tests so they are no longer affected by date changes or recent merges. It also makes global rounding the default for Mexico, improving consistency with local invoicing requirements.
Original PR description
[FIX] l10n_ec_edi: Fix wrong condition to display tax totals in PDF [FIX] l10n_mx_edi: Fix broken test after merge: The fix has been added by https://github.com/odoo/enterprise/commit/d5da2b62263f85fbce0f2548085c066cbbf10371 At the same time, this commit has been merged: https://github.com/odoo/enterprise/commit/00cc171c6e122118af72d84bb26ff083c086dff4 Now those tests are skipped on runbot. Let's fix them. [FIX] l10n_mx_edi: Remove date related stuff from MX test files Now we move to october, the test is failing on runbot... [IMP] l10n_mx: round_globally in mexico by default Now the round globally is fully managed, let's enforce it in Mexico.
The dashboard edit button has been moved into the updated dashboard controls so it appears where users expect it. This keeps spreadsheet dashboard editing available after related interface changes, reducing confusion for users who manage dashboards.
Original PR description
This commit is the counterpart of https://github.com/odoo/odoo/pull/182079 and add the edit button to the newly introduced registry.
Sales order spreadsheets now leave out section headers and notes from line item lists, avoiding confusing or poorly formatted rows. The list is also inserted with table styling again, making spreadsheet views clearer and easier to read.
Original PR description
Sections and notes in the SO are badly displayed in the sale order line list in the spreadsheet. They should be excluded from the list (domain on display type). (or maybe later, change the default list fields to make it pretty somehow?) Task: 4200539
The report editor's table menu now disappears again when the pointer moves away, matching the previous expected behavior. It also closes during scrolling, reducing visual clutter and preventing the menu from staying open at the wrong time.
Original PR description
Since PR odoo/enterprise#181141, when a qweb table menu is displayed, it no longer disappears when the pointer moves outside it. This commit will reintroduce the old behavior: - When the pointer quits a closed qweb table menu, we make it disappear. - When the pointer leaves an open qweb table menu, it doesn't disappear. You need to do a pointerdown to make it disappear. We'll also add a close to the qweb table menu when scrolling. This will have the same behavior as the table menu.
Fixes issues in Odoo Studio where editing Kanban cards after adding a card menu could target the wrong part of the card. It also places ribbon elements correctly so card layouts remain visually intact, making customization safer and more predictable for users.
Original PR description
Before this commit there were two issues: - add a menu on a card - try to remove or add a field elsewhere in the card => the xpath of the last operation was always wrong. This was because the normlalise function got confused and refused to actually add the menu template before the card template. - web_ribbon was appended to the card => this cause the style to be broken. Albeit the ribbon widget makes sense at the top of the card template, it should not break the style in those proportions. So, a small fix is done in studio to add the ribbon at the top of the card, but we strongly recommend a fix that will enable to put it anywhere as a direct child of the relevant view node. task-4207793
This update cleans up and speeds up several automated test tours used to verify key workflows in Knowledge, Rental product configuration, and Web Studio. It helps reduce unnecessary test steps and makes validation faster and more reliable without changing customer-facing features.
The accounting reports quarter filter now calculates periods based on actual calendar quarters instead of counting three-month ranges from the current date. This helps users see accurate quarterly report data and reduces the risk of misleading financial analysis.
Original PR description
The quarter filter was not properly calculating the quarters. It was taking periods of 3 months not based on quarter but based on the current date. The months are now properly calculated based on the quarter.
This fix prevents the Documents accounting flow from creating unnecessary empty accounting entries when determining the right journal. It reduces clutter and helps keep accounting records cleaner without changing the intended user workflow.
Original PR description
We don't need to create an empty move to compute the suitable journal_id. Task-4216195
Portal users can now search or group helpdesk tickets by related sales orders without running into an access rights error. This removes an unnecessary restriction so customers have a smoother self-service support experience.
Original PR description
Prior to the fix, portal users would get an access rights error whenever they would group or search sale order. That was because the ``sale_order_id`` field was only given access to sale and accounting users. That was the case since the helpdesk app was first created. All users, including portal, have access to the ``sale_order_line`` field, thus the restriction on the ``sale_order_id`` field are not anymore necessary. We "fix" the access right error by basically removing the group restriction on the ``sale_order_id`` field in the helpdesk.ticket model. task-4207628
The Documents app no longer automatically applies the filter that hides shortcuts in search results. This reduces confusion by showing users a more complete and expected view of their documents unless they choose otherwise.
Original PR description
It's more confusing than helpful to enable the filter automatically. Task-4216195
Code cleanup and technical improvements
The HTML editor’s internal plugin resource system was simplified so developers can define and access shared editor resources more consistently. This is an internal refactor that should make future editor maintenance easier without changing day-to-day user behavior.
Original PR description
This commit change the resource API for the plugins in 3 ways. # 1) The disposal of resources Instead of ```js class MyPlugin extends Plugin { /** @type { (p: MyPlugin) => Record<string, any> } */…
This commit change the resource API for the plugins in 3 ways.
# 1) The disposal of resources
Instead of
```js
class MyPlugin extends Plugin {
/** @type { (p: MyPlugin) => Record<string, any> } */
static resources = (p) => ({
my_handlers: p.handler.bind(p)
})
}
```
We now have
```js
class MyPlugin extends Plugin {
resources = {
my_handlers: this.handler.bind(this)
}
}
```
# 2) Resource getter
To access a specific resource within a plugin, instead of
```js
this.resources['my_handler']
```
We now have
```js
this.getResource('my_handler')
```
If no other plugin disposed the specified resource, the getter will return an empty array.
# 3) Sequences for all resources
This commit give the ability to specify a sequence for any resource item, removing the need for the consumer of the resource to have to setup it.
Instead of
```js
class MyPluginA extends Plugin {
resources = {
my_handlers: {handler: this.handler.bind(this), sequence: 100}
my_data: {id: 'some-id', sequence: 100}
}
}
class MyPluginB extends Plugin {
constructor() {
this.handlers = this.getResource('my_handlers')
.sort((a, b) => a.sequence - b.sequence)
}
myMethod() {
for (const {handler} of this.myHandlers) {
handler();
}
}
}
```
We now have
```js
class MyPluginA extends Plugin {
resources = {
my_handlers: withSequence(100, this.handler.bind(this)),
my_data: withSequence(100, {id: 'some-id'}),
}
}
class MyPluginB extends Plugin {
myMethod() {
for (const handler of this.getResource('my_handlers')) {
handler();
}
}
}
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prEditor dialogs now share a common way to restore the user's cursor or selection after the dialog closes. This reduces duplicated logic and helps make editing interactions more reliable across features such as media and AI-assisted content dialogs.
Original PR description
The purpose of this commit is to add a dialog plugin that will centralise the behaviour shared between dialogs opened from the editor. The behaviour shared by all the editor dialogs is the repositioning of the selection in the editable when a dialog closes. 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
The editor plugin resource API was updated to stay aligned with related platform changes. This is an internal cleanup that helps appointment and knowledge editor features remain maintainable without changing day-to-day user workflows.
Original PR description
This commit adapt the api of plugin resources to match the changes made in community.
Miscellaneous changes
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#180755
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 Forward-Port-Of: odoo/odoo#180755
Overriding the _compute_field_value in order to only prefetch the currently requested field. opw-4213262 Forward-Port-Of: odoo/odoo#181855 Forward-Port-Of: odoo/odoo#181534
Original PR description
Overriding the _compute_field_value in order to only prefetch the currently requested field. opw-4213262 Forward-Port-Of: odoo/odoo#181855 Forward-Port-Of: odoo/odoo#181534
Steps to reproduce: 1. Install the `sale_project` module. 2. Create a product with the following properties: - Type: 'Service' - Create on Order: 'Project & Task' 4. Create a sale order and add the product to it. 5. Confirm the sale order. 6. In another tab, change the product type to 'Consumable' in the product form (a popup will appear informing you that you cannot change the type, but it can be dismissed.) The issue arises because the 'Project' smart button remains visible
Original PR description
Steps to reproduce:
1. Install the `sale_project` module.
2. Create a product with the following properties:
- Type: 'Service'
- Create on Order: 'Project & Task'
4. Create a sale order and add the product to it.
5. Confirm the sale order.
6. In another tab, change the product type to 'Consumable' in the product form (a popup will appear informing you that you cannot change the type, but it can be dismissed.)
The issue arises because the 'Project' smart button remains visible in the sale order tab until the page is reloaded, and there are no longer any order lines with a product of type 'Service', resulting in a StopIteration error.
Closes #180340
Forward-Port-Of: odoo/odoo#182235
Forward-Port-Of: odoo/odoo#181946**Steps to reproduce the bug:** - Create a storable product "P1". - Go to the Purchase tab > add a vendor. - Create an order point: - Min qty: 10 - Trigger: Auto - Result > the quantity to order is updated to 10. - Create a delivery with one unit of P1. - Mark the delivery as 'To Do'. **Problem:** A purchase order is created with 10 units of P1 instead of 11. **Explanation:** When the minimum quantity is set to 10, the `_compute_qty_to_order` method is triggere
Original PR description
**Steps to reproduce the bug:** - Create a storable product "P1". - Go to the Purchase tab > add a vendor. - Create an order point: - Min qty: 10 - Trigger: Auto - Result > the quantity to order is…
**Steps to reproduce the bug:**
- Create a storable product "P1".
- Go to the Purchase tab > add a vendor.
- Create an order point:
- Min qty: 10
- Trigger: Auto
- Result > the quantity to order is updated to 10.
- Create a delivery with one unit of P1.
- Mark the delivery as 'To Do'.
**Problem:**
A purchase order is created with 10 units of P1 instead of 11.
**Explanation:**
When the minimum quantity is set to 10, the `_compute_qty_to_order` method is triggered. Since the `qty_to_order_manual` is 0, the `qty_to_order_computed` is using so computed with `_compute_qty_to_order_computed` and assigned to `qty_to_order`:
https://github.com/odoo/odoo/blob/156bed3f430d706e13822bbd95d91c8dfd3ea42d/addons/stock/models/stock_orderpoint.py#L274-L277
https://github.com/odoo/odoo/blob/156bed3f430d706e13822bbd95d91c8dfd3ea42d/addons/stock/models/stock_orderpoint.py#L292
Subsequently, the inverse method is triggered, and the value of `qty_to_order` is set in `qty_to_order_manual`:
https://github.com/odoo/odoo/blob/156bed3f430d706e13822bbd95d91c8dfd3ea42d/addons/stock/models/stock_orderpoint.py#L279-L281
Thus, when the delivery is confirmed, `_compute_qty_to_order` is called again. However, this time, as `qty_to_order_manual` is already set, its value is used instead of recalculating a new value using `_compute_qty_to_order_computed`.
opw-4150572
Forward-Port-Of: odoo/odoo#180951### Steps to reproduce: - Enable Multi-Step Routes - Inventory > Configuration > Warehouse Management > Warehouses - Change your warehouse settings to Manufacturing in 2 steps - Create a product P tracked by serial number with a BOM: - 1 x COMP (a storable product with 10 units in stock) - Create and confirm an MO for 10 units of P - Validate the delivery from stock to pre-production - Click on `Mass Produce` > `Generate` only 7 SN - Click No back order (split and generate only 7 MO's)
Original PR description
### Steps to reproduce: - Enable Multi-Step Routes - Inventory > Configuration > Warehouse Management > Warehouses - Change your warehouse settings to Manufacturing in 2 steps - Create a product P…
### Steps to reproduce: - Enable Multi-Step Routes - Inventory > Configuration > Warehouse Management > Warehouses - Change your warehouse settings to Manufacturing in 2 steps - Create a product P tracked by serial number with a BOM: - 1 x COMP (a storable product with 10 units in stock) - Create and confirm an MO for 10 units of P - Validate the delivery from stock to pre-production - Click on `Mass Produce` > `Generate` only 7 SN - Click No back order (split and generate only 7 MO's) #### > Looking at the quant of the product you see that 0 units are reserved in pre-production but 7 should be - validate one of the 7 MO #### > Looking at the quant of the product you see that -1 units are reserved in pre-production but 6 should be ### Cause of the issue: By processing the "Mass produce" wizzard you will call the `_assign_serial_numbers` method and hence the `split_productions`: https://github.com/odoo/odoo/blob/af4055e2ccce399f94bc465e2dd529c9f14953e0/addons/mrp/wizard/stock_assign_serial_numbers.py#L65-L68 During this `split_productions` call, the quant reserved quantity will be updated by these lines: https://github.com/odoo/odoo/blob/af4055e2ccce399f94bc465e2dd529c9f14953e0/addons/mrp/models/mrp_production.py#L1931-L1938 However, since the stock pocalypse, the quant is already updated once you write and change the quantity of the stock move line of the raw move of the inital MO because of these lines: https://github.com/odoo/odoo/blob/af4055e2ccce399f94bc465e2dd529c9f14953e0/addons/stock/models/stock_move_line.py#L437-L439 Hence, the `stock.quant` reserved quantity will end up to be updated twice opw-4145680 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181864 Forward-Port-Of: odoo/odoo#181255
### Steps to reproduce: - Create a product P tracked by serial number with a BOM: - 1 x COMP (a storable prodcut that you do not have in stock) - Create and confirm an MO for 10 units of P - Click on the [+] button to generate one serial number of P > This steps updates the qty_producting to 1 and the set the consumed_qty of the raw move to 1. - Click on `Mass Produce` > `Generate` > Apply (to generate the remaining SN) > This generates 9 backorders each for 1 unit of P with a set SN ###
Original PR description
### Steps to reproduce: - Create a product P tracked by serial number with a BOM: - 1 x COMP (a storable prodcut that you do not have in stock) - Create and confirm an MO for 10 units of P - Click on…
### Steps to reproduce: - Create a product P tracked by serial number with a BOM: - 1 x COMP (a storable prodcut that you do not have in stock) - Create and confirm an MO for 10 units of P - Click on the [+] button to generate one serial number of P > This steps updates the qty_producting to 1 and the set the consumed_qty of the raw move to 1. - Click on `Mass Produce` > `Generate` > Apply (to generate the remaining SN) > This generates 9 backorders each for 1 unit of P with a set SN #### > However raw moves are **picked with a consumed_qty of 0** ### Cause of the issue: Since the stockpocalypse commit 7dda6bb the `_split_productions` did not consume quantities anymore. This behavior was fixed by commit 4be8cac for mass production notably by the addittion of these lines: https://github.com/odoo/odoo/blob/6995d65437ba6b2cd0df7503d589260bedcce67d/addons/mrp/models/mrp_production.py#L1879-L1887 However, in our flow, when we assigned the firt serial number by clicking on the [+] button we had set the quantity of the `initial_move` to 1 and associated a `move_line` with the corresponding quantity to it. As such, none of the move line of the raw moves of the back order is going to be created and the issue remains. opw-4119702 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182216 Forward-Port-Of: odoo/odoo#179062
The condition that dictates whether or not the product warning is shown in the product list in pos is inverted. This means that we currently show the product warning when it's not the case. Steps to reproduce: 1. On a db without self order installed, open a pos; 2. Observe that the "info" tags on the corners of the product cards are red; Task: 4214248 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181668
Original PR description
The condition that dictates whether or not the product warning is shown in the product list in pos is inverted. This means that we currently show the product warning when it's not the case. Steps to reproduce: 1. On a db without self order installed, open a pos; 2. Observe that the "info" tags on the corners of the product cards are red; Task: 4214248 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181668
When overtime is converted to time off, an hr.attendance.overtime record is created with a negative amount to offset the total overtime amount available with adjustment set to True. Those records should not be taking into account when computing overtime itself. Forward-Port-Of: odoo/odoo#181701
Original PR description
When overtime is converted to time off, an hr.attendance.overtime record is created with a negative amount to offset the total overtime amount available with adjustment set to True. Those records should not be taking into account when computing overtime itself. Forward-Port-Of: odoo/odoo#181701
**Steps to reproduce:** - Install Accounting - Go to Accounting settings - Set "Quick encoding" to "Customer Invoices and Vendor Bills" - Create an invoice - Set "Total (Tax inc.)" to any value - Add a section and a note - Check Journal Items **Issue:** A tax is set on the section and the note lines. opw-4204583 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181519
Original PR description
**Steps to reproduce:** - Install Accounting - Go to Accounting settings - Set "Quick encoding" to "Customer Invoices and Vendor Bills" - Create an invoice - Set "Total (Tax inc.)" to any value - Add a section and a note - Check Journal Items **Issue:** A tax is set on the section and the note lines. opw-4204583 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181519
Steps: - Install `web_studio` - Open studio - Go to Reports - Create or edit an existing report - Add some text and try to change its size - Preview will display the right size but printed pdf ignores it `wkhtmltopdf` uses an old version of Webkit which doesn't support CSS3. Since 17.0 we use the new html_editor in our report editor but it uses `display-x-fs` (x is an int from 1 to 4). ```css .display-2-fs { font-size: calc(1.575rem + 3.9vw); }
Original PR description
Steps:
- Install `web_studio`
- Open studio
- Go to Reports
- Create or edit an existing report
- Add some text and try to change its size
- Preview will display the right size but printed
pdf ignores it
`wkhtmltopdf` uses an old version of Webkit which doesn't support CSS3. Since 17.0 we use the new html_editor in our report editor but it uses `display-x-fs` (x is an int from 1 to 4).
```css
.display-2-fs {
font-size: calc(1.575rem + 3.9vw);
}
```
The problem with this class is the 'calc', which is not supported by the old Webkit version.
see https://github.com/odoo/odoo/issues/136360
https://github.com/wkhtmltopdf/wkhtmltopdf/issues/4092
One solution would be to use the old (hardcoded) bootstrap 4 values in the reports.
opw-3894005
Forward-Port-Of: odoo/odoo#181756This change allows us to practically revive the 'real price' costing method via customization, specifically using the stock_valuation_fifo_lot OCA module. By making `qty_taken_on_candidate` adjustable in the `_run_fifo()` method, we can fine-tune the FIFO calculation to better suit real price costing needs. @qrtl QT4650 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180245
Original PR description
This change allows us to practically revive the 'real price' costing method via customization, specifically using the stock_valuation_fifo_lot OCA module. By making `qty_taken_on_candidate` adjustable in the `_run_fifo()` method, we can fine-tune the FIFO calculation to better suit real price costing needs. @qrtl QT4650 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180245
Without it, images with ratio different than 1 had width or height either shrunk or expanded, which definitely makes these avatar look hideous. This commit fixes most of them. Note that the ones with `.o_avatar` have implicitly `o_object_fit_cover` so this was unnecessary to add them. Before / After <img width="51" alt="Screenshot 2024-10-01 at 00 51 05" src="https://github.com/user-attachments/assets/bee81b6c-b3cc-4610-b855-3a66f6defff9"> <img width="55" alt="Screenshot 2024-10-01 at 00
Original PR description
Without it, images with ratio different than 1 had width or height either shrunk or expanded, which definitely makes these avatar look hideous. This commit fixes most of them. Note that the ones with `.o_avatar` have implicitly `o_object_fit_cover` so this was unnecessary to add them. Before / After <img width="51" alt="Screenshot 2024-10-01 at 00 51 05" src="https://github.com/user-attachments/assets/bee81b6c-b3cc-4610-b855-3a66f6defff9"> <img width="55" alt="Screenshot 2024-10-01 at 00 50 44" src="https://github.com/user-attachments/assets/f3d1937c-3a3a-4a8c-aa01-d91e25bceaac"> Before / After <img width="1280" alt="Screenshot 2024-10-01 at 00 51 40" src="https://github.com/user-attachments/assets/983aa74f-2904-4037-a373-517b13a014d9"> <img width="1280" alt="Screenshot 2024-10-01 at 00 49 40" src="https://github.com/user-attachments/assets/4227137a-aab4-48be-bbf0-803704cb9575"> Forward-Port-Of: odoo/odoo#182262
This Error occurs when a user tries to duplicate multiple payments from the 'Payments' list view. Steps to reproduce: - Install the 'account' module - Go to Invoicing / Customers / Payments and create two payments. - Come to the list view of 'Payments' and duplicate both of them. Traceback: ``` ValueError: too many values to unpack (expected 1) File "odoo/models.py", line 5961, in ensure_one _id, = self._ids ValueError: Expected singleton: account.payment(22, 11) File "o
Original PR description
This Error occurs when a user tries to duplicate multiple payments from the 'Payments' list view. Steps to reproduce: - Install the 'account' module - Go to Invoicing / Customers / Payments and…
This Error occurs when a user tries to duplicate multiple payments from the 'Payments' list view.
Steps to reproduce:
- Install the 'account' module
- Go to Invoicing / Customers / Payments and create two payments.
- Come to the list view of 'Payments' and duplicate both of them.
Traceback:
```
ValueError: too many values to unpack (expected 1)
File "odoo/models.py", line 5961, in ensure_one
_id, = self._ids
ValueError: Expected singleton: account.payment(22, 11)
File "odoo/http.py", line 2373, in __call__
response = request._serve_db()
File "odoo/http.py", line 1903, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1966, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1933, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2177, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 223, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 754, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 459, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/account/models/account_payment.py", line 939, in copy
if not self.is_internal_transfer:
File "odoo/fields.py", line 1204, in __get__
record.ensure_one()
File "odoo/models.py", line 5964, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
An error occurs at [1], where the system receives multiple records in 'self' as duplicating of multiple payments.
link [1]:https://github.com/odoo/odoo/blob/5e28dcf717a7184f226773b3c84b409da24c1336/addons/account/models/account_payment.py#L939
To resolve this issue, Add a loop to copy multiple records one by one.
Sentry-5689633522
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#176169**Purpose:** Enhance the barcode scanner interface and optimize the attendee registration process for more efficient handling of large volumes of attendees. **Specifications:** Change barcode scanner template. - Make barcode template same as 'stock_barcode' - Add a dynamic title Modify attendees page. - Remove check/uncheck button - Replace payment status by status - Keep status as a badge - Only keep kanban and list view - When clicking on record, it opens a dialog box same as if
Original PR description
**Purpose:** Enhance the barcode scanner interface and optimize the attendee registration process for more efficient handling of large volumes of attendees. **Specifications:** Change barcode scanner…
**Purpose:** Enhance the barcode scanner interface and optimize the attendee registration process for more efficient handling of large volumes of attendees. **Specifications:** Change barcode scanner template. - Make barcode template same as 'stock_barcode' - Add a dynamic title Modify attendees page. - Remove check/uncheck button - Replace payment status by status - Keep status as a badge - Only keep kanban and list view - When clicking on record, it opens a dialog box same as if barcode is scanned (kanban and list). Edit the dialog box which opens when user is marked attended. - Keep status in one line. - Add an undo button. - Add Print and Edit buttons in footer which are 'Print Ticket' and 'Open Details' currently. Removed a kanban view from event_sale module - 'event_registration_view_kanban' view was no longer needed as replaced 'sales_status' wth 'status' Mockup link: https://app.excalidraw.com/l/65VNwvy7c4X/88aC6OMVygk Task-4159794 Forward-Port-Of: odoo/odoo#180535
Steps to reproduce: - Create a product with 2 vendors: - First one: quantity 10, delay 10, price 5 - Second one: quantity 5, delay 5, price 10 - Select the dropship route on the product - Create an SO with that product (quantity 5) and confirm it - Go on the purchase order created Bug: The vendor selected is not the correct one (it selects the first one, so the price should be 0, and the delay should be incorrect as well) Fix: In https://github.com/odoo/odoo/commit/a35be7b0dd52a5
Original PR description
Steps to reproduce: - Create a product with 2 vendors: - First one: quantity 10, delay 10, price 5 - Second one: quantity 5, delay 5, price 10 - Select the dropship route on the product - Create an…
Steps to reproduce: - Create a product with 2 vendors: - First one: quantity 10, delay 10, price 5 - Second one: quantity 5, delay 5, price 10 - Select the dropship route on the product - Create an SO with that product (quantity 5) and confirm it - Go on the purchase order created Bug: The vendor selected is not the correct one (it selects the first one, so the price should be 0, and the delay should be incorrect as well) Fix: In https://github.com/odoo/odoo/commit/a35be7b0dd52a5a02b6811cb95ad3189483b7327, the partner passed to _select_seller will always have a value, but an incorrect one for dropshipping routes. The problem resides in https://github.com/odoo/odoo/blob/c04fe54bf45509660ea94a9d7d431c74f1c6023b/addons/product/models/product_product.py#L656. The partner_id is the SO buyer, and it's not possible to have the vendor == to the buyer. It thus default the vendor to the first known vendor which is incorrect. task-id: 4207060 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181724 Forward-Port-Of: odoo/odoo#181542
When a user clicks in the catalog record input to change the quantity manually the input content isn't autoselect and the user has to delete the former one to enter the desired value. Autoselecting the value seems more conveniant in the majority of cases. Also, after one of these edits, if the user click right away in the Back to order button, the redirection to the order form will too fast and it will miss the last edition. Current behavior before PR:  Desired behavior after PR is merged:  @Tecnativa --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180003
## Pull Request HOOT (PRHOOT) - part 24 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10
Original PR description
## Pull Request HOOT (PRHOOT) - part 24 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4:…
## Pull Request HOOT (PRHOOT) - part 24 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971 Part 15.5: https://github.com/odoo/odoo/pull/166463 Part 16: https://github.com/odoo/odoo/pull/166311 Part 17: https://github.com/odoo/odoo/pull/168328 Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657 Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767 Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895 Part 21: https://github.com/odoo/odoo/pull/174337 Part 22: https://github.com/odoo/odoo/pull/176777 / https://github.com/odoo/enterprise/pull/68721 Part 23: https://github.com/odoo/odoo/pull/179660 / https://github.com/odoo/enterprise/pull/69728 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181971
__Current behavior before commit:__ When making a search through `/website/search`, the `website_search_box` view is cached. This includes the search term and the search count. Therefore when a user makes a search, a previous search term might be displayed. It may even be a search that another user made. This bug appeared since the search bar has been added to header templates [`7559626`][1]. __Description of the fix:__ Add `t-nocache` to the whole searchbox so that the search term a
Original PR description
__Current behavior before commit:__ When making a search through `/website/search`, the `website_search_box` view is cached. This includes the search term and the search count. Therefore when a user makes a search, a previous search term might be displayed. It may even be a search that another user made. This bug appeared since the search bar has been added to header templates [`7559626`][1]. __Description of the fix:__ Add `t-nocache` to the whole searchbox so that the search term and the search count is updated with each search. __Steps to reproduce the issue in local:__ (For the issue to appear consistently everytime there should be only a single worker) 1. Click on the search button in the website header and make a search 2. Do the same thing again with another search 3. Click again on the search button The previous search term is shown inside the searchbar opw-4114511 [1]: https://github.com/odoo/odoo/commit/7559626 Forward-Port-Of: odoo/odoo#180548
To reporoduce: ============== 1. install "l10n_mx" 2. send an email to the vendor bill alias with both XML and PDF attached (use the ones on the ticket) -> Odoo only retrieves the XML file and PDF is deleted Problem: ======== when processing the files, `l10n_mx` may set `process_if_existing_lines = True` on some files, if one of these files is processed first, the other files will be ignored then deleted. Solution: ========= process all files. opw-4054484 --- I confirm I hav
Original PR description
To reporoduce: ============== 1. install "l10n_mx" 2. send an email to the vendor bill alias with both XML and PDF attached (use the ones on the ticket) -> Odoo only retrieves the XML file and PDF is deleted Problem: ======== when processing the files, `l10n_mx` may set `process_if_existing_lines = True` on some files, if one of these files is processed first, the other files will be ignored then deleted. Solution: ========= process all files. opw-4054484 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180576
### Steps to reproduce: - Create a Helpdesk team with the options "Return" and "Repairs" - Create a product, sell 1 unit and deliver it. - Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket. - Create a repair order and mark it as done. #### > If you go back to the product return, the stock move of the original return appears twice. ### Cause of the Issue: Clicking on t
Original PR description
### Steps to reproduce: - Create a Helpdesk team with the options "Return" and "Repairs" - Create a product, sell 1 unit and deliver it. - Create a ticket for the Helpdesk Team, select the customer…
### Steps to reproduce: - Create a Helpdesk team with the options "Return" and "Repairs" - Create a product, sell 1 unit and deliver it. - Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket. - Create a repair order and mark it as done. #### > If you go back to the product return, the stock move of the original return appears twice. ### Cause of the Issue: Clicking on the `End Repair` button of the repair will call the `action_repair_end` with a `default_picking_id` equal to the `picking_id` of the `repair.order` in the context. However, during this call a stock move groing from repair location to the repair location will be created and mark as done for the final product to be assocaited with the repair order: https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L379-L382 https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L417-L442 https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L444-L449 Since no `picking_id` is specified in its `move_vals`, the default `picking_id` (that is the return) will be added to the vals of the create here: https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/odoo/models.py#L4564 So that the newly created move will be linked to the return move even thought this makes no sense. opw-4159779 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180008
Issue: ====== We can't move elements in mass mailing. Steps to reproduce the issue: ============================= - Create a new mass mailing with a template that have some blocks - Try to drag one of the blocks to another position - When you click on the button to drag, the right sidebar refreches Origin of the issue: ==================== The issue was first introduced by [1]. The problem when we have the wysiwyg inside an iframe `document.activeElement` will be equal to the i
Original PR description
Issue: ====== We can't move elements in mass mailing. Steps to reproduce the issue: ============================= - Create a new mass mailing with a template that have some blocks - Try to drag one of the blocks to another position - When you click on the button to drag, the right sidebar refreches Origin of the issue: ==================== The issue was first introduced by [1]. The problem when we have the wysiwyg inside an iframe `document.activeElement` will be equal to the iframe element and the `ev.target` is the button of dragging. In reality the button is inside the iframe but the content of the iframe is like this `<iframe> document <iframe>` so contains returns false. Solution: ========= When the `activeElement` is an iframe we search inside its `contentDocument`. opw-4196067 [1]: https://github.com/odoo/odoo/commit/ef97eaf9876bcf1712d4a6bfb91307875b0034ac Forward-Port-Of: odoo/odoo#181143
In some situations it is useful to avoid generating useless device logs, e.g. for automated technical sessions, platform-generated request, etc. This commit introduces support for a `_trace_disable` session flag to do so. This should never be done without a proper assessment of the consequences for auditability, as seen from the user's point of view. Note that non-admin users have no direct or indirect way to set this flag, so it shouldn't be an extra security risk. Privileged users would
Original PR description
In some situations it is useful to avoid generating useless device logs, e.g. for automated technical sessions, platform-generated request, etc. This commit introduces support for a `_trace_disable` session flag to do so. This should never be done without a proper assessment of the consequences for auditability, as seen from the user's point of view. Note that non-admin users have no direct or indirect way to set this flag, so it shouldn't be an extra security risk. Privileged users would have different technical ways to set it, but they could just as easily delete the generated logs or modify them. Also noteworthy: such sessions will of course still be subject to all other auditing mechanisms (server logs, web proxy logs, metadata tracking on modified records, etc.) Forward-Port-Of: odoo/odoo#179413
odoo/odoo#114352 add some logic validation to avoid nonsensical configurations that attempt to e.g. add a follower to a model who does not inherit mail.thread This restriction is a tad too extreme in the case of the 'Send message' action - sending an email is supported on any kind of model as long as the email template supports it. Task-4203142 Forward-Port-Of: odoo/odoo#181763
Original PR description
odoo/odoo#114352 add some logic validation to avoid nonsensical configurations that attempt to e.g. add a follower to a model who does not inherit mail.thread This restriction is a tad too extreme in the case of the 'Send message' action - sending an email is supported on any kind of model as long as the email template supports it. Task-4203142 Forward-Port-Of: odoo/odoo#181763
Problem: When printing a Sales Order for a partner with a long address, the address is truncated in the generated PDF. Steps to reproduce: - Create a partner with a long address. - Create a Sales Order for that partner. - Print the Sales Order. - In the generated PDF, the partner's address is truncated. opw-4201101 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181525
Original PR description
Problem: When printing a Sales Order for a partner with a long address, the address is truncated in the generated PDF. Steps to reproduce: - Create a partner with a long address. - Create a Sales Order for that partner. - Print the Sales Order. - In the generated PDF, the partner's address is truncated. opw-4201101 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181525
Steps : - Set the company of the first pricelist in list view to false - Create a product and set it's company and the go to extra price tab and group by product - Now when adding a new, opens form view, try saving the record Issue : Returns a warning message not allowing to save Cause : The company for pricelist that is default selected and the product have different companies Fix : Updated the action so that it does not open form view as the pricelist tree view is multi-edit
Original PR description
Steps : - Set the company of the first pricelist in list view to false - Create a product and set it's company and the go to extra price tab and group by product - Now when adding a new, opens form view, try saving the record Issue : Returns a warning message not allowing to save Cause : The company for pricelist that is default selected and the product have different companies Fix : Updated the action so that it does not open form view as the pricelist tree view is multi-edit opw-3943830 Forward-Port-Of: odoo/odoo#171032
Steps to reproduce: - Survey > New > Tick 'Survey' - Create a question - Test > Complete the survey - Edit survey > See results The banner displays 'This is a test survey entry', despite no longer being in the test. The condition to display this text was removed in c983f8a5343ac623ebc9d6dbddc506db4079ee5e but it is still relevant here. opw-4160109 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182103 Forward-Port
Original PR description
Steps to reproduce: - Survey > New > Tick 'Survey' - Create a question - Test > Complete the survey - Edit survey > See results The banner displays 'This is a test survey entry', despite no longer being in the test. The condition to display this text was removed in c983f8a5343ac623ebc9d6dbddc506db4079ee5e but it is still relevant here. opw-4160109 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182103 Forward-Port-Of: odoo/odoo#179726
Forward-Port-Of: odoo/enterprise#70302
Original PR description
Forward-Port-Of: odoo/enterprise#70302
Steps to reproduce: - Timesheet > Register time for any task The display of time spent on the task also contains the diff with the expected time for the day, which should not be displayed here. I mistakenly left in a display meant for testing purposes only added in commit 56c7e8ccf5eb92baee258842fe72efa3d1956b96 opw-4123649 Forward-Port-Of: odoo/enterprise#71174
Original PR description
Steps to reproduce: - Timesheet > Register time for any task The display of time spent on the task also contains the diff with the expected time for the day, which should not be displayed here. I mistakenly left in a display meant for testing purposes only added in commit 56c7e8ccf5eb92baee258842fe72efa3d1956b96 opw-4123649 Forward-Port-Of: odoo/enterprise#71174
before this commit, if user need to pass any different value to the sale order creation, there is no direct hook available to do the same after this commit, this hook can be used to pass any value or to modify any existing value passed to the create method Forward-Port-Of: odoo/enterprise#70961 Forward-Port-Of: odoo/enterprise#70151
Original PR description
before this commit, if user need to pass any different value to the sale order creation, there is no direct hook available to do the same after this commit, this hook can be used to pass any value or to modify any existing value passed to the create method Forward-Port-Of: odoo/enterprise#70961 Forward-Port-Of: odoo/enterprise#70151
Before: The Schedule by Sales Order menu was not visible to planning users, even if they had the necessary access rights. After: The Schedule by Sales Order menu is now visible to planning users who have the appropriate access rights. Fix: Add the user group so that the menu will now be visible based on the user's access rights. Task:4192098 Forward-Port-Of: odoo/enterprise#70331
Original PR description
Before: The Schedule by Sales Order menu was not visible to planning users, even if they had the necessary access rights. After: The Schedule by Sales Order menu is now visible to planning users who have the appropriate access rights. Fix: Add the user group so that the menu will now be visible based on the user's access rights. Task:4192098 Forward-Port-Of: odoo/enterprise#70331
The tour `spreadsheet_dashboard_document_add_document_to_dashboard_group` was never actually run because the python method wasn't prefixed by `test_`. The toru was also broken since we allowed to create a dashboard based on a new spreadsheet. Task: [4199036](https://www.odoo.com/web#id=4199036&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#71142 Forward-Port-Of: odoo/enterprise#70355
Original PR description
The tour `spreadsheet_dashboard_document_add_document_to_dashboard_group` was never actually run because the python method wasn't prefixed by `test_`. The toru was also broken since we allowed to create a dashboard based on a new spreadsheet. Task: [4199036](https://www.odoo.com/web#id=4199036&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#71142 Forward-Port-Of: odoo/enterprise#70355
Before this PR When multiple appointments are selected and duplicated a traceback occurs. **Technical** **_get_default_range_slots** method in appointment_hr expects single record, so when appointment_hr is installed and try to duplicate the record singelton traceback occurs. After this PR Without any traceback, appointments can be duplicated. Task-4210180 Forward-Port-Of: odoo/enterprise#70537
Original PR description
Before this PR When multiple appointments are selected and duplicated a traceback occurs. **Technical** **_get_default_range_slots** method in appointment_hr expects single record, so when appointment_hr is installed and try to duplicate the record singelton traceback occurs. After this PR Without any traceback, appointments can be duplicated. Task-4210180 Forward-Port-Of: odoo/enterprise#70537
Before this PR: - The tour step for customer selection was skipped because the parent step triggered by `.o_field_widget[name=partner_id]` did not include a `run` action. - As a result, the child step executed, showing an empty tooltip with incorrect positioning since it was missing both `content` and `position`. - So, the customer selection step was not properly highlighted or explained. After this PR: - Added `content` and `position` attributes to the child step triggered by `.o_field_w
Original PR description
Before this PR: - The tour step for customer selection was skipped because the parent step triggered by `.o_field_widget[name=partner_id]` did not include a `run` action. - As a result, the child step executed, showing an empty tooltip with incorrect positioning since it was missing both `content` and `position`. - So, the customer selection step was not properly highlighted or explained. After this PR: - Added `content` and `position` attributes to the child step triggered by `.o_field_widget[name="partner_id"] input`, ensuring the tooltip appears with the correct message and placement. - The step now properly displays the tooltip when the customer selection field is focused. task-4159812 Forward-Port-Of: odoo/enterprise#69768
Create a bank statement line with: - Label - No partner - Bank Account number [BNK1] - Amount Go to reconciliation widget Reconcile with a manual statement having partner [TEST] [BNK1] will be added to the bank accounts of [TEST] Repeat the steaps with another account [BNK2] Issue: [BNK2] will not be added to the bank accounts of [TEST] This occurs because, when validating a statement line, we don't add a new bank account to the partner if there is already one defined opw-4
Original PR description
Create a bank statement line with: - Label - No partner - Bank Account number [BNK1] - Amount Go to reconciliation widget Reconcile with a manual statement having partner [TEST] [BNK1] will be added to the bank accounts of [TEST] Repeat the steaps with another account [BNK2] Issue: [BNK2] will not be added to the bank accounts of [TEST] This occurs because, when validating a statement line, we don't add a new bank account to the partner if there is already one defined opw-4145124 Forward-Port-Of: odoo/enterprise#69658
The definition of the records `hr_payroll.hr_work_entry_type_out_of_contract` and `l10n_be_hr_payroll.work_entry_type_partial_incapacity` reset the field `is_leave` to False, but not the field `is_unforeseen`. Because of the constraint `is_unforeseen_is_leave`, if `is_unforeseen` had been previously set as True, when the record gets updated (eg during an upgrade), only one of the fields gets changed and it will trigger the constraint. Steps to reproduce: - Edit 'Out of Contract' work entr
Original PR description
The definition of the records `hr_payroll.hr_work_entry_type_out_of_contract` and `l10n_be_hr_payroll.work_entry_type_partial_incapacity` reset the field `is_leave` to False, but not the field `is_unforeseen`. Because of the constraint `is_unforeseen_is_leave`, if `is_unforeseen` had been previously set as True, when the record gets updated (eg during an upgrade), only one of the fields gets changed and it will trigger the constraint. Steps to reproduce: - Edit 'Out of Contract' work entry type and set Time Off and Unforeseen Absence as True. - Upgrade to the next version. Forward-Port-Of: odoo/enterprise#70104