Monday, October 14, 2024
38 changes · saas-17.2
Resolved issues and error corrections
This fixes a broken messaging area on the Kenya OSCU stock import form after a platform-wide view syntax change. It helps ensure users can open and use the form without interface errors related to chatter display.
Original PR description
https://github.com/odoo/odoo/commit/351b047c3726527d8f59c0ba701c8934dd7c9af5 changed how the chatter is added to a view and updated the codebase except for this module. This commit fixes this.
This fixes a fragile automated test in the subscription payment flow where tiny rounding differences could incorrectly mark matching amounts as unequal. It helps keep subscription-related validation stable without changing customer-facing behavior.
Original PR description
Before this commit the following error was observed:
File "/data/build/enterprise/test_sale_subscription/tests/test_subscription_payment_integration.py", line 112, in test_subscription_invoice_automate
self.assertInvoicePaid(self.invoice)
File "/data/build/enterprise/test_sale_subscription/tests/test_subscription_payment_integration.py", line 66, in assertInvoicePaid
self.assertEqual(invoice.amount_paid, invoice.amount_total, "Amount should match")
AssertionError: 1206.3700000000001 != 1206.37 : Amount should match
Runbot errors: 100947, 100946, 100945, 100944, 100944This update corrects an outdated message panel format in the Kenya OSCU stock customs import screen. It helps ensure the page displays and works correctly after a broader system syntax update.
Original PR description
before this commit, the chatter still remains in the old format, in the commit https://github.com/odoo/odoo/commit/351b047c3726527d8f59c0ba701c8934dd7c9af5 chatter has been updated to new syntax and this got left over without changing into new after this commit, the left over old syntax is corrected to the new format
The mobile search panel no longer shows an extra red dot when a filter is selected. This removes a redundant visual cue, making the interface cleaner while keeping the selected filter clearly visible.
Original PR description
On mobile, whwen a domain is selected in the SearchPanel, there is a red dot that indicates there is a domain applied. This red dot is useless because we actually see that the domain is selected. This commit removes it. task-4246980 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product catalog prices are now hidden when the catalog is opened from manufacturing or repair orders. This keeps the catalog focused on selecting components, where price information is not relevant and could distract users.
Original PR description
This commit hides the unit price of products in the catalog, in case that the catalog was opened from a manufacturing or a repair order. This is because the catalog in this case is used to add a component so the price information is irrelevant. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves Odoo's internal Hoot test tool by making failed test results easier to understand and rerun. It helps developers diagnose issues faster, which supports more reliable quality checks before changes reach users.
Original PR description
## Pull Request HOOT (PRHOOT) - part 25 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4:…
## Pull Request HOOT (PRHOOT) - part 25 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971 Part 15.5: https://github.com/odoo/odoo/pull/166463 Part 16: https://github.com/odoo/odoo/pull/166311 Part 17: https://github.com/odoo/odoo/pull/168328 Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657 Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767 Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895 Part 21: https://github.com/odoo/odoo/pull/174337 Part 22: https://github.com/odoo/odoo/pull/176777 / https://github.com/odoo/enterprise/pull/68721 Part 23: https://github.com/odoo/odoo/pull/179660 / https://github.com/odoo/enterprise/pull/69728 Part 24: https://github.com/odoo/odoo/pull/181971 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
The definition of these records include the field `requires_allocation`, so updating them will trigger the constraint for that field. There's already a [fix for this](https://github.com/odoo/odoo/pull/182533) but it will be interesting to still mark these records as noupdate to be coherent with all the other `hr.leave.type` records. To reproduce: - Install `l10n_hk_hr_payroll` with demo data - Upgrade the module Forward-Port-Of: odoo/enterprise#71844
Original PR description
The definition of these records include the field `requires_allocation`, so updating them will trigger the constraint for that field. There's already a [fix for this](https://github.com/odoo/odoo/pull/182533) but it will be interesting to still mark these records as noupdate to be coherent with all the other `hr.leave.type` records. To reproduce: - Install `l10n_hk_hr_payroll` with demo data - Upgrade the module Forward-Port-Of: odoo/enterprise#71844
Steps to reproduce: - open a first tab - create a new spreadsheet - open a second tab - from that new tab, delete the spreadsheet (send to trash, then permanently delete it from the trash) - create a new spreadsheet => update a few cells, the websocket connection is broken. Task: 4252590 Forward-Port-Of: odoo/enterprise#71802
Original PR description
Steps to reproduce: - open a first tab - create a new spreadsheet - open a second tab - from that new tab, delete the spreadsheet (send to trash, then permanently delete it from the trash) - create a new spreadsheet => update a few cells, the websocket connection is broken. Task: 4252590 Forward-Port-Of: odoo/enterprise#71802
This task was created to modify the demo data for Argentina, to avoid using real partner information. latam-task-1239 adhoc-task-41734 Forward-Port-Of: odoo/enterprise#71408 Forward-Port-Of: odoo/enterprise#71230
Original PR description
This task was created to modify the demo data for Argentina, to avoid using real partner information. latam-task-1239 adhoc-task-41734 Forward-Port-Of: odoo/enterprise#71408 Forward-Port-Of: odoo/enterprise#71230
Current behaviour: --- When you click on the "request a document" link, then upload a document, you get a CSRF error Steps to reproduce: --- 1. Install documents 2. In documents, click the arrow next to "new", then "request" 3. Add a name, and a "request to", then click "request" 4. Go to messages, copy the link in the generated email 5. Paste the link in an incognito window 6. Upload a document, CSRF error Cause of the issue: --- The js file that adds the CSRF token (documents_
Original PR description
Current behaviour: --- When you click on the "request a document" link, then upload a document, you get a CSRF error Steps to reproduce: --- 1. Install documents 2. In documents, click the arrow next to "new", then "request" 3. Add a name, and a "request to", then click "request" 4. Go to messages, copy the link in the generated email 5. Paste the link in an incognito window 6. Upload a document, CSRF error Cause of the issue: --- The js file that adds the CSRF token (documents_public_pages.js) could not be loaded due to an error caused by website_sale_renting: `TypeError: odoo.define is not a function` The mixin file was loaded before the odoo module loader. Caused by: https://github.com/odoo/enterprise/commit/93d09071a08bd5de948886729d827b1c46e907d9 Fix: --- Put js code from website_sale_renting before owl.js which is right after assets_frontend_minimal, containing module_loader.js opw-4138333 Forward-Port-Of: odoo/enterprise#70577
Before this commit, it was possible to fill two date fields in two different date formats in the same document. This happened because the date format was dependent on the location of the user who is signing. After this commit, date fields will be auto-filled by a fixed date format, that format depends on the language of the company's partner. Task: 3930358 Forward-Port-Of: odoo/enterprise#64591
Original PR description
Before this commit, it was possible to fill two date fields in two different date formats in the same document. This happened because the date format was dependent on the location of the user who is signing. After this commit, date fields will be auto-filled by a fixed date format, that format depends on the language of the company's partner. Task: 3930358 Forward-Port-Of: odoo/enterprise#64591
### [FIX] account_report: fix indentation in xlsx export Currently the indentation of XLSX export of reports was sometimes broken. The current implementation only supported up to three levels of indentation in the export as well. This fix supports a virtually infinite number of indentation levels and fixes the indentation in the XLSX exports. ### [I18N] account_reports: update terms ### [IMP] account_reports: move account code column to the right in xlsx Currently, when exporting an a
Original PR description
### [FIX] account_report: fix indentation in xlsx export Currently the indentation of XLSX export of reports was sometimes broken. The current implementation only supported up to three levels of indentation in the export as well. This fix supports a virtually infinite number of indentation levels and fixes the indentation in the XLSX exports. ### [I18N] account_reports: update terms ### [IMP] account_reports: move account code column to the right in xlsx Currently, when exporting an accounting report as XLSX file, we add a column for the account codes on the very left of the sheet. This looks a bit weird and is not the most important information to have as a first column. In this commit, we move the column to the right so the name of the line will be first, followed by the account code (if applicable). We also add a column name for the account codes. task-3986483 Forward-Port-Of: odoo/enterprise#67111
There is an *Appraisal Plan* section in the setting that allows setting the global plan for the company. If *Appraisal Automation* is enabled and the plan is changed, we want to recompute the next appraisal date based on it for all the company employees. task-4167727 Forward-Port-Of: odoo/enterprise#69973
Original PR description
There is an *Appraisal Plan* section in the setting that allows setting the global plan for the company. If *Appraisal Automation* is enabled and the plan is changed, we want to recompute the next appraisal date based on it for all the company employees. task-4167727 Forward-Port-Of: odoo/enterprise#69973
The end date on the Holiday Attest (N-1) was wrong. It should be the same as the end of the notice period. Forward-Port-Of: odoo/enterprise#71642
Original PR description
The end date on the Holiday Attest (N-1) was wrong. It should be the same as the end of the notice period. Forward-Port-Of: odoo/enterprise#71642
Steps to reproduce: - Insert a pivot view of timesheet - Insert a list view of project - Add a new global filter based on project => you actually cannot select id for the list view of project, but we should be able to filter the list view based on the project id. This commit adds the id field to the allowed fields for the relation global filters. Task: 4228916 Forward-Port-Of: odoo/enterprise#71365
Original PR description
Steps to reproduce: - Insert a pivot view of timesheet - Insert a list view of project - Add a new global filter based on project => you actually cannot select id for the list view of project, but we should be able to filter the list view based on the project id. This commit adds the id field to the allowed fields for the relation global filters. Task: 4228916 Forward-Port-Of: odoo/enterprise#71365
### Steps to reproduce: - Create two helpdesk tickets - Create a timesheet for each one of those tickets - Merge the tickets together - Check the 'Hours spent' field where it doesn't show the addition of the two tickets' total_hours_spent ### Current behavior before PR: This is happening because when flushing after merging the tickets the total hours spent does not show in the recomputation tree so it doesn't get recomputed. ### Desired behavior after PR is merged: The idea of th
Original PR description
### Steps to reproduce: - Create two helpdesk tickets - Create a timesheet for each one of those tickets - Merge the tickets together - Check the 'Hours spent' field where it doesn't show the addition of the two tickets' total_hours_spent ### Current behavior before PR: This is happening because when flushing after merging the tickets the total hours spent does not show in the recomputation tree so it doesn't get recomputed. ### Desired behavior after PR is merged: The idea of the fix came from this commit https://github.com/odoo-dev/enterprise/commit/f4aedadbd6180049573c2b4d90ffc0dd4656ea06#diff-9a1216d4c95d4f60296c59d0294e505970b4d97ad4ac256e1a87c7289f1f8129R17 since the issue got resolved in 17.4 because of this commit where it changed the dependency of the project_id which leads to the existance of the total_hours_spent in the tree of recomputation that is depending on the helpdesk.ticket.project_id opw-4226970 Forward-Port-Of: odoo/enterprise#71630
1. Enable "auto-detect" on the Avatax fiscal position, 2. Go to "Abigail Peterson" contact and set "United States" as country 3. Expenses > My Expenses > New 4. Enter a description, set a total and "Abigail Peterson" as employee 5. "Create Report" > "Submit to Manager" > "Approve" > "Post Journal Entries" Issue: Validation error will raise because of the incomplete address However we only handle customer invoices and customer invoice refunds (aka credit notes) with external tax integr
Original PR description
1. Enable "auto-detect" on the Avatax fiscal position, 2. Go to "Abigail Peterson" contact and set "United States" as country 3. Expenses > My Expenses > New 4. Enter a description, set a total and "Abigail Peterson" as employee 5. "Create Report" > "Submit to Manager" > "Approve" > "Post Journal Entries" Issue: Validation error will raise because of the incomplete address However we only handle customer invoices and customer invoice refunds (aka credit notes) with external tax integrations so the constraint should only show for journal entries of this type. opw-4151193 Forward-Port-Of: odoo/enterprise#71747 Forward-Port-Of: odoo/enterprise#71543
Steps to reproduce: - Accounting > Configuration > Taxes - Create a tax with 'Tax Computation' as Fixed - Invoice a product with only that fixed tax - Print the invoice The subtotals for fixed taxes are displayed showing 'on $__', this is inconsistent with the intent of 5f77e6588ee2a15d7bf2cb593a51f509d9e4ca9d where the change was made. We want this mention only on percentage based taxes which actually depend on the amount the tax is applied to. i.e. '15% on $100' for percentage and ju
Original PR description
Steps to reproduce: - Accounting > Configuration > Taxes - Create a tax with 'Tax Computation' as Fixed - Invoice a product with only that fixed tax - Print the invoice The subtotals for fixed taxes are displayed showing 'on $__', this is inconsistent with the intent of 5f77e6588ee2a15d7bf2cb593a51f509d9e4ca9d where the change was made. We want this mention only on percentage based taxes which actually depend on the amount the tax is applied to. i.e. '15% on $100' for percentage and just 'Fix $15' for fixed taxes. opw-4110516 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180341
The active flag [can be included](https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/stock_warehouse.py#L259-L277) in the values to update when calling function `_create_or_update_sequences_and_picking_types`, for example [during upgrades](https://github.com/odoo/upgrade/blob/master/migrations/stock/saas~17.3.1.1/end-migrate.py#L16). This will raise the Validation Error even if the flag is being kept as active. upg-2034998 Forward-Port-Of: odoo/odoo#180292
Original PR description
The active flag [can be included](https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/stock_warehouse.py#L259-L277) in the values to update when calling function `_create_or_update_sequences_and_picking_types`, for example [during upgrades](https://github.com/odoo/upgrade/blob/master/migrations/stock/saas~17.3.1.1/end-migrate.py#L16). This will raise the Validation Error even if the flag is being kept as active. upg-2034998 Forward-Port-Of: odoo/odoo#180292
### Description of the issue/feature this PR addresses: In the chatter if you try to insert signature with: /Signature , an error appear if auth_totp is not installed: > Error: Invalid ids list: > Error: Invalid ids list: > at validatePrimitiveList (https://www.stesi.consulting/web/assets/debug/web.assets_web_dark.js:28515:15) (/web/static/src/core/orm_service.js:73) > at ORM.read (https://www.stesi.consulting/web/assets/debug/web.assets_web_dark.js:28596:9) (/web/s
Original PR description
### Description of the issue/feature this PR addresses: In the chatter if you try to insert signature with: /Signature , an error appear if auth_totp is not installed: > Error: Invalid ids list: >…
### Description of the issue/feature this PR addresses: In the chatter if you try to insert signature with: /Signature , an error appear if auth_totp is not installed: > Error: Invalid ids list: > Error: Invalid ids list: > at validatePrimitiveList (https://www.stesi.consulting/web/assets/debug/web.assets_web_dark.js:28515:15) (/web/static/src/core/orm_service.js:73) > at ORM.read (https://www.stesi.consulting/web/assets/debug/web.assets_web_dark.js:28596:9) (/web/static/src/core/orm_service.js:154) > at ORM.read (https://www.stesi.consulting/web/assets/debug/web.assets_web_dark.js:39288:41) (/web/static/src/core/utils/hooks.js:101) > at Object.callback (https://www.stesi.consulting/web/assets/debug/web_editor.backend_assets_wysiwyg.js:25785:51) (/web_editor/static/src/js/wysiwyg/wysiwyg.js:2463) > at Powerbox._pickCommand (https://www.stesi.consulting/web/assets/debug/web_editor.backend_assets_wysiwyg.js:14811:27) (/web_editor/static/src/js/editor/odoo-editor/src/powerbox/Powerbox.js:232) ### Current behavior before PR: The error above appears because the web_editor get the session_user_id from session_info that is set by auth_totp or in a frontend session. Using uid it works on both ### Desired behavior after PR is merged: No error should appear --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179378
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#182667
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#182667
Upon attempting to refund an Authorize.net transaction, its state on the provider side is fetched to decide on the refund strategy. If the payment is not yet settled, the refund is achieved by sending a void request rather than a refund request. This flow was not fully working because the payment engine refused to move the transaction state from `done` to `cancel`. This forced users to hit the "Refund" button once to send the void request and a second time to cancel the transaction, as the se
Original PR description
Upon attempting to refund an Authorize.net transaction, its state on the provider side is fetched to decide on the refund strategy. If the payment is not yet settled, the refund is achieved by sending a void request rather than a refund request. This flow was not fully working because the payment engine refused to move the transaction state from `done` to `cancel`. This forced users to hit the "Refund" button once to send the void request and a second time to cancel the transaction, as the second attempt was working thanks to the change of transaction state on the provider side. This commit allows Authorize.net transactions to move from the `done` state to the `cancel` state. It is not necessary to ensure we are in the context of a refund because we always check that a transaction is in the `authorized` state before attempting to void it. opw-4201355 Forward-Port-Of: odoo/odoo#183184
The DisplayDriver class uses the `xdotool` command to send keypresses to the browser. However for Chromium, it is using the wrong process name causing the keystrokes not to be received. The symptom of this is the Pairing Code does not disappear after 5 minutes as intended, leaving an invalid code on the screen. This PR fixes the issue by using the correct process name for Chromium. Related PR for 18.0+: https://github.com/odoo/odoo/pull/180286 --- I confirm I have signed the CL
Original PR description
The DisplayDriver class uses the `xdotool` command to send keypresses to the browser. However for Chromium, it is using the wrong process name causing the keystrokes not to be received. The symptom of this is the Pairing Code does not disappear after 5 minutes as intended, leaving an invalid code on the screen. This PR fixes the issue by using the correct process name for Chromium. Related PR for 18.0+: https://github.com/odoo/odoo/pull/180286 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182745
The demo mode option in the Peppol connection wizard is primarily used by internal teams (BA, support, sales) for demonstrations or testing. It is more appropriate to manage this mode through a system parameter instead of exposing it to all users in the wizard interface. This commit mirrors the change from (commit 6d222885f41f5136c690dcd56953f1a9775204ae pr odoo/odoo#182893), but without removing the related fields, making it suitable for stable versions. task-4215904 Forward-Port-Of: od
Original PR description
The demo mode option in the Peppol connection wizard is primarily used by internal teams (BA, support, sales) for demonstrations or testing. It is more appropriate to manage this mode through a system parameter instead of exposing it to all users in the wizard interface. This commit mirrors the change from (commit 6d222885f41f5136c690dcd56953f1a9775204ae pr odoo/odoo#182893), but without removing the related fields, making it suitable for stable versions. task-4215904 Forward-Port-Of: odoo/odoo#183180
Currently, when using any browser on an Ipad, qr codes will not be shown on the printed receipt, when printed for the first time. When printing it a second time, it will appear. Steps to reproduce: ------------------- * Use an Ipad (or simulate one) * Go to the **Point of sale** App * Select **Configuration** > **Settings** * Enable QR code on receipt * Open shop session * Make an order and pay it * Print the receipt > Observation: QR code does not appear, big white space where it sh
Original PR description
Currently, when using any browser on an Ipad, qr codes will not be shown on the printed receipt, when printed for the first time. When printing it a second time, it will appear. Steps to reproduce:…
Currently, when using any browser on an Ipad, qr codes will not be shown on the printed receipt, when printed for the first time. When printing it a second time, it will appear.
Steps to reproduce:
-------------------
* Use an Ipad (or simulate one)
* Go to the **Point of sale** App
* Select **Configuration** > **Settings**
* Enable QR code on receipt
* Open shop session
* Make an order and pay it
* Print the receipt
> Observation: QR code does not appear, big white space where it should be
* Print it again
> Observation: QR code is printed
Why the fix:
------------
```js
function createImage(url) {
return new Promise((resolve, reject) => {
const img = new Image();
img.onload = () => resolve(img);
img.decode = () => resolve(img);
img.onerror = reject;
img.crossOrigin = "anonymous";
img.decoding = "async";
img.src = url;
});
}
```
In this piece of code, `img.decode = () => resolve(img);` is supposed to ensure that the image is fully processed but is misused. Decode is not a setter, it's a method that returns a promise when the image is fully decoded. While this code wait for the image to load it does not wait for it to be fully ready (processed).
`img.decode()` ensures that the image has been fully decoded before continuing.
We go one step further with `requestAnimationFrame`. This defers the execution and will ensure that the resolved image is rendered in the next frame. It's more important in devices like Ipad because the broswers tend to handle image operations differently, thus creating rendering and timing issues.
With this fix, we now wait longer to make sure that the image is not only loaded but also fully processed and ready to be shown.
opw-4144049
Forward-Port-Of: odoo/odoo#182803Steps to reproduce ====================== Go to the user profile. Click on tags. You will be redirected to the courses instead of redirecting to the tags. Technical ========== Click event is there on the whole card as our tags are inside the card so the click event of a parent is triggering instead of the child. and we are redirected to the course page. After this PR =========== We will be redirected to tags when clicking on tag. Task-4203676 Forward-Port-Of: odoo/odoo#183079 F
Original PR description
Steps to reproduce ====================== Go to the user profile. Click on tags. You will be redirected to the courses instead of redirecting to the tags. Technical ========== Click event is there on the whole card as our tags are inside the card so the click event of a parent is triggering instead of the child. and we are redirected to the course page. After this PR =========== We will be redirected to tags when clicking on tag. Task-4203676 Forward-Port-Of: odoo/odoo#183079 Forward-Port-Of: odoo/odoo#181499
## Description After importing a large quantity of pending bills with no `invoice_date`, the dashboard can be significantly slow. The bottleneck comes primarily from the hot loop in `_count_results_and_sum_amounts`, as it's iterating over a potentially enormous list of dictionary of query results. This patch improvement consists mostly of hoisting invariants out of this hot loop, most impactful is the call to `context_today`, which does a lot of computation/conversions to apply the proper tim
Original PR description
## Description After importing a large quantity of pending bills with no `invoice_date`, the dashboard can be significantly slow. The bottleneck comes primarily from the hot loop in…
## Description After importing a large quantity of pending bills with no `invoice_date`, the dashboard can be significantly slow. The bottleneck comes primarily from the hot loop in `_count_results_and_sum_amounts`, as it's iterating over a potentially enormous list of dictionary of query results. This patch improvement consists mostly of hoisting invariants out of this hot loop, most impactful is the call to `context_today`, which does a lot of computation/conversions to apply the proper timezone and localize the date. ## Benchmark | len(results_dict) | Before | After | Speedup | |-------------------|--------|-------|---------| | Timings (10k) | 250ms | 50ms | 5x | | Timings (50k) | 1.2s | 300ms | 4x | | Timings (100k) | 2.7s | 820ms | 3.3x | | Timings (250k) | 6.7s | 1.7s | 3.9x | | Timings (~600k) | 13s | 4s | 3.25x | ## Reference opw-4235252 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183342
Task: 4228916 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#182595
Original PR description
Task: 4228916 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#182595
To reproduce the issue: (Need website_sale) 1. Set up a website shop for ES company - With demo payment method 2. In Settings: - Website > Automatic Invoice: enabled 3. With a portal user, add a product to the cart 4. Open the cart 5. Pay with Demo Error: The client is redirected to a page "Internal server error: The partner needs a set tax identification number or VAT number" When post-processing the payment, and because of step 2, it leads to https://github.com/odoo/odoo/
Original PR description
To reproduce the issue: (Need website_sale) 1. Set up a website shop for ES company - With demo payment method 2. In Settings: - Website > Automatic Invoice: enabled 3. With a portal user, add a…
To reproduce the issue: (Need website_sale) 1. Set up a website shop for ES company - With demo payment method 2. In Settings: - Website > Automatic Invoice: enabled 3. With a portal user, add a product to the cart 4. Open the cart 5. Pay with Demo Error: The client is redirected to a page "Internal server error: The partner needs a set tax identification number or VAT number" When post-processing the payment, and because of step 2, it leads to https://github.com/odoo/odoo/blob/20365bcab548c4a2d93194c8c2b8b2577d14d3ce/addons/l10n_es_edi_facturae/wizard/account_move_send.py#L86-L88 Where we will generate the data for the Facturae XML. There, we check few things, like the vat number of the partner: https://github.com/odoo/odoo/blob/e157cb2d8640fac1365beb135763cb25cff554f5/addons/l10n_es_edi_facturae/models/account_move.py#L312-L313 And since the portal user does not have any vat number, the error is raised. The Facturae feature should only be enabled for B2B flows OPW-4121724 Forward-Port-Of: odoo/odoo#181653
Since [1], the ".o_default_text_snippet" class has not been correctly removed when text is modified within a content-editable element. This commit resolves the issue. Steps to reproduce: - Drag and drop the "Pricelist block" into the page. - Click on the snippet newly inserted to display the options on the right panel. - Enable the "Descriptions" option under the Pricelist block options to display descriptions. - Edit some descriptions directly in the snippet. - Disable and re-
Original PR description
Since [1], the ".o_default_text_snippet" class has not been correctly removed when text is modified within a content-editable element. This commit resolves the issue. Steps to reproduce: - Drag and drop the "Pricelist block" into the page. - Click on the snippet newly inserted to display the options on the right panel. - Enable the "Descriptions" option under the Pricelist block options to display descriptions. - Edit some descriptions directly in the snippet. - Disable and re-enable the "Descriptions" option. - Bug: The edited descriptions are replaced by the default text. [1]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af#diff-52a4f9d2c217548e69e6b7fd097f286f1754a6389734eea254b87255e501cbef task-4084956 task-4147162 (first part) Forward-Port-Of: odoo/odoo#177588
Steps to reproduce the error 1.create a db in odoo 15.0 install hr_holiday and l10n_be_hr_payroll 2.create a leave with existing leave type from l10n_be_hr_payroll module 3.upgrade db to 16.0 the below mentioned traceback will raise traceback ```py Traceback (most recent call last): File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 698, in _tag_root f(rec) File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 599, in _tag_record record = model._load_recor
Original PR description
Steps to reproduce the error 1.create a db in odoo 15.0 install hr_holiday and l10n_be_hr_payroll 2.create a leave with existing leave type from l10n_be_hr_payroll module 3.upgrade db to 16.0 the…
Steps to reproduce the error
1.create a db in odoo 15.0 install hr_holiday and l10n_be_hr_payroll
2.create a leave with existing leave type from l10n_be_hr_payroll module
3.upgrade db to 16.0 the below mentioned traceback will raise
traceback
```py
Traceback (most recent call last):
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 698, in _tag_root
f(rec)
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 599, in _tag_record
record = model._load_records([data], self.mode == 'update')
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4393, in _load_records
data['record']._load_records_write(data['values'])
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4324, in _load_records_write
self.write(values)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3806, in write
real_recs._validate_fields(vals, inverse_fields)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 1365, in _validate_fields
check(self)
File "/home/odoo/src/odoo/16.0/addons/hr_holidays/models/hr_leave_type.py", line 188, in check_allocation_requirement_edit_validity
raise UserError(_("The allocation requirement of a time off type cannot be changed once leaves of that type have been taken. You should create a new time off type instead."))
odoo.exceptions.UserError: The allocation requirement of a time off type cannot be changed once leaves of that type have been taken. You should create a new time off type instead.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/home/odoo/src/odoo/16.0/odoo/service/server.py", line 1310, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/16.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/16.0/odoo/modules/registry.py", line 91, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 484, in load_modules
processed_modules += load_marked_modules(cr, graph,
File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 372, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 231, in load_module_graph
load_data(cr, idref, mode, kind='data', package=package)
File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 71, in load_data
tools.convert_file(cr, package.name, filename, idref, mode, noupdate, kind)
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 763, in convert_file
convert_xml_import(cr, module, fp, idref, mode, noupdate)
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 829, in convert_xml_import
obj.parse(doc.getroot())
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 749, in parse
self._tag_root(de)
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 711, in _tag_root
raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/16.0/l10n_be_hr_payroll/data/hr_leave_type_data.xml:14, somewhere inside
<record id="holiday_type_maternity" model="hr.leave.type">
<field name="name">Maternity Time Off</field>
<field name="requires_allocation">no</field>
<field name="leave_validation_type">no_validation</field>
<field name="request_unit">half_day</field>
<field name="color_name">lavender</field>
<field name="leave_notif_subtype_id" ref="hr_holidays.mt_leave"/>
<field name="work_entry_type_id" ref="work_entry_type_maternity"/>
<field name="icon_id" ref="hr_holidays.icon_11"/>
<field name="company_id" eval="False"/>
</record>
```
why this traceback is raised because while loading ``l10n_be_hr_payroll`` moduel this data file will load during that if record is noupdate false then it will go for write call so in that requires_allocation will also go for write call even the value is same. So, the newly introduced [``constraints``](https://github.com/odoo/odoo/commit/33da34b842f2fe700efaf55915d4cb9828e139d7) will trigger and check if any record
of leave is present with the that leavetype constraint will trigger .For fixing this issue pop the value of ``requires_allocation`` if the values are same otherwise record is modified by user.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#182533Description this PR addresses: Fixes #181899: Prevents data loss when migrating attachments from DB to filestore by adding a writable permission check before migration. Current behavior before PR: Migration to filestore proceeds even if the target directory is not writable, resulting in data loss. Desired behavior after PR is merged: Writable permissions are checked before migration. If the target directory is not writable, an exception will be raised --- I confirm I have signed
Original PR description
Description this PR addresses: Fixes #181899: Prevents data loss when migrating attachments from DB to filestore by adding a writable permission check before migration. Current behavior before PR: Migration to filestore proceeds even if the target directory is not writable, resulting in data loss. Desired behavior after PR is merged: Writable permissions are checked before migration. If the target directory is not writable, an exception will be raised --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181998
In the Calendar app with the Arabic language, there is no AM/PM distinction or 24-hour clock option. Users can only select a time between 1 and 12 without the ability to specify AM or PM. This issue is caused by the missing %p placeholder in the Arabic record of the res.lang.csv file. OPW-4182242 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180858
Original PR description
In the Calendar app with the Arabic language, there is no AM/PM distinction or 24-hour clock option. Users can only select a time between 1 and 12 without the ability to specify AM or PM. This issue is caused by the missing %p placeholder in the Arabic record of the res.lang.csv file. OPW-4182242 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180858
Description of the issue/feature this PR addresses: sys.settrace prevents coverage.py from working properly: https://coverage.readthedocs.io/en/7.5.3/trouble.html The main cause of the problem is that when executing the SyncCollector profiler we will settrace(None). This makes the coverage result invalid since the settrace added by the coverage is not resumed. Also, it would be possible to have a similar problem with nested SyncCollector, or if any other tool/code uses sys.settrace.
Original PR description
Description of the issue/feature this PR addresses: sys.settrace prevents coverage.py from working properly: https://coverage.readthedocs.io/en/7.5.3/trouble.html The main cause of the problem is that when executing the SyncCollector profiler we will settrace(None). This makes the coverage result invalid since the settrace added by the coverage is not resumed. Also, it would be possible to have a similar problem with nested SyncCollector, or if any other tool/code uses sys.settrace. So, an error is logged when the profiler starts. Current behavior before PR: The coverage.py report doesn't correctly track which tests have been run. Desired behavior after PR is merged: coverage.py will report all the correct tests. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167379
## Description of the issue/feature this PR addresses: Prior to this commit, the health route is responding with a 200 status even when the database server is down or unreachable. In deployment scenario (CI/CD), this route (/web/health) is (can be) used in order to get the deployement state. This is actually the only one that can be used in order to check it without an active session or credentials or master password. Including the optional db_server_status arg will allow integrating th
Original PR description
## Description of the issue/feature this PR addresses: Prior to this commit, the health route is responding with a 200 status even when the database server is down or unreachable. In deployment…
## Description of the issue/feature this PR addresses: Prior to this commit, the health route is responding with a 200 status even when the database server is down or unreachable. In deployment scenario (CI/CD), this route (/web/health) is (can be) used in order to get the deployement state. This is actually the only one that can be used in order to check it without an active session or credentials or master password. Including the optional db_server_status arg will allow integrating the postgresql server state without breaking any eventual existing overrides. ## Current behavior before PR: When the postgresql database is not up / not reachable the route is returning a 200 code. ## Desired behavior after PR is merged: When the postgresql database is not up / not reachable the route is returning a 500 code. As we are in stable, an optional argument has been added to the route in order not to break any potential existing overrides. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182840 Forward-Port-Of: odoo/odoo#182537
Task: 41734 Odoo-task: 1239 Description of the issue/feature this PR addresses: This task was created to modify the demo data for Argentina, to avoid using real partner information except for their VAT number. Current behavior before PR: Desired behavior after PR is merged: Edit the demo data with fake information except for the VAT number. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182663 Forward-Port-Of:
Original PR description
Task: 41734 Odoo-task: 1239 Description of the issue/feature this PR addresses: This task was created to modify the demo data for Argentina, to avoid using real partner information except for their VAT number. Current behavior before PR: Desired behavior after PR is merged: Edit the demo data with fake information except for the VAT number. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182663 Forward-Port-Of: odoo/odoo#175390
When the session of the kiosk is closed in the backoffice, the kiosk is supposed to show the "We are closed" banner and to no longer accept orders. Currently, this is not the case. In this commit we fix the issue Task: 4219525 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182081
Original PR description
When the session of the kiosk is closed in the backoffice, the kiosk is supposed to show the "We are closed" banner and to no longer accept orders. Currently, this is not the case. In this commit we fix the issue Task: 4219525 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182081
when a field object is not _toplevel, it may be shared with multiple registries and should be readonly in any case 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#182859
Original PR description
when a field object is not _toplevel, it may be shared with multiple registries and should be readonly in any case 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#182859