Friday, March 28, 2025
22 changes · saas-17.4
Resolved issues and error corrections
When duplicate records with activity history are merged, the merge is now recorded in the chatter of the affected records. This restores visibility for users so teams can understand when and why records were combined.
Original PR description
**Issue** When mergring two records with a chatter (e.g. Tasks), no log note appears in the chatter of the destination or source records. **Cause** The template changed modules when `data_cleaning` and `data_merge` were merged in 4fc497861fbefee7f4761c3341a3c2bd289edb31 opw-4513322
Miscellaneous changes
The E-invoicing is mandatory in Jordan, and most of the users need it. So, it's simpler if they have it already installed when they install the base module. task-4669464 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203266
Original PR description
The E-invoicing is mandatory in Jordan, and most of the users need it. So, it's simpler if they have it already installed when they install the base module. task-4669464 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203266
The CSS of global filters in dashboard was broken if there was too many filters or if a filter was too tall (e.g. relation filter with many options). This commit fixes those issues. Now the filters are wrapped in multiple lines if there are too many filters. That mean that we have to define a fixed width for the filters, otherwise the filters won't be aligned over multiple lines and will be ugly. The commit also adds max-height and overflow on the filters to avoid the filters being too tall.
Original PR description
The CSS of global filters in dashboard was broken if there was too many filters or if a filter was too tall (e.g. relation filter with many options). This commit fixes those issues. Now the filters…
The CSS of global filters in dashboard was broken if there was too many filters or if a filter was too tall (e.g. relation filter with many options). This commit fixes those issues. Now the filters are wrapped in multiple lines if there are too many filters. That mean that we have to define a fixed width for the filters, otherwise the filters won't be aligned over multiple lines and will be ugly. The commit also adds max-height and overflow on the filters to avoid the filters being too tall. It also changes the style of the `Select period...` option to be more placeholder-like. Note: the same fix cannot easily be done in 16.0, because there the date picker isn't a popover there, this adding `overflow` to the CSS breaks it. Task: [4624108](https://www.odoo.com/web#id=4624108&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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#201391
Steps: - install `contacts` and `sale_management` - Open a contact in a form view and add a sub-contact - Don't fill contact name field - Save & Close - Go to Quotations - Select this new contact as Customer (it should have a name like Parent contact, Other Address) - Add any product - Save - Click on `Preview` - Click on `Sign & Pay` - Traceback When there is no signature name, `NameAndSignature` does not set `resetSignature` and `getSignatureImage` on `this.signature`. So after `
Original PR description
Steps: - install `contacts` and `sale_management` - Open a contact in a form view and add a sub-contact - Don't fill contact name field - Save & Close - Go to Quotations - Select this new contact as Customer (it should have a name like Parent contact, Other Address) - Add any product - Save - Click on `Preview` - Click on `Sign & Pay` - Traceback When there is no signature name, `NameAndSignature` does not set `resetSignature` and `getSignatureImage` on `this.signature`. So after `SignatureForm` initialization, `onMounted` raise a traceback, because it calls directly `this.signature.resetSignature`. This commit adds default functions to `resetSignature` and `getSignatureImage` to prevent the crash. In addition to the this fix, I added a fallback to the default name on signature form to `sale_order.partner_id.commercial_partner_id.name` if `sale_order.partner_id.name` is not set. opw-4504223 Forward-Port-Of: odoo/odoo#202318
Issue ----- When in a branch company, products from the parent company are not visible in the catalog. Steps to reproduce ----- - Install "Sales" app - Go to Settings > Users & Companies > Companies - Create the "Main Company" Company - Add Branches to "Main Company" - Switch companies to "Main Company" - Create a product "A" and set the company to "Main Company" - Switch to one of the branch companies - Create a new Quotation -> The product is displayed from the dropdown li
Original PR description
Issue ----- When in a branch company, products from the parent company are not visible in the catalog. Steps to reproduce ----- - Install "Sales" app - Go to Settings > Users & Companies > Companies…
Issue
-----
When in a branch company, products from the parent company are not visible in the catalog.
Steps to reproduce
-----
- Install "Sales" app
- Go to Settings > Users & Companies > Companies
- Create the "Main Company" Company
- Add Branches to "Main Company"
- Switch companies to "Main Company"
- Create a product "A" and set the company to "Main Company"
- Switch to one of the branch companies
- Create a new Quotation
-> The product is displayed from the dropdown list but not in the Catalog
Cause
-----
Branches have a different id from their parent company. The search domain only includes the current companies but not its' parents.
We can simply include the parent company in `_get_product_catalog_domain` (of the `product_catalog_mixin` class).
The new test was crashing when trying to open the product catalog. This crash was caused by the `buttonString` variable of the `kanban_controller` not being a string as expected but rather a promise. This comes from the override of the `_defineButtonContent` method present in the Account module (which is required by Sale). In the override, `buttonString` takes the value of the super call but since it is an asynchronous setter function, we can just call it.
-----
Ticket:
opw-4472464
Forward-Port-Of: odoo/odoo#197620Before this commit, the IM status icon shown when the user is homeworking won't always be precise. This happens because of the IM status refactoring (https://github.com/odoo/odoo/pull/174814). Steps to reproduce: 1. Setup user Marc Demo as homeworking in the current day 2. As Marc Demo open Discuss 3. As Mitchell Admin open the conversation with Marc Demo -> the correct home online icon is shown 4. As Marc Demo close all Odoo tabs -> user goes offline and Mitchell Admin sees the correct o
Original PR description
Before this commit, the IM status icon shown when the user is homeworking won't always be precise. This happens because of the IM status refactoring (https://github.com/odoo/odoo/pull/174814). Steps…
Before this commit, the IM status icon shown when the user is homeworking won't always be precise. This happens because of the IM status refactoring (https://github.com/odoo/odoo/pull/174814). Steps to reproduce: 1. Setup user Marc Demo as homeworking in the current day 2. As Marc Demo open Discuss 3. As Mitchell Admin open the conversation with Marc Demo -> the correct home online icon is shown 4. As Marc Demo close all Odoo tabs -> user goes offline and Mitchell Admin sees the correct offline icon 5. As Marc Demo reopen Discuss -> Mitchell Admin sees the circle icon instead of the home icon This commit fixes the issue by sending the user im_status information directly from its indentity model (`res.partner` or `mail.guest`) in the `bus.bus/im_status_updated` notification payload. This ensures that any overrides on the `im_status` field will be taken into consideration without having to re-establish the override client side. `presence_status` now represents the status value of the presence model, while `im_status` represents the status value of the identity model. Forward-Port-Of: odoo/odoo#199936
…ring orders **Issue:** When using a language other than English and setting the Manufacturing Order name field to read-only via Studio, the name is not automatically converted into a unique value. As a result, after saving the first order (which defaults to "New"), any subsequent order creation fails with an error, stating that the name must be unique. **Steps to Reproduce:** 1. Install the Manufacturing app. 2. Install the Studio app. 3. Change the language to one other than English.
Original PR description
…ring orders **Issue:** When using a language other than English and setting the Manufacturing Order name field to read-only via Studio, the name is not automatically converted into a unique value.…
…ring orders
**Issue:**
When using a language other than English and setting the Manufacturing Order name field to read-only via Studio, the name is not automatically converted into a unique value. As a result, after saving the first order (which defaults to "New"), any subsequent order creation fails with an error, stating that the name must be unique.
**Steps to Reproduce:**
1. Install the Manufacturing app.
2. Install the Studio app.
3. Change the language to one other than English.
4. Navigate to Manufacturing > Operations > Manufacturing Orders.
5. Create a new Manufacturing Order.
6. Open Studio and set the name field to read-only.
7. Save the first Manufacturing Order with the default name ("New").
8. Attempt to create another Manufacturing Order.
9. Error: The system prevents saving due to a duplicate name.
Expected Behavior: The Manufacturing Order name should be automatically updated to a unique value upon saving, regardless of the selected language.
Actual Behavior: The name remains "New", but it is not translated when using a different language. Since the name field is set to read-only, the system does not trigger the automatic conversion to a unique name. As a result, when attempting to create another order, the system detects a duplicate and prevents saving due to a name conflict.
**Root Cause**
The system always sets the default name to "New" in English. However, the automatic name conversion process expects a translated name before updating it to a unique value. Because "New" remains untranslated, the system does not recognize it as a placeholder and fails to convert it.
**Fix**
Modify the default value of the name field to use a localized translation like it’s done for the sale order https://github.com/odoo/odoo/blob/7bc38562f1988ba15525c04168e30c06a8f1d33c/addons/sale/models/sale_order.py#L55. This ensures that the default name is translated according to the user's language, allowing the system to properly detect and replace it with a unique value when saving.
Opw-4553109
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#200138Currently when the user upload an e-invoice in compatible format, accounting information will be extracted to automatically create the bill and associated records. While creating the parnter, however, only basic information is filled in (name, vat, email, phone, country), leaving out the address Steps to reproduce: - Import an xml bill with complete partner info Issue: Only some partner fields are imported opw-4488308 Forward-Port-Of: odoo/odoo#203572 Forward-Port-Of: odoo/odoo#2017
Original PR description
Currently when the user upload an e-invoice in compatible format, accounting information will be extracted to automatically create the bill and associated records. While creating the parnter, however, only basic information is filled in (name, vat, email, phone, country), leaving out the address Steps to reproduce: - Import an xml bill with complete partner info Issue: Only some partner fields are imported opw-4488308 Forward-Port-Of: odoo/odoo#203572 Forward-Port-Of: odoo/odoo#201760
Ensure only Peppol-type proxies are retrieved when performing Peppol operations. Steps to reproduce: - Install Peppol and IT EDI - Register Peppol and IT EDI users - In Accounting, on the Vendor Bill journal, click "Fetch from Peppol" Odoo will attempt requests for all users, including an invalid call to 'False/api/peppol/1/get_all_documents'. This is not an issue in V17 but causes problems in V18. This fix makes sense in both versions as it prevents unnecessary requests a
Original PR description
Ensure only Peppol-type proxies are retrieved when performing Peppol operations. Steps to reproduce: - Install Peppol and IT EDI - Register Peppol and IT EDI users - In Accounting, on the Vendor Bill journal, click "Fetch from Peppol" Odoo will attempt requests for all users, including an invalid call to 'False/api/peppol/1/get_all_documents'. This is not an issue in V17 but causes problems in V18. This fix makes sense in both versions as it prevents unnecessary requests and avoids error messages in the logs. opw-4624633 Forward-Port-Of: odoo/odoo#203734
* follow markdown guidelines * add section for security reports --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143761
Original PR description
* follow markdown guidelines * add section for security reports --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143761
**Current behavior before PR:** - Rotating a cropped image reset the cropper to cover the entire image. - When saving the record, all attributes not in the safe_attrs list were sanitized. As a result, if the record contained a cropped image, its crop-related attributes were also sanitized. Consequently, when the cropper was reopened, the container displayed the entire image instead of the cropped version. **Desired behavior after PR is merged:** - The cropper now retains
Original PR description
**Current behavior before PR:** - Rotating a cropped image reset the cropper to cover the entire image. - When saving the record, all attributes not in the safe_attrs list were sanitized. As a result, if the record contained a cropped image, its crop-related attributes were also sanitized. Consequently, when the cropper was reopened, the container displayed the entire image instead of the cropped version. **Desired behavior after PR is merged:** - The cropper now retains its size when rotating a cropped image, maintaining the original crop area. - Image attributes such as data-width, data-height, data-scale-x, data-scale-y, data-x, and data-y are no longer sanitized during the save process. This ensures that when the cropper is reopened for a cropped image, the container correctly displays only the cropped portion of the image, rather than the entire image. task-4290693 Forward-Port-Of: odoo/odoo#203518 Forward-Port-Of: odoo/odoo#186864
Description of the issue/feature this PR addresses: The system assigns 8 hours of leave to contractors by default. This applies even if their schedule is set to 0 hours per week. As a result, contractors may receive holiday pay like full-timers. For example, a snowplow contractor with 0 hours in summer could wrongly get a full day's holiday pay during that period.     Current behavior before PR: A employee with 0 Hours/Week Working Schedule will receive max hours of a time off allocation.  Desired behavior after PR is merged: A employee with 0 Hours/Week Working Schedule will not receive max hours of a time off allocation. And no time off allocation should be created. opw-4464317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203805 Forward-Port-Of: odoo/odoo#202610
## Background In Mexico, all accounts need to follow a pattern XXX.XX.XX or XXX.XX.XXX where additionally the first five digits must belong to a list of prefixes published by the SAT. At the moment, several accounts created by default don't match the CoA pattern: - 999000001 Cash Difference Gain - 999000002 Cash Difference Loss. - 999300000 Cash Discount Loss - 999400000 Cash Discount Gain - 999999 Undistributed Profits/Losses ## Fix Given correct codes to the existing accou
Original PR description
## Background In Mexico, all accounts need to follow a pattern XXX.XX.XX or XXX.XX.XXX where additionally the first five digits must belong to a list of prefixes published by the SAT. At the moment,…
## Background In Mexico, all accounts need to follow a pattern XXX.XX.XX or XXX.XX.XXX where additionally the first five digits must belong to a list of prefixes published by the SAT. At the moment, several accounts created by default don't match the CoA pattern: - 999000001 Cash Difference Gain - 999000002 Cash Difference Loss. - 999300000 Cash Discount Loss - 999400000 Cash Discount Gain - 999999 Undistributed Profits/Losses ## Fix Given correct codes to the existing accounts and modifying data for some records:. | Account | New code | New name | New Account type | |-------------------------------------|-----------|------------------------------------------------------------------------------|------------------| | 999000001 Cash Difference Gain | 403.01.01 | Other Income | ~ | | 999000002 Cash Difference Loss | 601.84.02 | ~ | ~ | | 999300000 Cash Discount Loss | 402.01.01 | Returns, discounts or bonuses over sales and/or services at the general rate | other income | | 999400000 Cash Discount Gain | 503.01.01 | Returns, discounts or bonuses over purchases | ~ | | 999999 Undistributed Profits/Losses | 305.01.01 | Uncut Result | ~ | --- opw-4288080 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196852
Serbia has implemented a mandatory e-invoicing system named eFaktura. This module utilizes the eFaktura API to enable users to submit their e-invoices. task-4004913 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186235
Original PR description
Serbia has implemented a mandatory e-invoicing system named eFaktura. This module utilizes the eFaktura API to enable users to submit their e-invoices. task-4004913 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186235
Description of the issue this commit addresses: The Italian localization currently doesn't allow users to export the periodic tax report to xml format. This feature is missing. --- Desired behavior after the commit is merged: The Italian monthly tax report has a button that allows the user to export the report to an xml format. --- Enterprise PR: https://github.com/odoo/enterprise/pull/80009 task-4507942 --- I confirm I have signed the CLA and read the PR guidelines at w
Original PR description
Description of the issue this commit addresses: The Italian localization currently doesn't allow users to export the periodic tax report to xml format. This feature is missing. --- Desired behavior after the commit is merged: The Italian monthly tax report has a button that allows the user to export the report to an xml format. --- Enterprise PR: https://github.com/odoo/enterprise/pull/80009 task-4507942 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195948
Before this commit: The product snippet with filter "Latest Viewed Product" selected showed products in a random order. This was caused by a `search([('id', 'in', ids)])` which does not enforce the order of `ids` in the returned set. After this commit: The order returned follows the intended "Last Viewed Product" order. task-3916458 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200196
Original PR description
Before this commit:
The product snippet with filter "Latest Viewed Product" selected showed products in a random order. This was caused by a
`search([('id', 'in', ids)])` which does not enforce the order of `ids` in the returned set.
After this commit:
The order returned follows the intended "Last Viewed Product" order.
task-3916458
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#200196Steps to reproduce: 1. Create a new storable product 2. In the product's description, insert a base64 image - Pasting a (big) image from the clipboard insert it as base64 in <16.3 - Or do it manually by modifying the HTML 3. Create a Sale Order with the product 4. Validate the sale order ### Before this commit: During the Stock Picking creation, the picking's description is taken from the product's description and converted into plaintext. It replaces the images by some tex
Original PR description
Steps to reproduce:
1. Create a new storable product
2. In the product's description, insert a base64 image
- Pasting a (big) image from the clipboard insert it as base64 in <16.3
- Or do it manually by modifying the HTML
3. Create a Sale Order with the product
4. Validate the sale order
### Before this commit:
During the Stock Picking creation, the picking's description is taken from the product's description and converted into plaintext. It replaces the images by some text, but the Regex searching for a name in the src attribute, has a terrible backtracking (due to the lookahead).
### After this commit:
Searching for the filename does not make sense when dealing with base64; therefore, this commit skips this feature to prevent intensive CPU usage.
opw-4674295
Forward-Port-Of: odoo/odoo#203738Versions -------- - 17.0 Doesn't occur in later versions due to improved rounding utils. Steps ----- 1. Set up a sales order with a total of $286.90; 2. generate a payment link; 3. open payment link in private window. Issue ----- Error: The provided parameters are invalid. Cause ----- Commit c59a47da7400 added a `float_repr` to round the amount used in the url parameters. Issue occurs because this number can be different from the value used to generate the token (286.90 vs
Original PR description
Versions -------- - 17.0 Doesn't occur in later versions due to improved rounding utils. Steps ----- 1. Set up a sales order with a total of $286.90; 2. generate a payment link; 3. open payment link in private window. Issue ----- Error: The provided parameters are invalid. Cause ----- Commit c59a47da7400 added a `float_repr` to round the amount used in the url parameters. Issue occurs because this number can be different from the value used to generate the token (286.90 vs 286.90000000000003), making their hashes different. Solution -------- Use `float_repr` when generating a token, and in both instances, convert the string back into a float so they don't have mismatching zeroes at the end. opw-4669839 Forward-Port-Of: odoo/odoo#203785
Since 17.0, and before this commit, when the user navigates from an account report to another page and then comes back to the report through the breadcrumb, the user is brought to the top of the report. In 16.0, the user would be brought to the same position they were looking at. This commit brings this behavior back. task-4578468 Forward-Port-Of: odoo/enterprise#82072
Original PR description
Since 17.0, and before this commit, when the user navigates from an account report to another page and then comes back to the report through the breadcrumb, the user is brought to the top of the report. In 16.0, the user would be brought to the same position they were looking at. This commit brings this behavior back. task-4578468 Forward-Port-Of: odoo/enterprise#82072
#Description A total of 6 test were broken after changes(add/removal) in the accounts of the mexican localization in odoo community, the new expected values for the assesments were updated. Related PR #196852. Forward-Port-Of: odoo/enterprise#81270
Original PR description
#Description A total of 6 test were broken after changes(add/removal) in the accounts of the mexican localization in odoo community, the new expected values for the assesments were updated. Related PR #196852. Forward-Port-Of: odoo/enterprise#81270
Amazon SP-API is dropping support for the `POST_INVENTORY_AVAILABILITY_DATA` feed type. This was previously used in Odoo to synchronize the stock level with Amazon. This commit upgrades the feed api to use the new `JSON_LISTINGS_FEED` as a replacement. This new feed needs new informations that were not stored previously. Since this is a fix targeting stable versions of Odoo, it was decided to store this new inforamtion as a json dictionary in the `amazon.offer.amazon_feed_ref` field.
Original PR description
Amazon SP-API is dropping support for the `POST_INVENTORY_AVAILABILITY_DATA` feed type. This was previously used in Odoo to synchronize the stock level with Amazon. This commit upgrades the feed api to use the new `JSON_LISTINGS_FEED` as a replacement. This new feed needs new informations that were not stored previously. Since this is a fix targeting stable versions of Odoo, it was decided to store this new inforamtion as a json dictionary in the `amazon.offer.amazon_feed_ref` field. task-3820591 Forward-Port-Of: odoo/enterprise#78897
Versions -------- - 17.0+ Steps ----- 1. Have a salesman user without accounting rights; 2. assign user to a subscription; 3. create an invoice for the subscription; 4. assign a different salesman to the subscription; 5. as the initial salesman, try to close the subscription. Issue ----- Depending on the state of the cache, one of two things happen: 1. You get a validation error, saying the subscription has no invoices. 2. You get an access error if the invoice lines exist in t
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a salesman user without accounting rights; 2. assign user to a subscription; 3. create an invoice for the subscription; 4. assign a different salesman to the subscription; 5. as the initial salesman, try to close the subscription. Issue ----- Depending on the state of the cache, one of two things happen: 1. You get a validation error, saying the subscription has no invoices. 2. You get an access error if the invoice lines exist in the cache. Cause ----- The salesman only has read access to their own invoices. The first error happens because they cannot search for others' invoices. The second error happens because they cannot read the cached records. Solution -------- Use `sudo` to check for existing invoices. opw-4554639 Forward-Port-Of: odoo/enterprise#82243