Monday, April 8, 2024
26 changes
1 change
Resolved issues and error corrections
Odoo now waits until the web client has the complete user context before loading actions. This prevents server actions from running with missing information such as the active company, reducing errors in multi-company or context-dependent workflows.
Original PR description
Since [1], when an action is loaded, if the action is a server action, the server will execute the action directly and return the resulting action. Before the commit [1], only a part of the context was need, now that the server execute the action, the complete user context is need. Before this commit, a performance improvement was to call the action load at the beginning of the action service. The issue with calling the action load in such an early step, is that all the user context is not complete yet (For instance, the allowed_company_id is not yet there, it's added later by the company service). Now, the call to the action load is made on the mount of the WebClient, in which moment it should have the complete user context. [1] : https://github.com/odoo/odoo/commit/f49e97e9ad41c1c5e7123bad9c429a9af2732b73
1 change
Enhancements to existing features
23 changes
Enhancements to existing features
The approval request form has been improved to provide a better user experience. Date fields now have consistent spacing, and the primary action button intelligently changes based on document status—showing "Attach Documents" when no documents are linked, or "Confirm/Approve" once documents have been submitted. These refinements make the approval workflow clearer and more intuitive for users.
Original PR description
With this commit on approval request's form view:
* You have the same padding for dates
* The primary button is "attached documents" if you don't linked a
document or "confirm","approve" if you have already send a document.
task : 3724860
Forward-Port-Of: odoo/enterprise#59938
Forward-Port-Of: odoo/enterprise#58863Odoo now automatically includes fields that are required because of view rules, reducing the need for manual configuration across several business apps. This helps forms and workflows behave more reliably when conditions make information mandatory.
Original PR description
related to https://github.com/odoo/odoo/pull/137031
The UK tax reporting module now includes a configuration setting that allows users to easily switch between production and test modes without editing code. This makes it simpler for teams to test HMRC integration features using sandbox credentials before going live.
Original PR description
Previously, testing HMRC features with dummy credentials required manually changing variables within the code. This commit introduces a more user-friendly approach by adding a new configuration parameter. The new configuration parameter defaults to "production" to maintain existing behavior. However, users can switch to a "demo" or other values to transition the APIs to a sandbox environment for testing with mock credentials. task-3820114 Forward-Port-Of: odoo/enterprise#59152
Resolved issues and error corrections
This update fixes multiple issues with the timesheet leaderboard feature, including preventing the leaderboard from displaying for employees without billable rates, correcting theoretical working hours calculations, and improving the visual presentation with proper icons and styling. These fixes ensure the leaderboard accurately reflects employee billing information and displays correctly for all users.
Original PR description
This commit adds various changes to the codebase to fix issues with the leaderboard system, issues such as the leaderboard being displayed even though the current employee has no billable time rate, billing rate target not having the fa-building icon next to it, theorical working hours being incorrect, visual issues and many more. task-3570302
Fixed an issue where users couldn't access products from their company when viewing the product catalog in Field Service tasks without existing sales orders. The fix ensures the system correctly recognizes which company's products should be available, allowing seamless product browsing in multi-company environments.
Original PR description
Steps ----- 1. Have field services and sales installed 2. Create a new company 3. Create a new product belonging to the new company 4. Log in under new company 5. Field service > click the "Product" smart button in a task with no sales order ** Read access error when accessing a page with a product from new company ** Issue ----- In a multi-company environment, accessing the catalog of products in field service is only possible if there are no products belonging to a different company than the user's main company. Note: this issue only arises if there's no sales order linked to the task. If an order already exists (for example by creating a sales order item in the task form), its associated company will be used. Fix --- We use the tasks's company to have the correct allowed_company_ids in the context. **opw-3752311**
This fix resolves a crash that occurred when users clicked the cancel button in the signature request popup after scheduling a signature activity. The issue was caused by an incorrect parameter being passed when the popup closed. By updating how the parent view reloads after cancellation, the error is eliminated and the activity updates properly.
Original PR description
Version: ----------- saas-16.3 Steps to produce: ------------------------- 1. Open Sales or any other app. 2. Schedule an activity for Request Signature 3. Once the activity is scheduled, click on the Request Signature field 4. In the New signature Request pop-up click on cancel button ->Traceback occurs Issue: -------- A traceback occurs when we click on Request Signature after creating any Request Signature activity and click on cancel button. Cause: --------- The error occurs because when the cancel button is clicked, the onUpdate component is triggered to load and update the ID. However, a special parameter is passed incorrectly, leading to an error. Fix: ----- The issue can be resolved by changing the props from onUpdate to reloadParentView, the component correctly reload the parent view upon cancelation, This prevents the traceback error by ensuring that the activity is updated appropriately. task-3768008 Forward-Port-Of: odoo/enterprise#58729
This update upgrades the Dutch tax report templates used for submitting reports to the Netherlands fiscal authorities to the newer nt18 version. The templates have been updated to comply with the latest requirements from Dutch tax authorities, and a warning message has been added to remind users to upgrade their module before submitting reports.
Original PR description
The templates are used to create a report that will be sent to the fiscal authorities of the Netherlands. They have updated to a newer version of the template. Forward-Port-Of: odoo/enterprise#59907
This fix corrects the WhatsApp message sent count in event communications to accurately reflect all messages sent, including those to unconfirmed attendees. Previously, the system was undercounting messages because it excluded unconfirmed attendees from the total sent count, making it difficult to track actual communication activity.
Original PR description
Before this commit the Whatsapp Sent Count (located in the Communication tab of the event view) wasn't including messages sent to the attendees who weren't confirmed. ### [This commit changes] Event…
Before this commit the Whatsapp Sent Count (located in the Communication tab of the event view) wasn't including messages sent to the attendees who weren't confirmed. ### [This commit changes] Event mail scheduler will include seats_uncofirmed into calculation of the mail_count_done which is the count of emails sent. This is reflecting the actual number of messages sent. ### [Reproduce] - Install whatsapp_event - Create event E starting in time T (Events/Events) - Add an "Unconfirmed" attendee - Add an E-Mail in the Communication tab of the event E - Set Interval time > T, - Template: "Email Reminder" - Trigger "Before the event" - Run scheduled Action sending whatsapp (Scheduled Actions / Event: Mail Scheduler) - BUG: message sent, but not included in the sent count in the communication tab of the event E Related to the commit in the odoo community called: [FIX] event: Include unregistered attendee emails in total sent count # Related PRs in odoo Community This Pr is a part of fix/test bundle. For more details check out the here Community PR: https://github.com/odoo/odoo/pull/153795 opw-3693626 Forward-Port-Of: odoo/enterprise#58428
This fix resolves an issue where opening the "Add to dashboard" dialog would permanently delete all version history from a spreadsheet, even if the user cancelled the operation. Users can now safely access the dashboard feature without losing their spreadsheet edit history.
Original PR description
Steps to reproduce: - create a new spreadsheet - edit a few cells to create a few history revisions - click on menu File > Add to dashboard - close the dialog (you don't even need to actually create the dashboard) - open the history: File > See version history => all the history is gone Task: 3850102
This update fixes how helpdesk ticket confirmation emails are grouped in customer inboxes. The system now uses the correct email field to ensure all related ticket responses appear together, improving the customer experience when managing support conversations.
Original PR description
Follow-up of 0fd53102589e2bdc4d4a257f367a37eca88604c8 The mail template 'Helpdesk: Ticket Received' should also use the `name` instead of the `display_name` for emails all emails to be properly grouped. opw-3748509
This fix resolves an issue where scanning a different product in the barcode app during picking would lose the connection to the original sales order. The barcode app now properly tracks which sales order a picking belongs to, ensuring all products scanned are correctly linked to the right order and backorders are created properly.
Original PR description
Steps to reproduce: - Confirm an SO with a storable product - in barcode app open the created picking - Scan a different product confirm the picking and create a backorder Bug: the new product is not added to the SO and the original picking isn't linked the SO anymore Fix: when new moves are created in the inventory app default_picking_id is set in the context and is used in _default_group_id to set the group do the same for the barcode app opw-3644773 Forward-Port-Of: odoo/enterprise#60133 Forward-Port-Of: odoo/enterprise#57408
Users were unable to select different email templates when creating follow-up reminders for customers. The template dropdown only showed the currently configured template, making it impossible to change or re-select templates. This fix ensures the system properly recognizes available templates by setting the correct default model type for template filtering.
Original PR description
## Issue:
- When trying to select any new email template on follow up reports, it will only display the current template (the one configured in the followup level that the customer is currently in), and if you delete it, it's impossible to select one again.
## Steps To Reproduce:
- accounting > Follow-up reports.
- On a report click on FOLLOW UP.
- Notice missing templates in Content Template.
## Solution:
- The template_id field's domain is defined as `domain="[('model', '=', render_model)]"`, which filters based on render_model. However, it was not functioning correctly because the computation for `render_model` was not being triggered.
- To resolve this issue, I set 'res.partner' as the default render_model in the `default_get`.
opw-3776312
Forward-Port-Of: odoo/enterprise#58400This update fixes how taxes are calculated on product prices in the online store to match the standard sales process. Previously, the website store used an older tax calculation method that didn't handle all tax scenarios correctly, particularly when taxes were included in prices. Now all tax calculations use a single, more reliable method that properly handles complex tax situations.
Original PR description
Standard `sale` tax flows rely on `_get_tax_included_price_unit`, whereas part of `website_sale` flows do, while another part relies on `_fix_tax_included_price_company`, which doesn't handle some advanced cases (fiscal position mapping of price_included taxes). This commit drops the use of `_fix_tax_included_price_company` in website_sale, to only use the newest API of `_get_tax_included_price_unit`, supposed to handle more cases. Also makes all taxes computation go through a single entry point, `_apply_taxes_to_price`, already used for `combination_info` logic (/shop/product), but not in `_get_sales_prices` (/shop page). opw-3700803 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a problem where Afterpay payments processed through Stripe were failing due to incorrect shipping address information. The fix ensures that accurate shipping address details from orders or invoices are properly sent to Stripe, improving transaction success rates for customers using Afterpay as a payment method.
Original PR description
Resolves an issue with Afterpay via Stripe not receiving correct shipping address details, causing transaction failures. Now, ensures shipping address from the order or invoice is accurately sent to Stripe if we have it. backport of this PR: #157828 opw-3419984
This update fixes a display issue on mobile devices where product cards in the online shop would overflow when showing large prices alongside action buttons like "Add to Cart" or "Add to Wishlist". The fix allows the card content to wrap naturally to multiple lines, ensuring a better shopping experience on smaller screens.
Original PR description
In mobile, having a somewhat 'large price' (like a few thousands currency units) can cause the bottom of the card to overflow (esp. if buttons like 'add to card' or 'add to wishlist' are present). This commit modifies the card template so that content is normally spaced and can wrap to a new line if need be. opw-3706637
Users can now add spaces at the end of link labels without experiencing cursor flickering. This fix resolves a frustrating issue where the text editor would prevent users from typing spaces at the end of link text, improving the overall editing experience when creating and modifying links.
Original PR description
Current behavior before PR: The cursor kept on flickering when attempting to enter a space at the end of label text field of a link resulting in not being able to add space at all. Desired behavior after PR is merged: Now, it's possible to add spaces at the end of a link label. task-3820250 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160661 Forward-Port-Of: odoo/odoo#160060
This fix corrects a rounding issue that occurred when creating downpayments on sales orders with multiple line items. Previously, the system would round the downpayment amount separately for each line, causing small rounding errors to accumulate and result in incorrect total amounts (e.g., 840.01 instead of 840.00). The fix now calculates the downpayment amount correctly by rounding once at the end rather than line-by-line.
Original PR description
Create a SO with the following lines: 1. Price Unit 10000, tax 20% 2. Price Unit 10000, tax 20% 3. Price Unit 10000, tax 20% 4. Price Unit 50, tax 20% Confirm, Create a downpayment of 840.0 Check the downpayment Issue: Amount will be 840.01 This occurs because we compute the downpayment values aggregating so line amounts line by line, each time multiplying for the downpayment percentage and rounding the result. Over multiple lines this mechanism may accumulate a rounding error. opw-3812925 Forward-Port-Of: odoo/odoo#160662 Forward-Port-Of: odoo/odoo#160521
When creating a purchase order with a product that has multiple vendor options, the product description was incorrectly showing information from all vendor lines instead of just the selected vendor. This fix ensures the product description displays only the information from the specific vendor chosen for that purchase order.
Original PR description
Currently, when creating a purchase order, if the product has multiple vendor lines (with the vendor selected on the PO), the product description uses information from all the vendor lines; instead…
Currently, when creating a purchase order, if the product has multiple vendor lines (with the vendor selected on the PO), the product description uses information from all the vendor lines; instead of using information from the vendor line that is used for the price.
Steps to reproduce:
-------------------
* Go to the **Purchase** App
* Go to **Products**
* Select any product
* Select the **Purchase** tab
* Add `Vendor Product Name` and `Vendor Product Code` in additional line fields
* Add two vendor lines
* Line 1:
`Vendor`: Vendor1
`Vendor Product Name`: P1
`Vendor Product Code`: A
`Price`: 1
* Line 2:
`Vendor`: Vendor 1
`Vendor Product Name`: P1 bis
`Vendor Product Code`: B
`Price`: 5
* Select **Orders** > **Request for quotation**
* Create a new quotation
* Select Vendor 1, add the product for which we just added the two vendor lines
> **Observation**: The description of the product shows information from both vendor lines added.
Why the fix:
------------
This behavior was introduced when `name_get` was removed to use `dispay_name` instead.
* https://github.com/odoo/odoo/pull/122085/commits/a8b15c7ab5e2d850d0551a6eb4213bb20a30b210
* https://github.com/odoo/odoo/pull/122085/commits/a8b15c7ab5e2d850d0551a6eb4213bb20a30b210
When adding a product to the purchase order, the onchange on `product_id` is called. The onchange calls the function `_product_id_change`, which itself calls `_get_product_purchase_description`. https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/purchase/models/purchase.py#L1224 https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/purchase/models/purchase.py#L1401-L1407
The line `name = product_lang.display_name` calls the function `_compute_display_name`.
* We do have a parnter_id in the context as we have selected a vendor on the purchase order. https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/product/models/product_product.py#L434
* We don't have a supplierinfo in the context yet but we have multiple supplierinfo with the same partner_id. https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/product/models/product_product.py#L466-L467 Here we thus have 2 sellers.
* Ultimately, the display name joins the different display names computer for each seller. https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/product/models/product_product.py#L473-L483
Coming back to the line `self.name = self._get_product_purchase_description(product_lang)`, we now have the name of the purchase order line set as the concatenation of display names from the supplierinfo, i.e `'[A] P1, [B] P1 bis'`.
Once the onchange is called, the function `_compute_price_unit_and_date_planned_and_name` is being called. https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/purchase/models/purchase.py#L1295-L1302 In the current state, we do not meet the if condition. Indeed, the line has a name (`'[A] P1, [B] P1 bis'`) but it isn't in the default_names (`['[A] P1', '[B] P1 bis']`). It somehow corresponds to a setting where the name of the purchase order line was setup by the user.
With this current fix, the call to `_product_id_change` will set the name of the line with the product information from the company; and not the partner/seller. We also need to add this name to the `default_names` in `_compute_price_unit_and_date_planned_and_name` so that the description gets recomputed with regards to the seller, if any.
I tested the scenario where:
* The second supplierinfo has a smaller unit price when buying 10 products. On the sale order line, when I set the quantity to 20, the unit price is updated as well as the description. The description is updated as `line.name` is indeed in `default_names`.
opw-3802182
Forward-Port-Of: odoo/odoo#158398Fixed an issue where clicking the "Go to Website" button from the backend was incorrectly redirecting users to the website homepage instead of the specific course, event, or slide page. This problem occurred when users were accessing the system from a different domain than the configured base URL. The fix ensures users are taken to the correct page they intended to view.
Original PR description
How to reproduce: - Install website_slides with demo data - Log in from localhost - Log in from dev.localhost - Switch to localhost - (The system property web.base.url is http://dev.localhost:8069…
How to reproduce: - Install website_slides with demo data - Log in from localhost - Log in from dev.localhost - Switch to localhost - (The system property web.base.url is http://dev.localhost:8069 but we are on localhost) - Go to a course in the back end and click on “Go to website” button You are redirected to the frontend website home page instead of the course home page. This fix solves the problem. Afer correcting this error for the courses (slide.channel), we have found the same problem for: - event.sponsor - event.meeting.room - slide.slide So we apply the same correction for them. Technical note: the button "Go to website" uses the open_website_url method of WebsitePublishedMultiMixin that relies on website_url. That method expects a relative URL in the computed field website_url and not an absolute one (actually, the method already handle adding the website domain, so it expect the relative part). The problem is that the compute method for the field website_url of channel compute an absolute URL. The consequence is that the user is redirected to the home page instead of the course page (by WebsitePreview, see get path method). In stable, we cannot change easily website_url to make it relative as it is used in other of places (ex.: if we make it relative the share link in the sidebar on the frontend is relative which is not correct and in mail template, the URL might not be correct as the mail system append the default domain for relative URLs). So instead, we override open_website_url to use a relative URL when the website is not defined. If the website is defined on the course, we call the super implementation because a domain change might be required. Note that by doing that, we duplicate the code of _compute_website_url in open_website_url but making the URL relative instead of absolute. So we should clean that in master. Task-3635856 Forward-Port-Of: odoo/odoo#160114 Forward-Port-Of: odoo/odoo#148103
Portal users who are subcontractors were incorrectly seeing unpublished products in the online shop. This fix ensures that portal users can only view published products, while still maintaining their access to subcontracting features. The change prevents unpublished products from appearing in shop searches and listings for non-internal users.
Original PR description
### Steps to reproduce: - Activate Subcontracting in the settings. - Create a storable product - Create a BOM of type "subcontracting" where the subcontractor is a Portal user (e.g. Joel Willis) for…
### Steps to reproduce: - Activate Subcontracting in the settings. - Create a storable product - Create a BOM of type "subcontracting" where the subcontractor is a Portal user (e.g. Joel Willis) for that product. - Log out and connect as your portal user. - Go to the website shop and search your product. ### Expected behavior: The portal user should only be able to see the published products. ### Current behavior: The portal user sees unpublished products for which he is subcontractor. ### Cause of the issue: The commit 99b56ec has introduced a subcontracting portal. In order for portal users to be able to interact with product templates, the following rule was added to the "base.group_portal": https://github.com/odoo/odoo/blame/f0a0d596ab716c96de38a5c0f837da2924338d7b/addons/mrp_subcontracting/security/mrp_subcontracting_security.xml#L120-L131 When you go to the website shop, the records displayed in the shop will be computed here: https://github.com/odoo/odoo/blob/1c321cd1fe0aabd9cd92c13cd1eae604e5817ae0/addons/website_sale/controllers/main.py#L348 https://github.com/odoo/odoo/blob/f0a0d596ab716c96de38a5c0f837da2924338d7b/addons/website/models/mixins.py#L353-L357 However, during this call, the "ir.rule" added for portal users will be added to the SQL query here: https://github.com/odoo/odoo/blob/1c321cd1fe0aabd9cd92c13cd1eae604e5817ae0/odoo/models.py#L4682 As such, products (enven if unpublished) for which the portal user is a subcontractor will be fetched and displayed in the shop. ### Fix: Since the "ir.rule" can not be changed only for flows involving the `website_sale` application, we propose to make a change similar to commit b1f6171 whose purpose is to hide unpublished products for non internal users: https://github.com/odoo/odoo/blob/1c321cd1fe0aabd9cd92c13cd1eae604e5817ae0/addons/website_sale/models/product_template.py#L105-L108 opw-3768845 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159420
This update fixes an issue preventing SMS messages from being sent to partners with mobile phone numbers from Panama. The fix addresses a compatibility problem with the phone number validation library by applying a targeted patch to recognize Panama's updated mobile phone number format.
Original PR description
Current behavior:
---
Cannot send SMS to a partner that has a mobile phone number from Panama.
Steps to reproduce:
---
```python
# 6198 5462 is a valid phone number
parsed = phonenumbers.parse('6198 5462', region='PA')
is_valid = phonenumbers.is_valid_number(parsed)
is_valid == False
```
Cause of the issue:
---
Old versions of phonenumbers (external library) are not updated
to Panamas mobile phone numbers system change.
Fix:
---
Monkey patched the library
Similar as: https://github.com/odoo/odoo/commit/b21df8797141dac9f2cf0315658a08a238849f5b
opw-3682631
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#159970
Forward-Port-Of: odoo/odoo#156969This fix prevents users from changing a product's type when there are pending inventory transactions in their company. Previously, users could bypass this restriction in multi-company setups, which could cause data integrity issues. The fix ensures proper access controls are applied regardless of company configuration.
Original PR description
Description of the issue/feature this PR addresses: Without sudo, an user in a company can change the type even if somes not done stock.move.line exists. @amoyaux --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where scanning a different product in the barcode app during picking would lose the connection to the original sales order. When creating backorders, new products weren't being properly linked to their sales orders. The fix ensures that product movements are correctly associated with their procurement groups, maintaining the relationship between picked items and customer orders.
Original PR description
Steps to reproduce: - Confirm an SO with a storable product - in barcode app open the created picking - Scan a different product confirm the picking and create a backorder Bug: the new product is not added to the SO and the original picking isn't linked the SO anymore Fix: when new moves are created in the inventory app default_picking_id is set in the context and is used in _default_group_id to set the group set the context key during the write to ensure moves are created with the correct group test: https://github.com/odoo/enterprise/pull/57408 opw-3644773 Forward-Port-Of: odoo/odoo#160596 Forward-Port-Of: odoo/odoo#157255
This fix prevents users from accidentally editing kit product quantities directly in the inventory system. Previously, when managing inventory for kit products (products made up of components), the system would allow direct editing of the kit quantity even though only component quantities should be adjustable. Now the system enforces this rule, ensuring inventory data stays consistent.
Original PR description
Steps to reproduce: - Create a storable kit product - Update on hand quantity: only the components are displayed(correct behavior) - In Inventory tab open Inventory Adjustement - Possible to edit kit quantity Bug: In the product tab when trying to update qty the kit product is replaced with its components instead but it is still Possible to edit kit quantity directly in the inventory app Fix: introduced python constraint to prevent user from directly editing the kit product qty opw-3681703 Forward-Port-Of: odoo/odoo#160787 Forward-Port-Of: odoo/odoo#157061