Daily updates from Odoo
Monday, December 2, 2024
11 changes · saas-17.2
Miscellaneous changes
When uploading invoices in EFFF format taxes were not applied even though the XML file correctly defined them. The issue came from not taking the `<cbc:Percent>` tag into account when outside of `{*}TaxCategory` tag. This commit adds support both structures by checking for the `<cbc:Percent>` tag within `<cac:TaxSubtotal>` and outside of it. task-4348339 Forward-Port-Of: odoo/odoo#188859 Forward-Port-Of: odoo/odoo#188062
Original PR description
When uploading invoices in EFFF format taxes were not applied even though the XML file correctly defined them.
The issue came from not taking the `<cbc:Percent>` tag into account when outside of `{*}TaxCategory` tag.
This commit adds support both structures by
checking for the `<cbc:Percent>`
tag within `<cac:TaxSubtotal>` and outside of it.
task-4348339
Forward-Port-Of: odoo/odoo#188859
Forward-Port-Of: odoo/odoo#188062Description of the issue this PR addresses: Current behavior before PR: When pasting content containing `<div>` elements with inline child nodes, the `<div>` tags were unwrapped, causing all inline content within multiple `<div>` elements to merge into a single line. Desired behavior after PR is merged: `<div>` elements are now converted to `<p>` tags. This preserves the block structure and ensures inline content within each `<div>` remains in original format. task-4309745 ---
Original PR description
Description of the issue this PR addresses: Current behavior before PR: When pasting content containing `<div>` elements with inline child nodes, the `<div>` tags were unwrapped, causing all inline content within multiple `<div>` elements to merge into a single line. Desired behavior after PR is merged: `<div>` elements are now converted to `<p>` tags. This preserves the block structure and ensures inline content within each `<div>` remains in original format. task-4309745 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186862
Improve access related tests for mail.message and their sub models. Currently tests are dependent on discuss.channel model, and not always written in a clear way. Understanding the purpose of each test is not crystal clear. We now use a test model with simple rules, defined in test_mail addon. It allows to simulate models with * public access; * portal access; * internal access; * admin access; using ACLs and ir.rules. Tests are rewritten to be more concise and precise an
Original PR description
Improve access related tests for mail.message and their sub models. Currently tests are dependent on discuss.channel model, and not always written in a clear way. Understanding the purpose of each test is not crystal clear. We now use a test model with simple rules, defined in test_mail addon. It allows to simulate models with * public access; * portal access; * internal access; * admin access; using ACLs and ir.rules. Tests are rewritten to be more concise and precise and use new models. This is done in stable to keep coherency in tests codebase. It also eases writing bugfixes as tests won't have to be modified during forward port process. Finally it allows to backport improvements or fixes in later versions if it applies to previous versions. Task-4320561 Forward-Port-Of: odoo/odoo#189120 Forward-Port-Of: odoo/odoo#186394
Improvements for PR https://github.com/odoo/odoo/pull/130806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189238
Original PR description
Improvements for PR https://github.com/odoo/odoo/pull/130806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189238
The file viewer tries to show the document from the url obtained from the defaultSource function in file_model.js. This function builds the url using urlRoute. Before the fix, the urlRoute is the url from the attachment. This causes the PDF viewer to fail because it has a same-origin policy. This fix avoids to use the url to the one from the attachment's url directly so that the viewer can show the document correctly with the computed urlRoute. The attachment url does not need to be use
Original PR description
The file viewer tries to show the document from the url obtained from the defaultSource function in file_model.js. This function builds the url using urlRoute. Before the fix, the urlRoute is the url from the attachment. This causes the PDF viewer to fail because it has a same-origin policy. This fix avoids to use the url to the one from the attachment's url directly so that the viewer can show the document correctly with the computed urlRoute. The attachment url does not need to be used at all, as the odoo server will properly direct. Forward-Port-Of: odoo/odoo#187970
When generating the mail alias for a journal, we check whether the name of the company is already in it, and add it if it's not. The problem is before this commit, we didn't sanitize the name of the company to do that check, so a company name with spaces or accents would never be detected as part of the alias, and could end up being in it twice. This caused issues in the Winbooks import of one customer, who ended up with duplicate aliases because of that, since the journal code was not proper
Original PR description
When generating the mail alias for a journal, we check whether the name of the company is already in it, and add it if it's not. The problem is before this commit, we didn't sanitize the name of the company to do that check, so a company name with spaces or accents would never be detected as part of the alias, and could end up being in it twice. This caused issues in the Winbooks import of one customer, who ended up with duplicate aliases because of that, since the journal code was not properly added to the generated alias while it should, and a duplicate of the company name was put instead. opw-4196597 Forward-Port-Of: odoo/odoo#189149
In this commit, we fix this tour that failed each hour at minute 31 when the tour is runned at this time. The goal is to check the message text content and not the hour it was sent. runbot-error-id~108435 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#189266
Original PR description
In this commit, we fix this tour that failed each hour at minute 31 when the tour is runned at this time. The goal is to check the message text content and not the hour it was sent. runbot-error-id~108435 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#189266
Previously, it was still possible to access a project with an access_token even if that project is no longer in privacy="portal". This was not consistant with the front-end that disable the access to the portal share wizard when privacy is set to anything else than 'portal'. This change remove the token when the privacy is changed at the time of the write() This change is done in the project module because it depends on "portal", and not the other way around. This change can also be
Original PR description
Previously, it was still possible to access a project with an access_token even if that project is no longer in privacy="portal". This was not consistant with the front-end that disable the access to the portal share wizard when privacy is set to anything else than 'portal'. This change remove the token when the privacy is changed at the time of the write() This change is done in the project module because it depends on "portal", and not the other way around. This change can also be used as an invalidation mecanism in case of a token leak. Changing the privacy to 'private' then to 'portal' will allow for an invalidation of the previous token and the creation of new one. opw-4104804 task-4354145 Closes #176177 Forward-Port-Of: odoo/odoo#189218 Forward-Port-Of: odoo/odoo#188264
**Steps to reproduce the bug:** - Create a storable product: - "Finished Product" with the following BoM: - Component: 1 unit of "C1" - Byproducts: - 1 unit of "By-product 1" - 1 unit of "By-product 2" - Create a manufacturing order to produce 5 units of the finished product. - Confirm the MO. - Set the quantity produced to 5 units. - Set the quantity of byproducts to: - By-product 1: 4 units - By-product 2: 3 units - Validate the MO. - Print
Original PR description
**Steps to reproduce the bug:**
- Create a storable product:
- "Finished Product" with the following BoM:
- Component: 1 unit of "C1"
- Byproducts:
- 1 unit of "By-product 1"
- 1 unit of "By-product 2"
- Create a manufacturing order to produce 5 units of the finished product.
- Confirm the MO.
- Set the quantity produced to 5 units.
- Set the quantity of byproducts to:
- By-product 1: 4 units
- By-product 2: 3 units
- Validate the MO.
- Print the cost analysis.
**Problem:**
The reported quantity does not show the actual quantity produced but
instead shows the "to produce" quantity.
opw-4312292
Forward-Port-Of: odoo/odoo#188854Before this commit, when sending a message in full composer to explicit recipients and message contains mentions, the resulting recipients of the message were only mentioned users. Steps to reproduce: - Open a form view with suggested recipient (e.g. any contacts with demo data) - Click "Send message" then full composer button ("expand" button) - Type `@Marc Demo` mention in the full composer text area - Click on "Send" => The new message shows envelope with only "Marc Demo" in the rec
Original PR description
Before this commit, when sending a message in full composer to explicit recipients and message contains mentions, the resulting recipients of the message were only mentioned users. Steps to…
Before this commit, when sending a message in full composer to explicit recipients and message contains mentions, the resulting recipients of the message were only mentioned users.
Steps to reproduce:
- Open a form view with suggested recipient (e.g. any contacts with demo data)
- Click "Send message" then full composer button ("expand" button)
- Type `@Marc Demo` mention in the full composer text area
- Click on "Send"
=> The new message shows envelope with only "Marc Demo" in the recipients, instead of "Marc Demo" and the suggested recipient.
This happens because when making a mention, the code to enrich the `partner_ids` of `mail.compose.message` was basically setting its content with mentions, without taking into account whether there were some explicit values with other means than with `@mention`.
This commit fixes the issue by adding mentions with the current value of `partner_ids`, so that mentions and explicit recipients are the resulting recipients of message as expected
Task-4366608
Forward-Port-Of: odoo/odoo#189187Originally, the inventory adjustment view will attempt to merge quants eventhough this merging is done in the scheduler. In this PR we allow a way to skip the function _quant_tasks which performs merging. This is done through a system parameter. Merging quants has been seen to cause deadlocks in cases where multiple users are visiting the same view at the same time. Skipping this process will make sure to only merge quants through the scheduler. This will speedup opening the quants views and
Original PR description
Originally, the inventory adjustment view will attempt to merge quants eventhough this merging is done in the scheduler. In this PR we allow a way to skip the function _quant_tasks which performs merging. This is done through a system parameter. Merging quants has been seen to cause deadlocks in cases where multiple users are visiting the same view at the same time. Skipping this process will make sure to only merge quants through the scheduler. This will speedup opening the quants views and could also be helpful in debugging. opw-4226821 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189053