Wednesday, January 15, 2025
23 changes · saas-17.2
Resolved issues and error corrections
This change corrects a problem in web navigation tests caused by a previous update. It helps keep automated checks reliable so future changes to the web interface can be validated with confidence.
Original PR description
Fixes test broken by: be23ed0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Issue Before This Commit: -------------------------------- The delivery label generated by the Shiprocket delivery method displayed an incorrect total when a discount or free delivery was applied, which caused confusion for users. Steps to Produce: -------------------------------- 1. Apply a discount or free delivery for a Shiprocket shipment. 2. Validate the delivery. 3. The total on the delivery label will show an incorrect value, not accounting for the discount or free delivery. W
Original PR description
Issue Before This Commit: -------------------------------- The delivery label generated by the Shiprocket delivery method displayed an incorrect total when a discount or free delivery was applied, which caused confusion for users. Steps to Produce: -------------------------------- 1. Apply a discount or free delivery for a Shiprocket shipment. 2. Validate the delivery. 3. The total on the delivery label will show an incorrect value, not accounting for the discount or free delivery. With This Commit: -------------------------------- The issue is fixed by ensuring the correct data is sent to the API, which now reflects the accurate total value on the delivery label, even when a discount or free delivery is applied. Task-id: 4395054 Forward-Port-Of: odoo/enterprise#75660
Before this commit, the button label displayed as 'Comparison: <previous_period>' (where 'previous_period' was the period preceding the compared period), regardless of the comparison type selected. For example, if comparing October 2024 to previous months, the label would appear as 'Comparison: Sep 2024'. This caused confusion for users when comparing a period to multiple previous ones, as only the last period was displayed in the label. After this commit, the button label is now dynamic and
Original PR description
Before this commit, the button label displayed as 'Comparison: <previous_period>' (where 'previous_period' was the period preceding the compared period), regardless of the comparison type selected.…
Before this commit, the button label displayed as 'Comparison: <previous_period>' (where 'previous_period' was the period preceding the compared period), regardless of the comparison type selected. For example, if comparing October 2024 to previous months, the label would appear as 'Comparison: Sep 2024'. This caused confusion for users when comparing a period to multiple previous ones, as only the last period was displayed in the label. After this commit, the button label is now dynamic and reflects the selected comparison: - When comparing to previous periods: 'Comparison: <periods_number> Previous Periods' - When comparing to the previous period: 'Comparison: Previous Period' - When comparing to the same period in previous years: 'Comparison: <periods_number> Previous Years' - When comparing to the same period in the previous year: 'Comparison: Previous Pear' - When we don't compare to another period/year: 'Comparison' Here, 'periods_number' refers to the number of periods or years being compared. task-id: 4267209 Forward-Port-Of: odoo/enterprise#75328 Forward-Port-Of: odoo/enterprise#73944
This commit change the account_move field we use to compute mod349 report. Before, we used amount_total. Now we use amount_untaxed, as the mod349 only need to show taxable bases. opw-4320487 Forward-Port-Of: odoo/enterprise#76516
Original PR description
This commit change the account_move field we use to compute mod349 report. Before, we used amount_total. Now we use amount_untaxed, as the mod349 only need to show taxable bases. opw-4320487 Forward-Port-Of: odoo/enterprise#76516
Currently, an error occurs when opening a preview of an invoice without an invoice date Step to produce: - Install the `l10n_ec_edi` module (with demo data). - Change a current company to 'EC Company', which has an 'Ecuador' country. - Create a new invoice, add a customer name, payment terms, and invoice line, save the record, - Click on the 'Preview' button (ensure that the invoice has no date). ```TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.date'``` An err
Original PR description
Currently, an error occurs when opening a preview of an invoice without an invoice date Step to produce: - Install the `l10n_ec_edi` module (with demo data). - Change a current company to 'EC Company', which has an 'Ecuador' country. - Create a new invoice, add a customer name, payment terms, and invoice line, save the record, - Click on the 'Preview' button (ensure that the invoice has no date). ```TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.date'``` An error occurs when the system attempts to calculate payment term days at [1], with using an invoice date, but it is not available. Link [1]: https://github.com/odoo/enterprise/blob/26aa95079af2a868c2991c7f19daee5328d5bb01/l10n_ec_edi/models/account_move.py#L440C22-L440C93 To resolve this issue, Provide a default day zero(0) for the payment term, if invoice date is not available. Sentry-6015854429 Forward-Port-Of: odoo/enterprise#76560 Forward-Port-Of: odoo/enterprise#72864
Due to an error in the condition, `ProprietaryID` was always used, even if IBANID should be used instead. That lead to customers missing information (`ProprietaryID` is not always picked up by other software, while IBANID is). Ticket link: https://odoo.com/odoo/69/tasks/4414985 opw-4414985 Forward-Port-Of: odoo/odoo#192519
Original PR description
Due to an error in the condition, `ProprietaryID` was always used, even if IBANID should be used instead. That lead to customers missing information (`ProprietaryID` is not always picked up by other software, while IBANID is). Ticket link: https://odoo.com/odoo/69/tasks/4414985 opw-4414985 Forward-Port-Of: odoo/odoo#192519
Currently, when buying a product in pos and using a new lot id, the quantities do not reflect this lot id. Steps to reproduce: ------------------- * Create a product: * Storable * Available in POS * Tracked by lots * Open shop session * Select the product just created * Enter anything as the lot number * Finalize order * Close session * In the back-end, navigate to the product page * Select the smart button **On hand** > Observation: The lot is not reflected Why the fix:
Original PR description
Currently, when buying a product in pos and using a new lot id, the quantities do not reflect this lot id. Steps to reproduce: ------------------- * Create a product: * Storable * Available in POS * Tracked by lots * Open shop session * Select the product just created * Enter anything as the lot number * Finalize order * Close session * In the back-end, navigate to the product page * Select the smart button **On hand** > Observation: The lot is not reflected Why the fix: ------------ When the session in closed, `stock.lot` are created but not reflected on the inventory quantity updates. We can add the `lot_id` when creating move lines as where we mention it, it will always have a related existing lot as per: https://github.com/odoo/odoo/blob/ba21b59d1234d13b5d4460facd60c586648048b8/addons/point_of_sale/models/stock_picking.py#L290 opw-4359435 Forward-Port-Of: odoo/odoo#193450
CLA change. Added new resource to corporate CLA file --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193539
Original PR description
CLA change. Added new resource to corporate CLA file --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193539
* = stock * PROPBLEM: when viewing purchase or vendor dashboard (under logistic section) , viewing the scoreboard for purchased or order it calculate all record from purchase.report but when clicking on it, redirect to view of 'purchase order' only which is wrong compare to the number display on the scoreboard * SOLUTION: This commit fix by edit the domain of related pivot which the scoreboard use to display data to the domain having state in either Purchase or Done Description of the iss
Original PR description
* = stock * PROPBLEM: when viewing purchase or vendor dashboard (under logistic section) , viewing the scoreboard for purchased or order it calculate all record from purchase.report but when clicking on it, redirect to view of 'purchase order' only which is wrong compare to the number display on the scoreboard * SOLUTION: This commit fix by edit the domain of related pivot which the scoreboard use to display data to the domain having state in either Purchase or Done 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#191985
Two lines that were missing from the "REAGYP - Agricultura" Fiscal Position Tax Mapping have been added. task-4342206 Forward-Port-Of: odoo/odoo#192930 Forward-Port-Of: odoo/odoo#192359
Original PR description
Two lines that were missing from the "REAGYP - Agricultura" Fiscal Position Tax Mapping have been added. task-4342206 Forward-Port-Of: odoo/odoo#192930 Forward-Port-Of: odoo/odoo#192359
Use fully qualified names as columns in related table can have a same name and this query could raise an error. Like the one below error below was shown in 18.0 ``` psycopg2.errors.AmbiguousColumn: column reference "state" is ambiguous LINE 3: AND state = 'validate' ``` Note: error occured in 18.0 will be fixed in forward port, using fully qualified names was the purpose so made sense to start from 16.0 and fix for all versions after Description of the issue/
Original PR description
Use fully qualified names as columns in related table can have a same name and this query could raise an error. Like the one below error below was shown in 18.0 ``` psycopg2.errors.AmbiguousColumn: column reference "state" is ambiguous LINE 3: AND state = 'validate' ``` Note: error occured in 18.0 will be fixed in forward port, using fully qualified names was the purpose so made sense to start from 16.0 and fix for all versions after 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#193568
**Description of the issue/feature this PR addresses:** When odoo is deployed with Reverse Proxy , like cloudflare, and cache rule is enabled. The login page is cached by cloudflare, "Cf-Cache-Status" is set to "HIT" in the reponse header  But in the html content, csrf_token is unavailable.  Error when try to
Original PR description
**Description of the issue/feature this PR addresses:** When odoo is deployed with Reverse Proxy , like cloudflare, and cache rule is enabled. The login page is cached by cloudflare, "Cf-Cache-Status" is set to "HIT" in the reponse header  But in the html content, csrf_token is unavailable.  Error when try to login.  **Current behavior before PR:** User can not login. **Desired behavior after PR is merged:** User can login. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191453
The get_text_content is not powerful enough to extract translated attributes. As a result, get_text_content will return empty string '' for terms whose translated contents are only in attributes. When the result is used to build the mapping text2terms, users will get strange result after write. opw-4147913 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 g
Original PR description
The get_text_content is not powerful enough to extract translated attributes. As a result, get_text_content will return empty string '' for terms whose translated contents are only in attributes. When the result is used to build the mapping text2terms, users will get strange result after write. opw-4147913 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#193574
Steps to reproduce ================== - Open any project - Create many project stages (80+) - Switch to the list view - Group by stage - Switch to to next page => The pager keeps increasing Cause of the issue ================== `stage_id` has a group_expand: `_read_group_stage_ids` This method is used to include empty stages in the result for the kanban view, so that we can drag tasks to an empty stage. Solution ======== Add a context key `project_kanban` and only add em
Original PR description
Steps to reproduce ================== - Open any project - Create many project stages (80+) - Switch to the list view - Group by stage - Switch to to next page => The pager keeps increasing Cause of the issue ================== `stage_id` has a group_expand: `_read_group_stage_ids` This method is used to include empty stages in the result for the kanban view, so that we can drag tasks to an empty stage. Solution ======== Add a context key `project_kanban` and only add empty stages in that case. opw-4408061 Forward-Port-Of: odoo/odoo#192955 Forward-Port-Of: odoo/odoo#192492
When a product has a fixed tax, there should be a separate downpayment line for the fixed tax amount. Steps to reproduce: ------------------- * Create a fixed tax of 1€ * Assign this tax to any product * Create a sale order with this product * Open PoS and make a downpayment of 10% > Observation: There is only one downpayment line with the total amount of the product and the fixed tax combined. opw-4252104 Forward-Port-Of: odoo/odoo#192208
Original PR description
When a product has a fixed tax, there should be a separate downpayment line for the fixed tax amount. Steps to reproduce: ------------------- * Create a fixed tax of 1€ * Assign this tax to any product * Create a sale order with this product * Open PoS and make a downpayment of 10% > Observation: There is only one downpayment line with the total amount of the product and the fixed tax combined. opw-4252104 Forward-Port-Of: odoo/odoo#192208
Renaming session to __session leverages Python's name mangling and ensures the attribute is treated as a private to the class. Forward-Port-Of: odoo/odoo#193501
Original PR description
Renaming session to __session leverages Python's name mangling and ensures the attribute is treated as a private to the class. Forward-Port-Of: odoo/odoo#193501
The tax tags are translatable but never translated automatically because they are generated dynamically from the tax report. This commit aims at improving this by translating automatically the tags that match exactly the name of the tax report line, for instance in Israel. Forward-Port-Of: odoo/odoo#192233
Original PR description
The tax tags are translatable but never translated automatically because they are generated dynamically from the tax report. This commit aims at improving this by translating automatically the tags that match exactly the name of the tax report line, for instance in Israel. Forward-Port-Of: odoo/odoo#192233
Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.6.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193722
Original PR description
Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.6.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193722
Steps to reproduce: - Go to the "/blog/astronomy-2/what-if-they-let-you-run-the-hubble-5" page. - Click on the "Mobile Preview" button. - Bug: The breadcrumb is broken. In stable versions, we fixed this in the least intrusive way possible to avoid making significant layout changes to existing databases. **BEFORE:** <kbd></kbd> **AFTER:** <kbd>![2025-01-14_09-53](https://github.com/
Original PR description
Steps to reproduce: - Go to the "/blog/astronomy-2/what-if-they-let-you-run-the-hubble-5" page. - Click on the "Mobile Preview" button. - Bug: The breadcrumb is broken. In stable versions, we fixed this in the least intrusive way possible to avoid making significant layout changes to existing databases. **BEFORE:** <kbd></kbd> **AFTER:** <kbd></kbd> In master version, in mobile view, we replaced the breadcrumb with a "< All Blogs" button to return to the blogs list, similar to what is done in "website_sale" and "website_event". opw-4457408 Forward-Port-Of: odoo/odoo#193508
Steps: - Install project_todo - Create a second company - Create a project - Link the project to a company - Setup a default value for task.project_id with your new project (1) - Try to open project_todo Actual result: - Error due to company id - can't adapt type 'res.company' Expected result: - No error - Welcome task is created and project is opened opw-4465277 Caused by https://github.com/odoo/odoo/pull/173625 Forward-Port-Of: odoo/odoo#193359
Original PR description
Steps: - Install project_todo - Create a second company - Create a project - Link the project to a company - Setup a default value for task.project_id with your new project (1) - Try to open project_todo Actual result: - Error due to company id - can't adapt type 'res.company' Expected result: - No error - Welcome task is created and project is opened opw-4465277 Caused by https://github.com/odoo/odoo/pull/173625 Forward-Port-Of: odoo/odoo#193359
Versions -------- - 16.0 (fix issue) - 17.0+ (skip useless constraint) Commit 3871ae2c6c45 enabled automated m2m CRUD in 17.0+ Steps ----- 1. Create an automated action on a Model with tags (e.g. Contact); 2. set trigger to On Creation; 3. in data to write, have evaluation type to Value; 4. fill in the value (e.g. 1); 5. create a record that would trigger the automation. Issue ----- > ValueError: Wrong value for res.partner.category_id: 1 Cause ----- In the `eval_value`
Original PR description
Versions -------- - 16.0 (fix issue) - 17.0+ (skip useless constraint) Commit 3871ae2c6c45 enabled automated m2m CRUD in 17.0+ Steps ----- 1. Create an automated action on a Model with tags (e.g.…
Versions -------- - 16.0 (fix issue) - 17.0+ (skip useless constraint) Commit 3871ae2c6c45 enabled automated m2m CRUD in 17.0+ Steps ----- 1. Create an automated action on a Model with tags (e.g. Contact); 2. set trigger to On Creation; 3. in data to write, have evaluation type to Value; 4. fill in the value (e.g. 1); 5. create a record that would trigger the automation. Issue ----- > ValueError: Wrong value for res.partner.category_id: 1 Cause ----- In the `eval_value` method, the `many2many` type doesn't get covered. Solution -------- 1. Have `eval_value` handle `many2many` values (linking them to relevant record, and existing as a single expression per column). 2. Undo 09a6df204f2a which disallowed writing by reference for many2many fields. This change makes writing by reference possible as well, and allows you to select the desired record, instead of having to manually fill in its ID. opw-4054461 Forward-Port-Of: odoo/odoo#193469 Forward-Port-Of: odoo/odoo#190047
Interfaces/Drivers inherit from an `Interface`/`Driver` class. These parent classes should not be registered as an actual interface/driver. This is now filterered at instanciation in order to avoid looping over useless elements later. Forward-Port-Of: odoo/odoo#193510
Original PR description
Interfaces/Drivers inherit from an `Interface`/`Driver` class. These parent classes should not be registered as an actual interface/driver. This is now filterered at instanciation in order to avoid looping over useless elements later. Forward-Port-Of: odoo/odoo#193510
To run tours or unit tests, we instrument Chrome and run it headlessly. One of the arguments passed while doing so is the "window size" it needs to use to emulate desktop-like or mobile-like screen sizes. Newer versions of Chrome sometimes introduce slight variation between the Chrome's window size and its viewport size (due to changes in the interface layout...). While often not a deal-breaker, Chrome 128 forces a min-width for the window greater than the breakpoint we use for smaller/
Original PR description
To run tours or unit tests, we instrument Chrome and run it headlessly. One of the arguments passed while doing so is the "window size" it needs to use to emulate desktop-like or mobile-like screen…
To run tours or unit tests, we instrument Chrome and run it headlessly. One of the arguments passed while doing so is the "window size" it needs to use to emulate desktop-like or mobile-like screen sizes. Newer versions of Chrome sometimes introduce slight variation between the Chrome's window size and its viewport size (due to changes in the interface layout...). While often not a deal-breaker, Chrome 128 forces a min-width for the window greater than the breakpoint we use for smaller/mobile-like testing (e.g. 375px, which matches a small smartphone). This commit changes the way we instrument Chrome to use a specific size by using the DevTools' Emulated Device (aka. "responsive mode"). It allows to apply a very specific viewport's size independently of the actual Chrome's window size, which makes it way more predictable than before. Note: this change is part of the preparation to support the "new" headless mode, which becomes the default starting with Chrome 128. Reference: - https://chromedevtools.github.io/devtools-protocol/tot/Emulation/#method-setDeviceMetricsOverride Forward-Port-Of: odoo/odoo#193779 Forward-Port-Of: odoo/odoo#193696