Monday, December 2, 2024
18 changes · saas-17.2
Miscellaneous changes
[FIX] account_reports, l10n_*_reports: add explicit ORDER BY to report engines for consistent LIMIT and OFFSET behavior As stated here https://www.postgresql.org/docs/current/queries-limit.html , postgresql requires an explicit ORDER by within the query for LIMIT and OFFSET to work properly and consistently between query executions. We hence add one to each engine not having one already. ======================================= [FIX] account_reports: properly handle groupby in account_co
Original PR description
[FIX] account_reports, l10n_*_reports: add explicit ORDER BY to report engines for consistent LIMIT and OFFSET behavior As stated here https://www.postgresql.org/docs/current/queries-limit.html ,…
[FIX] account_reports, l10n_*_reports: add explicit ORDER BY to report engines for consistent LIMIT and OFFSET behavior
As stated here https://www.postgresql.org/docs/current/queries-limit.html , postgresql requires an explicit ORDER by within the query for LIMIT and OFFSET to work properly and consistently between query executions. We hence add one to each engine not having one already.
=======================================
[FIX] account_reports: properly handle groupby in account_codes engine for grouping keys used with multiple accounts
// TO REPRODUCE
1) Create a report with a single line, whose computation uses the account_codes engine, with formula "1". Set "partner_id" as the groupby value for that line. Setup a "load more limit" of 2 on your report.
2) Create 3 accounts, with codes 11, 12, 13
3) Create 3 partners: A, B, and C
4) Create journal entries, with the following lines (all balancing lines must use other accounts as the ones defined in 2) ), in that order:
- on account 11, with partner A, debit=10
- on account 11, with partner A, debit=20
- on account 12, with partner A, debit=25
- on account 11, without partner, debit=30
- on account 11, without partner, debit=40
- on account 12, with partner B, debit=50
- on account 13, with partner C, debit=60
5) Open the report for a period covering all the created journal entries, and have a look at the sublines generated for the groupby.
=> With the limit being 2, you'd expect to see "A", "B", and a "Load more..." line allowing to visualize the rest (namely a line for "C", and "Unknown"). Instead of that, you see no "Load more ...", and line "A"'s amount is wrong.
// EXPLANATION
The SQL query of the account_codes engine is grouping not only by groupby key (here, partner_id), but also by account_id, to be able to process the "C" and "D" suffixes of the formula later on. Because of that, the LIMIT passed by the load_more_limit is applied on that grouping.
With a load_more_limit of 2, we try to load 3 lines. If we manage to load 3, we only display 2, but know we need to display the "Load more..." line. Else, we know there are no more results, so no need for that additional line.
So, with our example, the query runs with a LIMIT of 3, returning
- 30 for A on account 11
- 25 for A on account 12
- 70 for no partner on account 11
Then, another issue happens:
The results returned by the SQL query (hence, by the engine) contain two times the same partner_id. From an engine perspective, the grouping key is only partner_id, not account_id (which is only used for an inner computation, with the SQL query). So that means the same grouping key has two different values. This is not legit, and causes one of them to shadow the other.
The report computation then receives 1 result for A, and 1 for "Unknown", so it renders them, and since there is no third result, it does not display the "Load more ...".
Forward-Port-Of: odoo/enterprise#74819
Forward-Port-Of: odoo/enterprise#74784When synchronizing orders from Amazon with Avatax enabled, sales order lines currently show no taxes and incorrectly set the tax included price as being the subtotal. This occurs because the fiscal position used does not include any tax, which is the expected behavior for Avatax. The recomputation then uses the full amount of the line (which is tax included), and in the absence of tax, consider this is also the subtotal. We now intentionally do not consider the tax amount from Amazon
Original PR description
When synchronizing orders from Amazon with Avatax enabled, sales order lines currently show no taxes and incorrectly set the tax included price as being the subtotal. This occurs because the fiscal position used does not include any tax, which is the expected behavior for Avatax. The recomputation then uses the full amount of the line (which is tax included), and in the absence of tax, consider this is also the subtotal. We now intentionally do not consider the tax amount from Amazon on the order lines, because the distribution of the Amazon's given tax amount is unknown. The multiple real taxes across that line is not an information that Amazon gives us, and needs to be seen from Avatax. This setup ensures that the subtotal on sales order lines remain accurate. opw-4214775 Forward-Port-Of: odoo/enterprise#74007
**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/enterprise#73666Current behaviour: --- When trying to duplicate a resource booking containing a resource, you get a Validation Error for a missing field. Expected behaviour: --- Ability to duplicate a resource booking Steps to reproduce: --- 1. Go to Appointments 2. Select a resource appointments (ie. Tennis Court) 3. Click on new (To make a new resource booking) 4. Set a name, attendee, AND resource (ie. Court 1) 5. Go to list view, and open newly made booking 6. Click on the cog > Duplicate
Original PR description
Current behaviour: --- When trying to duplicate a resource booking containing a resource, you get a Validation Error for a missing field. Expected behaviour: --- Ability to duplicate a resource…
Current behaviour: --- When trying to duplicate a resource booking containing a resource, you get a Validation Error for a missing field. Expected behaviour: --- Ability to duplicate a resource booking Steps to reproduce: --- 1. Go to Appointments 2. Select a resource appointments (ie. Tennis Court) 3. Click on new (To make a new resource booking) 4. Set a name, attendee, AND resource (ie. Court 1) 5. Go to list view, and open newly made booking 6. Click on the cog > Duplicate 7. Validation Error Cause of the issue: --- Caused by: https://github.com/odoo/enterprise/commit/064e0da976edd7ef501e4fb33d4d579eaab85a3d When duplicating a calendar.event, at the field appointment_resource_ids, the relation table appointment_booking_line is used on the fields calendar_event_id and appointment_resource_id. However, the model appointment_booking_line has another required field capacity_reserved. So when inserting into the table: https://github.com/odoo/odoo/blob/b64a507697381fd7bb205f4a2b2217322d31811a/odoo/fields.py#L4945 Only the two specified columns/fields are set, but not the third required field capacity_reserved. Which causes a SQL error "violates not-null constraint" opw-4187159 Forward-Port-Of: odoo/enterprise#71489
Problem ---------- Since 1st October, the SHIF replace the NHIF, the only difference is the computation of the amount. All payslip before and on the 9 October use the NHIF and all new payslip from the 9 October use the SHIF Objective ---------- Adapt the salary rules to compute the good rule. Adapt the NHIF Report to make NHIF or SHIF reports. Solution ---------- Create new SHIF rule parameter with a min amount and rate computation. Create a new report wizard to manage the 2 differe
Original PR description
Problem ---------- Since 1st October, the SHIF replace the NHIF, the only difference is the computation of the amount. All payslip before and on the 9 October use the NHIF and all new payslip from the 9 October use the SHIF Objective ---------- Adapt the salary rules to compute the good rule. Adapt the NHIF Report to make NHIF or SHIF reports. Solution ---------- Create new SHIF rule parameter with a min amount and rate computation. Create a new report wizard to manage the 2 different rules NHIF and SHIF task-4294419 Forward-Port-Of: odoo/enterprise#74241
[link to broken tests](https://runbot.odoo.com/web#id=68972&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) since [this pr](https://github.com/odoo/enterprise/pull/62136), a lot of things changed in swiss payroll localization. One of the changes was introduction of new module, l10n_ch_hr_payroll_elm. This affected one of the assertQueryCount tests checking compute_sheet function, which is also overwriten in said module. Therefore, we need to increase the query count acc
Original PR description
[link to broken tests](https://runbot.odoo.com/web#id=68972&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) since [this pr](https://github.com/odoo/enterprise/pull/62136), a lot of things changed in swiss payroll localization. One of the changes was introduction of new module, l10n_ch_hr_payroll_elm. This affected one of the assertQueryCount tests checking compute_sheet function, which is also overwriten in said module. Therefore, we need to increase the query count accordingly. Flamegraph of function _get_base_local_dict before above mentioned pr:  Flamegraph of same function after the pr:  Forward-Port-Of: odoo/enterprise#73831
…ayslip form Steps: • Install the payroll app. • Install l10n_au_hr_payroll module. • Open payslip and remove the employee from the form and click outside to apply changes. • It will cause the traceback error. Cause of the issue: • After removing the employee name corresponding contract will become empty. • The issue is due to empty record set of contract. Fix: • Added a check to ensure contract is present. task-4341523 Forward-Port-Of: odoo/enterprise#74238
Original PR description
…ayslip form Steps: • Install the payroll app. • Install l10n_au_hr_payroll module. • Open payslip and remove the employee from the form and click outside to apply changes. • It will cause the traceback error. Cause of the issue: • After removing the employee name corresponding contract will become empty. • The issue is due to empty record set of contract. Fix: • Added a check to ensure contract is present. task-4341523 Forward-Port-Of: odoo/enterprise#74238
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