Thursday, April 7, 2022
32 changes · master
Enhancements to existing features
This update lets businesses using Stripe process customer refunds directly from Odoo, reducing the need to switch between systems. It also cleans up the Stripe payment handling code to make future maintenance easier and more reliable.
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
The mail app now uses a dedicated autocomplete input view across messaging areas such as chat windows, Discuss, and the messaging menu. This makes the underlying setup more consistent, helping future improvements to recipient or channel suggestions work reliably across the interface.
Original PR description
With all its identifying fields Task-2817076
The website editor's command menu has been visually refreshed and now hides itself when no matching commands are available, avoiding an unnecessary “No results” message. Keyboard navigation through grouped commands has also been corrected, making the editor smoother and more predictable to use.
Original PR description
- When no command is found in the Powerbox, the text "No results" is shown, which is annoying. Instead, this hides the Powerbox, and restores it if needed (on backspace for instance). - This is a general design upgrade for the Powerbox. task-2802749 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves how Odoo recognizes and processes Dailymotion and Youku video links in the website editor. It helps ensure the correct video is embedded from supported URL formats, reducing errors when users add videos to pages.
Original PR description
**Current behavior before PR:** The regex patterns for dailymotion and youku were too permissive and not specific enough for the way they were intended to be used. **Desired behavior after PR is merged:** The new regexes should correctly isolate the video ID from the URL string and cover all embedding needs for the two providers. For the initiating discussion and PR, see following link: https://github.com/odoo/odoo/pull/44537#discussion_r753250276 task-2696033
The mail app’s attachment viewer has been improved with clearer controls for closing, downloading, and moving between attachments. This makes reviewing images, videos, and other shared files in conversations smoother and more reliable for users.
Original PR description
Task-2579306
Subscriptions are now managed through sales orders, reducing duplicated processes and making subscription handling more flexible. Businesses can combine different billing periods on one customer record, generate invoices for due lines more accurately, and improve upsell discount handling.
Original PR description
Purpose ======= Migrate subscription to sales order to simplify the code, the UX & make it more flexible for the future and easier to maintain. Subscription still appears as a separate module. This…
Purpose ======= Migrate subscription to sales order to simplify the code, the UX & make it more flexible for the future and easier to maintain. Subscription still appears as a separate module. This PR aims to move the sale.subscription models to sale.order. The implementation is quite similar to the sale_renting module. Before this PR, sale.subscription records are similar to sale.order ones. A lot of logic is duplicated to handle the subscription line computations, tax handling, etc. The current implementation of subscription has several drawbacks: * the sale.subscription records depends on required sale order template. * it is not possible to mix different periodicity in a subscription. Each partner has as many contract as periodicity needed (monthly, yearly etc) * when the flow starts in sale_management, the first invoice must be created from the sale application. * upsell prorata calculation to apply a discount is flawed when the salesman want to apply another discount. This PR fixes these issues and make subscription more flexible. One record can have subscription lines with different periodicity. Each line have a next_invoice_date and invoices are generated when they are due with the matching lines. Before this commit, the sale module could not be used to manage subscriptions in an override. This commit adapts the sale module to odoo/enterprise#21825 Taskid: 2568007
Subscriptions are now managed directly through sales orders, reducing duplicated workflows and making subscription handling more flexible. Businesses can combine different billing periods in one contract and generate invoices only for the lines that are due.
Original PR description
Purpose ======= Migrate subscription to sales order to simplify the code, the UX & make it more flexible for the future and easier to maintain. Subscription still appears as a separate module. This…
Purpose ======= Migrate subscription to sales order to simplify the code, the UX & make it more flexible for the future and easier to maintain. Subscription still appears as a separate module. This PR aims to move the sale.subscription models to sale.order. The implementation is quite similar to the sale_renting module. Before this PR, sale.subscription records are similar to sale.order ones. A lot of logic is duplicated to handle the subscription line computations, tax handling, etc. The current implementation of subscription has several drawbacks: * the sale.subscription records depends on required sale order template. * it is not possible to mix different periodicity in a subscription. Each partner has as many contract as periodicity needed (monthly, yearly etc) * when the flow starts in sale_management, the first invoice must be created from the sale application. * upsell prorata calculation to apply a discount is flawed when the salesman want to apply another discount. This PR fixes these issues and make subscription more flexible. One record can have subscription lines with different periodicity. Each line have a next_invoice_date and invoices are generated when they are due with the matching lines. Taskid: 2568007
The barcode stock screens are easier to use, with clearer product references, completion highlighting, better small-screen keypad spacing, and stock moves shown on the information page. Picking details also now include the chatter, and location-based pages are ordered by location name for more predictable navigation.
Original PR description
- Small UI improvements:
- Add supplier reference in the move line when it exists
- Highlight in green when the quantity done is the amount expected
- Change layout of the digipad to have more space in smaller screens
- Show stock moves in kanban view in the information page
- Add the chatter of the picking in the information page.
- Fix that when locations are activated, pages would not appear in the order of the stock location name but in the order of the index of the location in the db.
Task-ID: 2766631Quarter-based date filters in Documents Spreadsheet now show values like "Q1/2022" instead of "Q1 2022". This makes the format more consistent and easier to read for users working with spreadsheet filters.
Original PR description
Change filter display value from "Q1 2022" to "Q1/2022" Odoo task 2816618
The My Planning shift form now hides the Send and Reset to Draft actions for published shifts, matching the existing behavior for publish-related buttons. This reduces confusion for employees by keeping unavailable or inappropriate shift actions out of their view.
Original PR description
In the planning.slot form view in the "My Planning" menu, we hid the "Publish" and "Publish & Send" buttons in a previous task. However, the buttons "Reset to Draft" and "Send" for published shifts are still visible, which is inconsistent. This commit hides those two buttons in the "My Planning" menu. Related: https://github.com/odoo/enterprise/pull/23423 Task-2818723
Resolved issues and error corrections
The accounting payment widget now shows exchange differences with the correct amount and label, reducing confusion when invoices and payments use different currencies. Reconciled entry views and payment details also better reflect both company and foreign currency amounts where relevant.
Original PR description
Task ID: 2712093 Currently: - In the payment widget the exchange difference value is always shown as 0 and is described as "Paid on", which can be confusing for a user - In the Reconciled entries smart button of the exchange difference entry not all reconciled lines are visible - If the invoice is in a foreign currency but the customer paid in company currency, the widget still shows foreign currency that can fluctuate and can be confusing Desired: - The exchange difference should have the difference amount and be described as "Exchange difference" (text-muted) - All reconciled lines should be visible when opening Reconciled Entries from the Exchange difference entry - When the invoice is in a foreign currency, show the foreign amount with ~ and show the actual amount paid in the pop-up -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
The mail app's follow button styling was reviewed and simplified as part of a broader interface cleanup. This helps keep the user interface easier to maintain while preserving the existing behavior for users.
Original PR description
Part of the overall v16 SCSS optimization/restyle, task-2704984 task-2818019 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Unnecessary call to _create_check_sequence because is called in create method and create is called in super().copy() TT35608 Description of the issue/feature this PR addresses: If you duplicate a journal two check sequence are created. Current behavior before PR: If you duplicate a journal two check sequence are created. Desired behavior after PR is merged: If you duplicate a journal one check sequence is created. -- I confirm I have signed the CLA and read the PR guidelin
Original PR description
Unnecessary call to _create_check_sequence because is called in create method and create is called in super().copy() TT35608 Description of the issue/feature this PR addresses: If you duplicate a journal two check sequence are created. Current behavior before PR: If you duplicate a journal two check sequence are created. Desired behavior after PR is merged: If you duplicate a journal one check sequence is created. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#88033
## How to reproduce: 1- Create Product Category "PC" AVCO|FIFO Automated. 2- Create Storable Product "P" with product category PC and unit cost to 1. 3- Create SO with 10 units of P. 4- Create PO with 10 units of P and unit cost of 2. Delivery of the SO should now have 2 IV layers, with one being "Revaluation of XXX (negative inventory)" Global IV of P should be 0 qty, 0 value. 5- Return the delivery order of SO. 6- Open valuation of the return => The value is 0, should be 20
Original PR description
## How to reproduce: 1- Create Product Category "PC" AVCO|FIFO Automated. 2- Create Storable Product "P" with product category PC and unit cost to 1. 3- Create SO with 10 units of P. 4- Create PO…
## How to reproduce:
1- Create Product Category "PC" AVCO|FIFO Automated.
2- Create Storable Product "P" with product category PC and unit cost to 1.
3- Create SO with 10 units of P.
4- Create PO with 10 units of P and unit cost of 2.
Delivery of the SO should now have 2 IV layers, with one being "Revaluation of XXX (negative inventory)"
Global IV of P should be 0 qty, 0 value.
5- Return the delivery order of SO.
6- Open valuation of the return
=> The value is 0, should be 20
In `_get_price_unit`, `price_unit` is taken on the last svl of the origin_returned_move_id, in our case it's the revaluation layer.
`_get_price_unit` now take all svls of origin_returned_move_id into account.
---
The logic for using all IV layers to compute the price_unit is as follows:
If you (1) Sold 10 P (uc 1) , (2) Purchase 10 P (uc 2) , (3) Return the 10 P from the SO
It should have the same end result as (1) Purchase 10 P (uc 2) , (2) Sold 10 P , (3) Return the 10 P from the SO
The end result for the last scenario is 10 qty, 20 value.
The former scenario should also have the 10 qty, 20 value, to do so it need to take into account the revaluation layer.
---
Bug introduced by https://github.com/odoo/odoo/pull/84274
Before the mentioned PR, when the unit_cost of the last valuation layer from the original stock move was 0 (aka: probably always the case when a revaluation layer was created), ` _get_price_unit()` would use the product standard_cost, making the issue mostly invisible.
OPW-2784033
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#88110
Forward-Port-Of: odoo/odoo#85751Currently, when modifying an invoice line and setting taxes (price included) for 100%, the price_unit field will be displayed as 0. This is incorrect and is being fixed here. opw-2793284 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#87960
Original PR description
Currently, when modifying an invoice line and setting taxes (price included) for 100%, the price_unit field will be displayed as 0. This is incorrect and is being fixed here. opw-2793284 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#87960
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#87957
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#87957
- The image transform option uses the `transform` CSS property, which is very poorly supported in email clients. This hides that option so as to avoid bad surprises. - Images with an aspect ratio of 299×524 that aren't linked to anything are treated as downloadable attachments by GMail and get a little "download" icon. This tends to ruin carefully crafted mailing designs so this ensures all images are actually linked to something (at the very least, to `#`) so the icon doesn't appear. task-2
Original PR description
- The image transform option uses the `transform` CSS property, which is very poorly supported in email clients. This hides that option so as to avoid bad surprises. - Images with an aspect ratio of 299×524 that aren't linked to anything are treated as downloadable attachments by GMail and get a little "download" icon. This tends to ruin carefully crafted mailing designs so this ensures all images are actually linked to something (at the very least, to `#`) so the icon doesn't appear. task-2802705 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#87981 Forward-Port-Of: odoo/odoo#87253
**Current behavior before PR:** In Discuss topbar, call buttons are added to allow call and video between channel members. Those buttons were also added to live chat channels but any voice call or video call features are not available for visitors. **Desired behavior after PR is merged:** Call buttons will not appear in Discuss top bar for live chat channels. **Task**-2744224 Forward-Port-Of: odoo/odoo#88002 Forward-Port-Of: odoo/odoo#83908
Original PR description
**Current behavior before PR:** In Discuss topbar, call buttons are added to allow call and video between channel members. Those buttons were also added to live chat channels but any voice call or video call features are not available for visitors. **Desired behavior after PR is merged:** Call buttons will not appear in Discuss top bar for live chat channels. **Task**-2744224 Forward-Port-Of: odoo/odoo#88002 Forward-Port-Of: odoo/odoo#83908
Before this commit, when closing a legacy action Dialog an error was raised. Forward-Port-Of: odoo/odoo#88081
Original PR description
Before this commit, when closing a legacy action Dialog an error was raised. Forward-Port-Of: odoo/odoo#88081
**Current behavior before PR:** When you create a new channel HTML tags are visible in Autocomplete text area for a split second **Desired behavior after PR is merged:** Added prevendDefault for the autocomplete select event to stop it's defaullt behaviour as changing the autocomplete text area's value by the selected item's value Task-2792365 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#88097
Original PR description
**Current behavior before PR:** When you create a new channel HTML tags are visible in Autocomplete text area for a split second **Desired behavior after PR is merged:** Added prevendDefault for the autocomplete select event to stop it's defaullt behaviour as changing the autocomplete text area's value by the selected item's value Task-2792365 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#88097
In case of purchase agreement, call for tender still appears everywhere and it's confusing for the user in case of purchase agreement. It would be better to create another action to have a correct pdf name and report name but it will be modify in master and we could keep a minimal diff here. Forward-Port-Of: odoo/odoo#88076
Original PR description
In case of purchase agreement, call for tender still appears everywhere and it's confusing for the user in case of purchase agreement. It would be better to create another action to have a correct pdf name and report name but it will be modify in master and we could keep a minimal diff here. Forward-Port-Of: odoo/odoo#88076
The name_search of product_template was very slow one problem was the search for product_variant_ids = False here i changed the expression.py using postgresql "exists" instead of "id in (select ..." as reference here the amount of data - 297487 entries in product_template - 299006 entries in product_product Forward-Port-Of: odoo/odoo#78607
Original PR description
The name_search of product_template was very slow one problem was the search for product_variant_ids = False here i changed the expression.py using postgresql "exists" instead of "id in (select ..." as reference here the amount of data - 297487 entries in product_template - 299006 entries in product_product Forward-Port-Of: odoo/odoo#78607
Since [1] the CSRF token used by the donation snippet's form did end up being cached for new visitors that did not have a session id yet. This made the validation of the token fail when using the form because the token from the very first new visitor on the worker was reused. After this commit pages that contain a Donation snippet are not cached anymore in order to always get a fresh CSRF token - similarly to what is done for the form snippet. When using incognito mode the csrf token
Original PR description
Since [1] the CSRF token used by the donation snippet's form did end up being cached for new visitors that did not have a session id yet. This made the validation of the token fail when using the…
Since [1] the CSRF token used by the donation snippet's form did end up being cached for new visitors that did not have a session id yet. This made the validation of the token fail when using the form because the token from the very first new visitor on the worker was reused. After this commit pages that contain a Donation snippet are not cached anymore in order to always get a fresh CSRF token - similarly to what is done for the form snippet. When using incognito mode the csrf token is sometimes not recognized during navigation to the donation payment page. Simple sequence to reproduce it: - drop a Donation snippet on the Home page - use Firefox and do not log in - in normal browser, select 25 then press Donate Now - open an incognito browser, select 50 then press Donate Now => 400 Bad Request Alternative (any browser): - open page with Donation snippet in incognito window - remove session id from cookies using developer tools - close window - reopen page in a new incognito window - try to donate => 400 Bad Request [1]: https://github.com/odoo/odoo/commit/7fccbac004628093da49016f75370a84bba49465 opw-2774065 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#87045
Steps to reproduce: - Create a new product as a storable - Set quantity to 0 - Create a new internal transfer Issue: - The forecast button is in green which should not be the case Solution: For the internal transfers view, the green forecast button was invisible when "forecast are strictly less than 0". It should be "less than or equal to 0". Inversely, the red forecast button should be invisible only when is "forecast are strictly greater than 0". opw-2806764 Forward-Port-Of: o
Original PR description
Steps to reproduce: - Create a new product as a storable - Set quantity to 0 - Create a new internal transfer Issue: - The forecast button is in green which should not be the case Solution: For the internal transfers view, the green forecast button was invisible when "forecast are strictly less than 0". It should be "less than or equal to 0". Inversely, the red forecast button should be invisible only when is "forecast are strictly greater than 0". opw-2806764 Forward-Port-Of: odoo/odoo#88146 Forward-Port-Of: odoo/odoo#87863
When using a pricelist with a currency different than the one of the product, the prices used in the pricelist (surcharge, min_margin, & max_margin) are using the default currency of the company which is invalid. To reproduce the issue: 1. Enable multiple currency and enable a second one with an exagerated rate for the sake of clarity. 2. Create a formula pricelist with the newly activated currency using either surcharge or the margin. 3. Create a SO with a standard product. By switching
Original PR description
When using a pricelist with a currency different than the one of the product, the prices used in the pricelist (surcharge, min_margin, & max_margin) are using the default currency of the company…
When using a pricelist with a currency different than the one
of the product, the prices used in the pricelist (surcharge, min_margin,
& max_margin) are using the default currency of the company which is invalid.
To reproduce the issue:
1. Enable multiple currency and enable a second one with an exagerated rate for the sake of clarity.
2. Create a formula pricelist with the newly activated currency using either surcharge or the margin.
3. Create a SO with a standard product. By switching between pricelist, you will see an invalid price.
E.G.:
EUR_rates = 2 compared to USD PRICELIST = surcharge of 10€ on any product
PRODUCT_price = 300$ PRODUCT_price_euros = 150€
CURRENT_SO_price = (300 + 10)/rate_EUR = (300 + 10)/2 = 155€
EXPECTED_SO_price = (300 + 10*rate_EUR)/rate_EUR = (300 + 10*2)/2 = 160€
Solution: Adapt the computation of a pricelist_item to take into account the currency.
Could not embed everything in the PricelistItem._compute_price method as it would imply
changing its signature (to include the date of the transaction). Consequently,
using a context to pass the adapted prices.
opw-2760720
Forward-Port-Of: odoo/odoo#88143
Forward-Port-Of: odoo/odoo#87018Because some lines can be sections/notes without a product, and the product presence when needed is already verified by the sql constraints. Fixes the mistake from #81818 specifying the field as required when it shouldn't be. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#88194
Original PR description
Because some lines can be sections/notes without a product, and the product presence when needed is already verified by the sql constraints. Fixes the mistake from #81818 specifying the field as required when it shouldn't be. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#88194
In the Disallowed Expenses Report, we can have zero total amounts. This fix is avoiding ZeroDivisionError when computing the rate. [opw-2812849](https://www.odoo.com/web#id=2812849&model=project.task) Forward-Port-Of: odoo/enterprise#26014
Original PR description
In the Disallowed Expenses Report, we can have zero total amounts. This fix is avoiding ZeroDivisionError when computing the rate. [opw-2812849](https://www.odoo.com/web#id=2812849&model=project.task) Forward-Port-Of: odoo/enterprise#26014
The options are not exported because of the name change of a function from https://github.com/odoo/enterprise/commit/4641825daa0ed3b8e407fb3817c582cb541e88a4. Changing it indeed provides it to the xml. Forward-Port-Of: odoo/enterprise#25385
Original PR description
The options are not exported because of the name change of a function from https://github.com/odoo/enterprise/commit/4641825daa0ed3b8e407fb3817c582cb541e88a4. Changing it indeed provides it to the xml. Forward-Port-Of: odoo/enterprise#25385
In case of 'sum_if_pos'/'sum_if_neg'/'sum_if_pos_groupby'/'sum_if_neg_groupby', the totals of the financial report line was well computed. However, when unfolding the line, the displayed grouped lines were always computed like a 'sum'. For example, assume a financial report line with 'sum_if_neg_groupby' as formula considering 2 lines: one +2000 on A, one -10000 on B. In this case, the total of the report line is correct (-10000). However, when unfolding the line, we get A: +2000 B: -1000
Original PR description
In case of 'sum_if_pos'/'sum_if_neg'/'sum_if_pos_groupby'/'sum_if_neg_groupby', the totals of the financial report line was well computed. However, when unfolding the line, the displayed grouped lines were always computed like a 'sum'. For example, assume a financial report line with 'sum_if_neg_groupby' as formula considering 2 lines: one +2000 on A, one -10000 on B. In this case, the total of the report line is correct (-10000). However, when unfolding the line, we get A: +2000 B: -10000 ... instead of only B. task: 2791942 Forward-Port-Of: odoo/enterprise#25935 Forward-Port-Of: odoo/enterprise#25177
Forward-Port-Of: odoo/enterprise#25892
Original PR description
Forward-Port-Of: odoo/enterprise#25892
Before this commit, once the package setting is active, the "Put in Pack" button was shown for any type type of barcode operations, even for inventory adjustments. This button is no longer displayed for inventory adjustments. Forward-Port-Of: odoo/enterprise#25810 Forward-Port-Of: odoo/enterprise#25794
Original PR description
Before this commit, once the package setting is active, the "Put in Pack" button was shown for any type type of barcode operations, even for inventory adjustments. This button is no longer displayed for inventory adjustments. Forward-Port-Of: odoo/enterprise#25810 Forward-Port-Of: odoo/enterprise#25794
On the MPS, when updating a schedule impact another schedule not in the list, we add the impacted schedules at the end of the list. (A schedule update can impact the schedule of the bom components of the product) Currently, when multiple warehouses are present in the company, the new schedule is inserted INSIDE the last schedule. With the fix, the new schedule is inserted AFTER the last schedule. --- Example: In local 14, FURN_8900 and FURN_1118 are components of FURN_7800. We creat
Original PR description
On the MPS, when updating a schedule impact another schedule not in the list, we add the impacted schedules at the end of the list. (A schedule update can impact the schedule of the bom components of the product) Currently, when multiple warehouses are present in the company, the new schedule is inserted INSIDE the last schedule. With the fix, the new schedule is inserted AFTER the last schedule. --- Example: In local 14, FURN_8900 and FURN_1118 are components of FURN_7800. We create a new warehouse in the current company, the issue only happen with multiples warehouses in the MPS. We update the list limit to not show the 2 components in the list. We update the forecasted demand of FURN_7800 so that the components are added to the list: - Behavior before fix: https://watch.screencastify.com/v/keCIZ0UOcGyOjxE4kCYh - Behavior after fix: https://watch.screencastify.com/v/zurLZjWZMHMDNl7ByNae --- OPW-2786188 --- Forward-Port-Of: odoo/enterprise#25930