Thursday, August 5, 2021
28 changes · master
Enhancements to existing features
Payment validation charges are now refunded immediately when the payment is confirmed, instead of relying on customers reaching a follow-up page. This reduces the risk of customers not receiving refunds after closing a browser tab or when confirmation happens through automated payment notifications, with Authorize.net voiding validation charges right away.
Original PR description
Before this commit, the validation flow with verification (payment of a small amount with immediate refund) was performed with the use of validation routes: after payment, the customer was redirected…
Before this commit, the validation flow with verification (payment of a small amount with immediate refund) was performed with the use of validation routes: after payment, the customer was redirected to the validation route stored on the transaction to trigger the refund. This implementation had an issue: if the customer never reached the validation route, they were not refunded their validation amount. This could happen if the customer closed the tab after paying with an acquirer offering payments with redirection, or if the validation payment was asynchronously confirmed through a webhook notification. This commit gets rid of validation routes and requires acquirers to immediately refund the validation amount when the payment is confirmed. This way, a payment confirmation coming from a webhook can trigger the refund too. As the only acquirer that implements the validation with verification flow, Authorize.net now voids validation transactions as soon as they are authorized. While we're at it, the logging of processing values is adapted to only log specific rendering values if a redirect form is rendered. task-2612977 Enterprise PR: https://github.com/odoo/enterprise/pull/20060 Upgrade PR: https://github.com/odoo/upgrade/pull/2710
This update improves the Point of Sale experience with clearer receipts and invoices, better mobile popups, and more intuitive selling controls. Staff can more easily identify POS browser tabs, see tip and discount details, reprint receipts with the original order date, and spot multiple open sessions from the dashboard.
Original PR description
This PR addresses multiple small changes for the POS according the task 2492631 which are: - Discount information from a pricelist is shown on the invoice depending on the discount policy. - Improved…
This PR addresses multiple small changes for the POS according the task 2492631 which are: - Discount information from a pricelist is shown on the invoice depending on the discount policy. - Improved the Product Configuration modal which was too wide and not mobile friendly. - ~~Allocate only one (or groups of) cash payment method(s) to a single `pos.config` if the cash control is activated. This prevents the opening control of multiple `pos.config` (if the cash control is activated) from being mixed up.~~ - "Resume" button of the `pos.config` has been renamed to "Continue selling". - Changed the favicon when opening the POS UI. - The amount of the tip is now shown on the button and is selected in the `NumberPopup` - Added `white-space: pre-line` css for the message popup. This keeps the line breaks in the message. - Date of the original POS order is shown when reprinting a receipt. - The `pos.config` kanban now show if there are more than one opened session. By clicking on the button-link, it opens a filtered `pos.session` view containing the opened sessions of the `pos.config` An additional fix has been added regarding the modals not correctly aligned in mobile version Related enterprise PR: https://github.com/odoo/enterprise/pull/19273
Website animation features have been merged directly into the main Website app after cleanup and improvements. This makes animated website content a standard part of Website, simplifying use and maintenance without requiring a separate app.
Original PR description
The app received many fixes and its code was improved and cleaned. It was about time to include it directly into the website features. task-2215118
Aged Receivable and Aged Payable reports now use clearer column names and remove the journal column to make the reports easier to read. Customer or vendor bill references are still available as tooltips, helping users access key context without cluttering the report.
Original PR description
Modify the Aged Receivable and Aged Payable reports: -include customer reference or bill reference as a tooltip -'Report Date' -> 'Due Date' -'Exp. Date' -> 'Expected Date' -Remove Journal column Task 2573962
Subscription portal payment handling was updated to align with the new payment transaction process. This improves the refund validation flow and keeps subscription payments consistent with the broader platform changes.
Original PR description
Enterprise side of the removal of validation routes on payment transactions. See community side for more details. task-2612977 Community PR: https://github.com/odoo/odoo/pull/74707 Upgrade PR: https://github.com/odoo/upgrade/pull/2710
Resolved issues and error corrections
Image shape settings now behave correctly when users replace shaped images with GIFs or switch back to supported formats. This prevents animated GIFs from being incorrectly converted or losing animation, and avoids leftover shape data on image types that do not support shapes.
Original PR description
Issues: [ 1 ] - Edit mode > Set a shape on Image - Replace it by a GIF > GIF is not animated in the shape. - Remove the shape > the GIF is still not animated (converted and saved as base64). [ 2 ] - [1] Edit mode > Set a shape on image (mimetype = 'image/jpeg') - [2] Replace it by an animated GIF. - [3] Replace the .GIF image again by the old one. - The shape is not applied on it. The goal of this PR is to fix all issues related to wrong mimetype values / incoherent dataset by adding the `_isImageMimetypeSupported()` method to check if image format is supported and set shape accordingly. IMPORTANT: after this PR, the right mimetype value for GIF images is passed and shapes cannot be applied on them > useless shape data will be removed from non-supported images. task-2578242
Miscellaneous changes
Due to the following PR: https://github.com/odoo/odoo/pull/70092 the download icon wasn't present in the document viewer. We had to do this to avoid crash in mobile apps (Android and iOS). But even if there are multiple other ways to download file, some of our users are used to use pdf js download button that was previously hidden. So in this commit, we restore it on desktop as we can now correctly handle the error on Android tablets and hide this button on iOS tablets. Note that p
Original PR description
Due to the following PR: https://github.com/odoo/odoo/pull/70092 the download icon wasn't present in the document viewer. We had to do this to avoid crash in mobile apps (Android and iOS). But even…
Due to the following PR: https://github.com/odoo/odoo/pull/70092 the download icon wasn't present in the document viewer. We had to do this to avoid crash in mobile apps (Android and iOS). But even if there are multiple other ways to download file, some of our users are used to use pdf js download button that was previously hidden. So in this commit, we restore it on desktop as we can now correctly handle the error on Android tablets and hide this button on iOS tablets. Note that pdfjs button is not needed on mobile as we doesnt' have attachements preview on small screens. Another button is available when you open the file. Steps to reproduce: - Go to Accounting - Customer Invoices - After printing it once, the download icon wasn't present in pdfjs preview 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#74624 Forward-Port-Of: odoo/odoo#74606
The project overview now checks directly whether a project has timesheets instead of calculating total timesheet time first. This reduces unnecessary processing and should make the project kanban view load more efficiently when timesheets are present.
Original PR description
Before this commit, we use the `total_timesheet_time` field in the kanban view of `project.project` to know if there are some timesheets into each project. The problem is this field is computed and its compute method take more execution time than just use `timesheet_ids` field to allow if a project has at least one timesheet. This commit replaces the using of `total_timesheet_time` field by the `timesheet_ids` field in project kanban view to check if the project has at least one timesheet. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The mail menu unread counter now excludes channels that are not pinned, preventing hidden or inactive conversations from inflating the displayed unread count. This helps users see a more accurate notification number for the conversations they actively keep in their menu.
Original PR description
Follow up of a795a2f7d8fd57120db5cafdc9f1929e118b0626
Adyen payment notifications will now always receive the expected confirmation response, even if Odoo encounters a validation issue while processing them. This avoids exposing internal error details in Adyen's backend and keeps payment notification handling cleaner and more consistent.
Original PR description
Before this commit, when the webhook was processing a notification, if there was a validation error, the webhook was sending the whole traceback to Adyen. Since this was still a response code 200, this didn't cause any problem, but we could see the response received in the Adyen backend. So we will now catch any validation error and send `'[accepted]'` in the response.
This fix ensures that when an Italian SdI Coop electronic invoice is sent successfully, the system reports the success correctly. This helps prevent follow-up processes or user feedback from treating a successful send as uncertain or failed.
Original PR description
…d return {'success': True}
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-prThis fixes an issue that could prevent PDF reports, such as invoices, from printing correctly. Businesses can now generate and share key documents more reliably without print errors interrupting daily workflows.
Original PR description
fixes for odoo/odoo#68299 can be tested with invoice print to pdf
Customers returning to Odoo after paying with Adyen will no longer risk losing their payment session due to browser cookie behavior. This helps Odoo immediately find and finish processing the payment, reducing failed or delayed order confirmations. Related payment return descriptions for PayUmoney and SIPS were also clarified.
Original PR description
Before this commit, users returning from Adyen to Odoo after payment could see their session renewed, depending on their browser's implementation of the `SameSite` cookie attribute. This prevented Odoo from retrieving the transaction from the users' session. This commit flags the return route of Adyen with `save_session=False`, hence allowing all users to immediately post-process their transactions when they return to Odoo. While we're at it, the docstrings of the return routes of PayUmoney and SIPS' have been updated for better clarity.
Point of Sale users now see an error message when they select a loyalty reward for a free product that is not available in the POS. This prevents silent failures and helps staff understand why the reward cannot be applied.
Original PR description
This PR addresses multiple small changes for the POS according the task 2492631 which are: - Added an `ErrorPopup` when selecting a free product which is not loaded in the POS as a reward. - ~~Properly load the rewards and rules of the corresponding (only one) Loyalty Programs~~ (fixed in 0fbdbd082209f8f408c1a88f969a4fab26fd1589) Related community PR: https://github.com/odoo/odoo/pull/72793
A recent change caused errors when users tried to print accounting reports as PDF files. This fix restores reliable PDF printing so finance teams can generate and share reports without interruption.
Original PR description
odoo/enterprise#17270 introduced an error when trying to print accounting reports to PDF
Issue: When making a return for a transfer, the precision_rounding was taken from the UoM of the product given in the transfer, but the quantity was taken in the UoM of the product defined on its form Steps to reproduce : 1) Create a UoM "Hundreds", rounding precision 1 (has to be different than "Dozen"), Bigger than the reference Unit of Measure, ratio 100 2) Create a test product with "Dozen" as UoM 3) Inventory > Operations > Transfers > Create 4) Add test product, Demand=2, Unit o
Original PR description
Issue: When making a return for a transfer, the precision_rounding was taken from the UoM of the product given in the transfer, but the quantity was taken in the UoM of the product defined on its…
Issue: When making a return for a transfer, the precision_rounding was taken from the UoM of the product given in the transfer, but the quantity was taken in the UoM of the product defined on its form Steps to reproduce : 1) Create a UoM "Hundreds", rounding precision 1 (has to be different than "Dozen"), Bigger than the reference Unit of Measure, ratio 100 2) Create a test product with "Dozen" as UoM 3) Inventory > Operations > Transfers > Create 4) Add test product, Demand=2, Unit of Measure=Hundreds 5) Validate 6) Create a Return for that transfer 7) Quantity is set to 17 Dozen instead of 16.67 Why is that a bug: The quantity to return is `quantity = stock_move.product_qty` (in UoM of the product form) but the rounding is made with rounding precision `stock_move.product_uom.rounding` (in UoM of the line of the transfer) which can be different in case of manual transfer creation for example opw-2543304 Forward-Port-Of: odoo/odoo#74496 Forward-Port-Of: odoo/odoo#74435
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#71847
Original PR description
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#71847
When using several certification together, there was an issue when we tried to modify the quantity of an orderline. The "this" context was lost and we were unable to call the function anymore. In order to fix that, we bind the context when calling the function. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#74162
Original PR description
When using several certification together, there was an issue when we tried to modify the quantity of an orderline. The "this" context was lost and we were unable to call the function anymore. In order to fix that, we bind the context when calling the function. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#74162
When a purchase order is generated via the scheduler with a reordering rule, the gst_treatment is not retrieved opw-2540090 Forward-Port-Of: odoo/odoo#74645 Forward-Port-Of: odoo/odoo#74569
Original PR description
When a purchase order is generated via the scheduler with a reordering rule, the gst_treatment is not retrieved opw-2540090 Forward-Port-Of: odoo/odoo#74645 Forward-Port-Of: odoo/odoo#74569
**Description of the issue/feature this PR addresses:** - create a pos config with a printer - connect the printer - open a new pos session with an user with only group 'group_pos_user' - click on the printer --> An error is raise If you a user with only group 'group_pos_user' it is not possible to print the sale details. Because during the compute_all of the taxe, account.account.tag need read access. This PR allow 'group_pos_user' to print the sale details. Current behavior before
Original PR description
**Description of the issue/feature this PR addresses:** - create a pos config with a printer - connect the printer - open a new pos session with an user with only group 'group_pos_user' - click on the printer --> An error is raise If you a user with only group 'group_pos_user' it is not possible to print the sale details. Because during the compute_all of the taxe, account.account.tag need read access. This PR allow 'group_pos_user' to print the sale details. Current behavior before PR:  @pimodoo @caburj -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#74320
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#74705
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#74705
Before this commit, the popover would be displayed on top of the clicked element if that element was a menu in a dropdown. Indeed, there was not enough room for the popover to be shown correctly, as the available space was the dropdown itself. Note that if there was more than 2 menus in the dropdown, it would work correctly as it would create enough space for the popover to be shown bellow or above the menu. Step to reproduce: - Create a menu and a submenu - Click on the menu, it op
Original PR description
Before this commit, the popover would be displayed on top of the clicked element if that element was a menu in a dropdown. Indeed, there was not enough room for the popover to be shown correctly, as the available space was the dropdown itself. Note that if there was more than 2 menus in the dropdown, it would work correctly as it would create enough space for the popover to be shown bellow or above the menu. Step to reproduce: - Create a menu and a submenu - Click on the menu, it opens a dropdown with the submenu inside it - Click on the submenu, the popover position is wrong Forward-Port-Of: odoo/odoo#74747
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#74640
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#74640
This pull request does not include enough information about changed files or commits to identify a specific business impact. It appears to be a work-in-progress item, so the expected user-facing change is not yet clear.
Fix traceback introduced by: https://github.com/odoo/enterprise/commit/60fee9884649af097ba496dbeb532912d4a50c7c opw-2616467 Forward-Port-Of: odoo/enterprise#20079 Forward-Port-Of: odoo/enterprise#20069
Original PR description
Fix traceback introduced by: https://github.com/odoo/enterprise/commit/60fee9884649af097ba496dbeb532912d4a50c7c opw-2616467 Forward-Port-Of: odoo/enterprise#20079 Forward-Port-Of: odoo/enterprise#20069
All accounting reports did not have the proper styles and indentation when exported to PDF Task 2613444 Forward-Port-Of: odoo/enterprise#20074
Original PR description
All accounting reports did not have the proper styles and indentation when exported to PDF Task 2613444 Forward-Port-Of: odoo/enterprise#20074
When using several certification together, there was an issue when we tried to modify the quantity of an orderline. The "this" context was lost and we were unable to call the function anymore. In order to fix that, we bind the context when calling the function. Forward-Port-Of: odoo/enterprise#19811
Original PR description
When using several certification together, there was an issue when we tried to modify the quantity of an orderline. The "this" context was lost and we were unable to call the function anymore. In order to fix that, we bind the context when calling the function. Forward-Port-Of: odoo/enterprise#19811
Related issue: [Odoo issue](https://www.odoo.com/web#action=333&active_id=70&cids=1&id=2532514&menu_id=4720&model=project.task&view_type=form) (see messages, not description) Before coming up with this, I did refresh stats (`VACUUM`) on the database concerned here in order to rule out the possibility of poor statistics being behind the inefficient query plan. When the user tries to open up product template form view, the following query is generated by the orm if the Quality module (`quali
Original PR description
Related issue: [Odoo issue](https://www.odoo.com/web#action=333&active_id=70&cids=1&id=2532514&menu_id=4720&model=project.task&view_type=form) (see messages, not description) Before coming up with…
Related issue: [Odoo issue](https://www.odoo.com/web#action=333&active_id=70&cids=1&id=2532514&menu_id=4720&model=project.task&view_type=form) (see messages, not description)
Before coming up with this, I did refresh stats (`VACUUM`) on the database concerned here in order to rule out the possibility of poor statistics being behind the inefficient query plan.
When the user tries to open up product template form view, the following query is generated by the orm if the Quality module (`quality_control` to be specific) is installed:
```
SELECT COUNT(1) FROM "quality_point" WHERE (
(("quality_point"."active" = TRUE) AND ("quality_point"."company_id" = 1))
AND (
("quality_point"."id" NOT IN (SELECT "quality_point_id" FROM "product_product_quality_point_rel" WHERE "quality_point_id" IS NOT NULL)) OR
("quality_point"."id" IN (SELECT "quality_point_id" FROM "product_product_quality_point_rel" WHERE "product_product_id" IN (12383)))
)
)
AND ("quality_point"."company_id" IS NULL OR ("quality_point"."company_id" in (1)))
```
This query causes Odoo to **hang indefinitely**. I managed to dissect it and find which piece of it exactly makes Odoo hang, here it is:
`("quality_point"."id" NOT IN (SELECT "quality_point_id" FROM "product_product_quality_point_rel" WHERE "quality_point_id" IS NOT NULL))`
and I found it by manually running in psql the following (this will also become the test-query that I'll be running every time I make any changes):
```
SELECT COUNT(1) FROM "quality_point"
WHERE ("quality_point"."id" NOT IN
(SELECT "quality_point_id" FROM "product_product_quality_point_rel" WHERE "quality_point_id" IS NOT NULL));
```
I believe the problem lies with the use of `NOT IN`. According to this [thread](https://wiki.postgresql.org/wiki/Don%27t_Do_This#Why_not.3F_3), `NOT IN` becomes highly inefficient upon reaching certain threshold (ie in case of big enough tables, record-wise). So, to confirm this, I run the following two queries (notice the difference in `LIMIT`):
`SELECT id FROM "quality_point" WHERE ("quality_point"."id" NOT IN (SELECT quality_point_id FROM "product_product_quality_point_rel" LIMIT(2097153)));`
`SELECT id FROM "quality_point" WHERE ("quality_point"."id" NOT IN (SELECT quality_point_id FROM "product_product_quality_point_rel" LIMIT(2097152)));`
and here are explain plans corresponding to these queries:
The first query **hangs**, while the second **doesn't**. Explain plan changes when fetching >2097152 records from `product_product_quality_point_rel` (in the case of this particular database). New plan makes the query extremely inefficient, to the point that it's never finished (and therefore makes it impossible to open product template form views for the customer).
So in order to prevent the first query from hanging, I rewrote it to use `NOT EXISTS` instead of `NOT IN`, as suggested [here](https://wiki.postgresql.org/wiki/Don%27t_Do_This#Why_not.3F_3):
`SELECT id FROM "quality_point" WHERE NOT EXISTS (SELECT quality_point_id FROM "product_product_quality_point_rel" WHERE quality_point_id = "quality_point"."id" LIMIT(2097153));`
and bingo, it worked. Now the only thing left was to make Odoo generate a query without the use of `NOT IN`. Initially I thought about modifying `orm/expression.py` to make it prefer using `NOT EXISTS` instead of `NOT IN`, but due to the complexity of orm and me lacking in knowledge, I opted for "tricking" Odoo into generating a different query while still achieving the same result, hence this pr. After this change in `quality.py`, this is how the query looks like:
```
SELECT count(1) FROM "quality_point" WHERE (
(("quality_point"."active" = true) AND ("quality_point"."company_id" = 1))
AND (
("quality_point"."id" in (SELECT "quality_point_id" FROM "product_product_quality_point_rel" WHERE "product_product_id" IN (NULL))) OR
("quality_point"."id" in (SELECT "quality_point_id" FROM "product_product_quality_point_rel" WHERE "product_product_id" IN (12383)))
)
)
AND ("quality_point"."company_id" IS NULL OR ("quality_point"."company_id" in (1)))
```
It doesn't utilize `NOT EXISTS`, but also there is no `NOT IN` anymore and Odoo no longer hangs waiting for this query to finish, so I guess it'll do as well.
Forward-Port-Of: odoo/enterprise#19228