Navigate
Branch
Tuesday, August 13, 2024
33 changes
13 changes
Resolved issues and error corrections
Fixes the mailing template editor so it resizes to the template content instead of leaving extra blank space or making the snippet panel hard to use. This improves the email campaign editing experience, especially when working with very small or large templates.
Original PR description
Purpose ======= Fix the height of the mail templates in the mailing form. Specification ============= For small templates / theme selector, there is a blank space below the editor because the…
Purpose ======= Fix the height of the mail templates in the mailing form. Specification ============= For small templates / theme selector, there is a blank space below the editor because the iframe's height is matching the full height of the website snippets on the side. For big templates, the website snippets doesn't follow the template scrolling which makes it difficult to drag and drop the snippets. This happens following the removal of the full width view and a related js file which was previously resizing the editor height accordingly (ref commit: https://github.com/odoo/odoo/commit/cf6cd5ef46287f4e71fe96ad6b404ba9b08c1066 ) Reverting a part of the old "mailing_mailing_view_form_full_width" file into the "mass_mailing_html_field" one so that the editor iframe is correctly resized depending on its content and the editor sidebar is correctly resized to follow the scrolling behavior. Concretely, introducting back the resize observer and the "_updateIframe", "_isFullScreen", "_resizeMailingEditorIframe" and "_repositionMailingEditorSidebar" methods. Task-4086341 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Presence status updates are now sent only to users who share a chat or channel with the person whose status changed. This reduces unnecessary client-server traffic and should improve performance without changing the visible messaging experience.
Original PR description
Since [1], presences are only sent when necessary. This PR greatly reduced the traffic between client and server. This PR is a follow-up to reduce the traffic between server and client: the presences should only be sent to people sharing a chat or channel with the presence user. [1]: https://github.com/odoo/odoo/pull/174814 enterprise: https://github.com/odoo/enterprise/pull/68022
Miscellaneous changes
### Description of the issue/feature this PR addresses: In Odoo 15, only stock.group_stock_manager can use the Lock and Unlock button on stock.move ( https://github.com/odoo/odoo/blob/b361be31e446919ffc0ee14e99f8b88fae630ede/addons/stock/views/stock_picking_views.xml#L257 ) When moving the button to an ir.actions.server, the group_ids was not ported properly in #116799 . This commit fixes it and restore the group restriction ### Current behavior before PR: Users without the group `
Original PR description
### Description of the issue/feature this PR addresses: In Odoo 15, only stock.group_stock_manager can use the Lock and Unlock button on stock.move ( https://github.com/odoo/odoo/blob/b361be31e446919ffc0ee14e99f8b88fae630ede/addons/stock/views/stock_picking_views.xml#L257 ) When moving the button to an ir.actions.server, the group_ids was not ported properly in #116799 . This commit fixes it and restore the group restriction ### Current behavior before PR: Users without the group `stock.group_stock_manager` (Administrator) can lock/unlock stock.picking ### Desired behavior after PR is merged: Only users with that group can lock/unlock stock.picking opw-4075127 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176442
Current behavior before PR: - Selecting the last text of a paragraph and applying hex color on it resulted in a traceback. - Selecting the initial text of a long paragraph and applying hex color resulted in unintended coloring of other unselected text. Desired behavior after PR is merged: - Applying a hex color on text will no longer lead to a traceback. - Only the selected text will be colored. task-3578454 Forward-Port-Of: odoo/odoo#174039 Forward-Port-Of: odoo/odoo#158006
Original PR description
Current behavior before PR: - Selecting the last text of a paragraph and applying hex color on it resulted in a traceback. - Selecting the initial text of a long paragraph and applying hex color resulted in unintended coloring of other unselected text. Desired behavior after PR is merged: - Applying a hex color on text will no longer lead to a traceback. - Only the selected text will be colored. task-3578454 Forward-Port-Of: odoo/odoo#174039 Forward-Port-Of: odoo/odoo#158006
This solve 2 problems: -------------------- * Singleton Error: - STEP TO REPRODUCE: Go to tree view mode of task, press New to create a new Task, input 'description' -> Save -> Then edit its description again -> Save -> View history revision -> Error - Solution is to ensure 'recordId' has value when opening History Dialog * Wrong resId when switching task: - when you have 2 tasks, and you navigate between them, this.props.resId will usually be the one for the first task, so
Original PR description
This solve 2 problems: -------------------- * Singleton Error: - STEP TO REPRODUCE: Go to tree view mode of task, press New to create a new Task, input 'description' -> Save -> Then edit its description again -> Save -> View history revision -> Error - Solution is to ensure 'recordId' has value when opening History Dialog * Wrong resId when switching task: - when you have 2 tasks, and you navigate between them, this.props.resId will usually be the one for the first task, so the history is wrong when we navigate between tasks, Instead we use this.model.root.resId Video to reproduce on runbot saas-17.1 https://github.com/odoo/odoo/assets/56789189/1cfd2dd8-a80e-4bdd-aac4-82856eadc8de --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171090
Before this commit, performing a cash in/out operation in a session without any other cash transactions would result in the cash in/out not appearing in the report. It will become like this:  opw-4076188 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175364
Original PR description
Before this commit, performing a cash in/out operation in a session without any other cash transactions would result in the cash in/out not appearing in the report. It will become like this:  opw-4076188 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175364
### Steps to reproduce: 1. Create a storable product and set the quantity on hand to 100 units 2. Create a delivery of 20 units and mark as to-do 3. In the detailed operations, change the quantity to 10 units 4. Validate the transfer without backorder 5. Go to Inventory > Reporting > Locations 6. Click on Inventory at Date, and select a date one month in the past 7. The on hand quantity for the product is 10 ### Before this commit: When viewing a product's quantity in the past, the va
Original PR description
### Steps to reproduce: 1. Create a storable product and set the quantity on hand to 100 units 2. Create a delivery of 20 units and mark as to-do 3. In the detailed operations, change the quantity to 10 units 4. Validate the transfer without backorder 5. Go to Inventory > Reporting > Locations 6. Click on Inventory at Date, and select a date one month in the past 7. The on hand quantity for the product is 10 ### Before this commit: When viewing a product's quantity in the past, the value was based on the `product_qty` of the done stock moves. However, this is the demand, and it is not always equals to the quantity that moved. ### After this commit: Use the quantity of the done stock move lines, which reflect better what really moved in the past. opw-3946354 Forward-Port-Of: odoo/odoo#168456
Before this commit: When a form view was set to non-editable (edit="0"), its x2many fields could still contain editable boolean fields (e.g., Boolean Toggle). After this commit: Boolean fields within x2many fields are now also read-only when the form view is non-editable. Task-3802653 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 ww
Original PR description
Before this commit: When a form view was set to non-editable (edit="0"), its x2many fields could still contain editable boolean fields (e.g., Boolean Toggle). After this commit: Boolean fields within x2many fields are now also read-only when the form view is non-editable. Task-3802653 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#174989
- Go to Project App; - Add a task in any project; - Move the task to "Cancelled State"; - Click on the progress bar above the stage. Before this commit, the task will get hidden but load more button appears. This occurs because the group bar, and the progress bar are out of sync with the latest search read (executed when clicking on a progress bar). Now, when filtering the progress bar is updated, and when removing the filtering the group count is updated, this maintains a correct synch
Original PR description
- Go to Project App; - Add a task in any project; - Move the task to "Cancelled State"; - Click on the progress bar above the stage. Before this commit, the task will get hidden but load more button appears. This occurs because the group bar, and the progress bar are out of sync with the latest search read (executed when clicking on a progress bar). Now, when filtering the progress bar is updated, and when removing the filtering the group count is updated, this maintains a correct synchronization between the current showing records and the group count and the progress bar. Note that, this commit also prevents to shown negative values for the "Other" progress bar. opw-3935547 Forward-Port-Of: odoo/odoo#176511
### Steps to reproduce: - Enable Multi-Step Routes and Batch Transfers in the settings - Inventory > Configuration > Warehouse Management > Operation Types - Click on internal transfer: Enable Auomatic batches group by dest - Create a internal transfer with two moves: 1 x screw and 1 x bolt - Mark the transfer as Todo, duplicate it and `mark as Todo` > the two transfers should be added to a batch - In the barcode app, batch transfers, go on your batch - Add a single screw and validate
Original PR description
### Steps to reproduce: - Enable Multi-Step Routes and Batch Transfers in the settings - Inventory > Configuration > Warehouse Management > Operation Types - Click on internal transfer: Enable…
### Steps to reproduce: - Enable Multi-Step Routes and Batch Transfers in the settings - Inventory > Configuration > Warehouse Management > Operation Types - Click on internal transfer: Enable Auomatic batches group by dest - Create a internal transfer with two moves: 1 x screw and 1 x bolt - Mark the transfer as Todo, duplicate it and `mark as Todo` > the two transfers should be added to a batch - In the barcode app, batch transfers, go on your batch - Add a single screw and validate > A pop up appears to tell you that the rest will be backordered - Validate ### Bug: Instead of being redirected to the barcode app, you are left on the old version of the batch. If you go back the barcode app you will see that your old batch is actually empty (0 lines) and its state is "in progress" instead of being done. If you click on the the empty batch you get a traceback since its picking_type is nowhere to be found by owl ### Cause of the issue: When you added your screw via the barcode app, you marked the move of the picking as picked. When you validated the batch, you are going to mark this move as done and to back order its picking since only part of it was completed. However, since one of its move is 'done' and the other one is 'assigned', its state will not be done and the picking to backorder will be removed from the original batch y these lines: https://github.com/odoo/odoo/blob/686e0f40f28b81ec99ad41f784a06d0ff231b01c/addons/stock_picking_batch/models/stock_picking.py#L140-L144 It would make sense if the the other pickings were to stay in the batch, which is what the "any" part of the if condition is trying to check. However the other picking of the batch is going to be removed later by these lines (since none of its move are picked so that it is considered to be empty): https://github.com/odoo/odoo/blob/686e0f40f28b81ec99ad41f784a06d0ff231b01c/addons/stock_picking_batch/models/stock_picking_batch.py#L233-L234 https://github.com/odoo/odoo/blob/686e0f40f28b81ec99ad41f784a06d0ff231b01c/addons/stock_picking_batch/models/stock_picking.py#L120-L121 This is the cause of all the issues since the old batch is now emptied from all of its picking so that its state will stay in progress and its picking_type_id can't be found from its pickings. ### Expected behavior: The part of the picking that was marked as done should have stayed in the old batch. ### Fix: The any part of this if condition should take into account the pickings that are going to be detached from the batch. https://github.com/odoo/odoo/blob/686e0f40f28b81ec99ad41f784a06d0ff231b01c/addons/stock_picking_batch/models/stock_picking.py#L140-L144 opw-4088846 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176121
Oversight from task-3637983 (https://github.com/odoo/odoo/pull/161265) task-4104583 Forward-Port-Of: odoo/odoo#176224 Forward-Port-Of: odoo/odoo#176147
Original PR description
Oversight from task-3637983 (https://github.com/odoo/odoo/pull/161265) task-4104583 Forward-Port-Of: odoo/odoo#176224 Forward-Port-Of: odoo/odoo#176147
To reproduce the bug: - Add extra step during checkout - Make Sign in/up at check out Mandatory - Add a non-service product to the cart without being logged in and proceed to checkout - Create an account and once logged in continue the checkout process normally until payment is done When the process is done, a request is sent to /shop/payment/validate, and we get a server error message since we try to fetch `sale_last_order_id` from the session but it's not set. To simplify, the buying
Original PR description
To reproduce the bug: - Add extra step during checkout - Make Sign in/up at check out Mandatory - Add a non-service product to the cart without being logged in and proceed to checkout - Create an account and once logged in continue the checkout process normally until payment is done When the process is done, a request is sent to /shop/payment/validate, and we get a server error message since we try to fetch `sale_last_order_id` from the session but it's not set. To simplify, the buying process goes like this: cart > [sign in/up] > [delivery] > checkout > extra_step or confirm_order > payment. The issue is that `sale_last_order_id` is set in confirm_order, which we don't pass through if we have extra_step enabled. To fix that, I moved the set operation a step earlier. opw-3988807 Forward-Port-Of: odoo/odoo#174638
In order to be more accessible, commit [1] allowed the hoverable menus to have an outline when they are focused by using the Tab key. When hovering these menus with the mouse, the outline should not appear, unless it was already focused (with the Tab key). Also, when hovering, the focus should stay on the already focused element. This last part causes some issues: indeed, the focus is kept by calling the `focus` function and the issue with it is that it scrolls to the element on which it is c
Original PR description
In order to be more accessible, commit [1] allowed the hoverable menus to have an outline when they are focused by using the Tab key. When hovering these menus with the mouse, the outline should not…
In order to be more accessible, commit [1] allowed the hoverable menus to have an outline when they are focused by using the Tab key. When hovering these menus with the mouse, the outline should not appear, unless it was already focused (with the Tab key). Also, when hovering, the focus should stay on the already focused element. This last part causes some issues: indeed, the focus is kept by calling the `focus` function and the issue with it is that it scrolls to the element on which it is called. This made the screen scroll unexpectedly anytime we hovered a hoverable menu, to bring the focused element into view. This commit fixes this issue by specifying that the screen should not scroll when focusing the element. Steps to reproduce: - In the menu editor, add some submenus. - In edit mode, click on the header and set the "Sub Menus" option to "On Hover" and the "Scroll Effect" option to "Scroll". - Go to the "/shop" page. - In edit mode, add the cart button on the products and then save. - Scroll down the page and add a product to the cart. - Scroll up the page and hover the menu with a submenu. => The page scrolls down to the product we just added, since it was the focused element. [1]: https://github.com/odoo/odoo/commit/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4 opw-4069610 Forward-Port-Of: odoo/odoo#175710
13 changes
New functionality added to Odoo
Sales teams can now create spreadsheet-based calculators from quotation templates and use them to calculate prices, quantities, and other quotation line values before saving them back to the quote. This helps businesses support tailored pricing workflows, such as delivery or assembly cost calculations, while keeping each calculator adaptable to specific use cases.
Original PR description
Purpose ------- In several businesses, it might be cumbersome to properly calculate a quote (define an appropriate quantity, price, etc). The goal of this task is to allow user to easily access a…
Purpose
-------
In several businesses, it might be cumbersome to properly calculate a
quote (define an appropriate quantity, price, etc). The goal of this task is
to allow user to easily access a spreadsheet (blank or preconfigured) to
do those calculations.
Specification
-------------
From a quotation template, you can create a spreadsheet calculator template.
At creation, a list of sale order lines is inserted with a global
filter allowing to filter the lines according to their quotation.
You can add "Field sync" rules on any cell (right click on a cell) to update
one field of one order line in the list (readonly fields are excluded).
Then, when you create a quotation from the quotation template, you can open
the spreadsheet calculator. It creates a copy of the spreadsheet (allowing
you to play around values etc.) and adds a global filter to filter the
sale order lines from the quotation.
From this spreadsheet, by clicking on "Save in SO00XX", it reads the values
in cells with a "Field sync" rules and updates the quotation lines with
those values.
This allows to create very specific flows with any arbitraty computations
to compute any values in sale order lines, based on any data, from the
spreadsheet itself or from the database by inserting other data sources
in the spreadsheet template, for example, employee planning, products,
stock, etc.
This great power and flexibility comes with limitation about how generic
it can be. It's expected to hardcode product names or ids in formulas in
order to match order lines. Hardcoded names are of course not robust to
different languages, ids are robust to that but are less friendly and are
not cross-db compatible. Each spreadsheet calculator template must be
built specifically for every use case and every database.
Task: 3761590Point of Sale can now receive and manage online restaurant orders through UrbanPiper, starting with Zomato and Swiggy. This helps restaurants centralize third-party delivery orders in Odoo, reducing manual entry and improving order handling.
Original PR description
*=pos_restaurant_urban_piper In this commit : ==== - Enabled integration of online orders from various providers with the Point of Sale. - Currently, Zomato and Swiggy are implemented as the first providers. task- 4040542 Co-authored-by: paso-odoo <paso@odoo.com> Co-authored-by: meji-odoo <meji@odoo.com> Related: https://github.com/odoo/odoo/pull/173300 Related: https://github.com/odoo/upgrade/pull/6327
Introduces a new sales commission app to create commission plans and calculate commissions for salespeople and managers. The feature supports commissions based on sales, invoices, margins, and subscription growth, helping businesses automate and track incentive payouts more accurately.
Enhancements to existing features
Field service-related pages now use clearer, more human-readable web addresses. This improves the customer and employee experience by making links easier to understand, share, and recognize across reports, sales, and stock workflows.
Original PR description
*= industry_fsm_report, industry_fsm_sale, industry_fsm_stock This commit modifies existing URLs to the new format so that the URL's become more human readable. Task-3820230
Several HR-related apps now use cleaner, more human-readable web links. This makes shared links easier to understand and helps create a more consistent navigation experience across expenses, payroll, recruitment signing, and referrals.
Original PR description
*= {expense_extract, payroll, recruitment_sign,
referral}
This commit modifies existing URLs to the new format
so that the URL's become more human readable.
Task-3820230The 1099 box field is repositioned on partner records so it appears below the payment method field. This keeps related payment and tax reporting information grouped together, making the form easier to read and complete.
Original PR description
In this commit:https://github.com/odoo/odoo/pull/174537/commits/09d2b29e14425c1e333bbe4ae6e5caa2e6361f9f We moved the field property_payment_method_id into the account module and we want it to be below the payment terms in the res_partner view. This commit will change the xpath so that the field box_1099_id is now below the payment method field. task: 4016652
Planning warnings for single-day time off are now shorter and easier to read. Instead of repeating the same date twice, the message shows the leave date once and includes custom hours only when relevant.
Original PR description
Before this commit even if there was a single day leave the warning would read as "Person is on leave from 12/7/21 (fromTime) to 12/7/21 (toTime)". After this commit if leave is of single day type then the warning would be read as "Person is on leave on 12/7/21 (fromTime to toTime)". If Time is not custom hours the warning would be read as "Person is on leave on 12/7/21" Here fromTime and toTime are subject to availabilty. task-3887999
Public knowledge article lists are now easier to use: visitors can click anywhere on an article row instead of only the title. Rows also highlight on hover, making clickable articles clearer and aligning the public experience with the internal view.
Original PR description
Currently, there are two layout issues with the article public view: 1. The article link hitbox of the article public view does not span over the entire row. To open an article, the user has to click on the article title. To improve the UX experience, we will set the article link hitbox to the entire row as we do in the backend view. 2. When the user hovers an article link, we do not give a clear indication that the element is clickable. To improve that, we will highlight the rows on hovering as we do in the backend view. Those two changes will improve the UX experience and the consistency between the sidebar loaded in the public view and the sidebar loaded in the backend view. task-4011436
Mobile users can now access message actions through a bottom context menu, making common communication tasks easier to find and use on small screens. This improves the experience for teams managing conversations from phones, including WhatsApp-related messages.
Original PR description
Task-4102385 https://github.com/odoo/odoo/pull/175776
Payment follow-up email templates no longer include the customer's general partner address by default. This keeps reminders focused on the designated follow-up contact, reducing confusion and helping messages go to the right recipient.
Original PR description
Since https://github.com/odoo/enterprise/pull/61861, we include the template partners and email addresses, but Payment followup typically uses the followup contact's email address, and doesn't need partner's address in the template Found due to OPW-3988791
Resolved issues and error corrections
This change addresses a point of sale issue where orders could receive duplicate numbers. Preventing duplicate order numbers helps keep sales records clear and reduces reconciliation problems for staff.
Original PR description
- add async...await when necessary
Miscellaneous changes
Where possible, we make the eTIMS-specific fields and buttons invisible unless the company has Kenya as fiscal country. Exceptions to this are: - the buttons on partner and user form views. We don't have a way of showing them only if the currently selected company is Kenyan. However, they are already visible only in debug mode, so this isn't too much of a problem. - the 'Custom Imports' menuitem - we don't have a way of making it conditionally visible. Forward-Port-Of: odoo/enterprise#6690
Original PR description
Where possible, we make the eTIMS-specific fields and buttons invisible unless the company has Kenya as fiscal country. Exceptions to this are: - the buttons on partner and user form views. We don't have a way of showing them only if the currently selected company is Kenyan. However, they are already visible only in debug mode, so this isn't too much of a problem. - the 'Custom Imports' menuitem - we don't have a way of making it conditionally visible. Forward-Port-Of: odoo/enterprise#66905
Issue ----- Trial report assumes the `comparison` key exists when generating report options. However, that won't be the case if `filter_period_comparison` (Period Comparison option) is false. Steps ----- - Go to Accounting -> Configuration -> Accounting Reports. - Choose Trial Balance then go to Options and disable 'Period Comparison'. - Now generate a trial balance report by going to Reporting -> Audio Reports -> Trial Balance. - A `KeyError` is thrown. opw-3991886 Forward-Po
Original PR description
Issue ----- Trial report assumes the `comparison` key exists when generating report options. However, that won't be the case if `filter_period_comparison` (Period Comparison option) is false. Steps ----- - Go to Accounting -> Configuration -> Accounting Reports. - Choose Trial Balance then go to Options and disable 'Period Comparison'. - Now generate a trial balance report by going to Reporting -> Audio Reports -> Trial Balance. - A `KeyError` is thrown. opw-3991886 Forward-Port-Of: odoo/enterprise#68000 Forward-Port-Of: odoo/enterprise#66049
7 changes
Enhancements to existing features
This update enhances Ecuador's electronic invoice system to support factoring operations, where companies can sell outstanding invoices to financial institutions. The changes add required fields ("plazo" and "unidadTiempo") to sales invoices and debit notes, and rename a technical tag for better compatibility. This enables Ecuadorian businesses to participate in invoice factoring programs.
Original PR description
Some improvements in EDI to support factoring operations. The tag "plazo" and "unidadTiempo" are mandatory in order to a company can be a factor . (Sell off all of its outstanding invoices at one time, rather than having to wait on collecting payments from customers) - Rename tag "RespuestaAutorizacion" to "autorizacion" - Add tag "plazo" and "unidadTiempo" in Sales Invoices and Debit Note (not only for Purchase liquidation) - Modify unit tests
Resolved issues and error corrections
This update fixes the "Add to Dashboard" dialog in the Spreadsheet Dashboard Documents feature by removing an unnecessary external link button. The change simplifies the dialog interface, making it cleaner and more focused on the primary action of adding content to dashboards.
Original PR description
The PR hides the M2O external button in the "Add to Dashboard" dialog by passing the 'no_open' option to the widget. Task: [4066519](https://www.odoo.com/odoo/project/2328/tasks/4066519?cids=2)
Fixed a bug in the Indian localization asset module where depreciation validation checks were only running when assets were first created, not when they were updated later. Now these important validation checks will run both at creation and whenever assets are modified, ensuring data integrity throughout the asset lifecycle.
Original PR description
[FIX] l10n_in_asset: fix check_depreciation func dependencies `_check_depreciations` function is only called at creation and not afterwards We need to have it raised afterwards too task-id#3909619
This fix resolves an issue where confirming multiple purchase orders created through the approval workflow would fail with a validation error. The problem occurred because a temporary naming context was being incorrectly carried over when creating shipments, causing duplicate names. The fix ensures this context is properly cleared so shipments receive unique names as expected.
Original PR description
Issue ----- [Approvals, Purchase, Stock] 1. In approvals, set the current user as the approver for the "Create RFQ's" approval type. 2. Approvals > New Request > Create RFQ's > Select a product with…
Issue
-----
[Approvals, Purchase, Stock]
1. In approvals, set the current user as the approver for the "Create RFQ's" approval type.
2. Approvals > New Request > Create RFQ's > Select a product with a vendor setup ("Acoustic bloc screen" for example) > Submit > Approve > Create RFQ >
Click smart button to navigate to the PO > Confirm the PO (should work)
4. Repeat step 2, ValidationError when trying to confirm the PO.
Note: the issue only arises in this specific flow, the PO can still be confirmed by for example just refreshing the page.
Issue
-----
A 'default_name' key is added to the context when creating a request for a category which uses sequential names (which is the case for RFQ's approvals). https://github.com/odoo/enterprise/blob/65a8e25f1ff2d0faf17ad73c1402615d320ffc48/approvals/models/approval_category.py#L154
As a result, it gets propagated all the way to the creation of the picking when the PO is confirmed.
https://github.com/odoo/odoo/blob/beb8c7d86ae6062dbad9fcb17bc3141d14a9fcdc/addons/stock/models/stock_picking.py#L721 As pickings require a unique (name, company_id), a first picking can be created with the name 'New', but later ones will fail.
Fix
-----
Avoid propagating the default_name key when opening the purchase orders so the picking created when confirming the order will have the correct name.
opw-3990816
Forward-Port-Of: odoo/enterprise#66504When users duplicate a rental order, the rental line information was not being preserved, causing the duplicated order to lose its rental status. This fix ensures that rental line details are properly copied when an order is duplicated, so users can confirm the duplicated rental order with all rental information intact.
Original PR description
Problem: When the user duplicates a rental order from a list view in the rental app, the order lines of the rental order were not getting computed to True for field is_rental during compute_is_rental. The compute method was checking if the 'in_rental_app' was passed into the line's context, which is not the case during the duplication. Solution: If a line has rentable products and it is from a rental order, then the line should be considered is_rental, rather than basing it on the context of the method being called from the Rental app. Steps to Reproduce on Runbot: 1. Install Rental app 2. View the rental orders in list view 3. Select a rental order with a status and duplicate 4. Observe that duped rental order has no rental_status when you confirm it opw-4055493
This fix prevents the Documents app from crashing when users switch between companies and try to access folders they don't have permission to view. Previously, the app would display an error and require a page refresh. Now it automatically redirects to the default "All Folders" view when a folder becomes inaccessible due to company switching, providing a seamless user experience.
Original PR description
Issue: When we have multiple companies and we create different folders for each other, if we are working in a folder from let's say company A and then we switch to Company B, we will run the same…
Issue: When we have multiple companies and we create different folders for each other, if we are working in a folder from let's say company A and then we switch to Company B, we will run the same link to this folder but from the Company B rights point of view, and since this folder is not accesible from this company it will throw a traceback and break the page until refresh to another url. Steps to reproduce: 1. Install Documents. 2. Have atleast 2 companies. 3. Create a new folder that belongs to the current company. 4. While having this folder selected, change to the 2nd company. Solution: The issue is triggered within the load funcion for the DocumentsSearchModel, since we get the folderId that's in the url, and we also get the list of the folder we have access to, we could filter out if the current folder we are trying to access is within this list before calling toggleCategoryValue, and If it's not we could just call it on `folderId = false;` as default (which is the "All" section of folders). This way we avoid calling `category.values.get(...)` later on for undefined (we don't have access to this folder). opw-3971935
This fix corrects an issue where debit amounts were showing as zero in accounting reports when using analytics grouping. The problem was caused by inverted debit signs in the report calculation logic. Users will now see accurate debit figures that match balance amounts when filtering by debit values in analytics-enabled reports.
Original PR description
To reproduce the issue, on a fresh db with nothing else: 1) Create a new accounting report from srcatch, so that: - it has 2 columns - it has 1 line, with two expressions: - the expression going in…
To reproduce the issue, on a fresh db with nothing else:
1) Create a new accounting report from srcatch, so that:
- it has 2 columns
- it has 1 line, with two expressions:
- the expression going in column 1 is a domain, doing [('debit', '>', 0)]
- the expression going in column 2 is also a domain, doing [('balance', '>', 0)]
- it has analytics groupby enabled
2) Create a vendor bill, with only 1 line of 100€. Assign it an analytic distribution of 100% into some analytic account.
3) Open your report, activate the analytic groupby on the analytic account used in point 2).
====> The column considering the balance shows 100€, while the one considering the debit shows 0. This is wrong; both columns should show 100€.
This is due to the fact the sign of the debit is inverted in the SQL shadowing of the move lines made to handle analytics in the report engine. Instead of 100, it sees -100 here, which does not match the domain.
Forward-Port-Of: odoo/enterprise#67018