Saturday, February 22, 2025
16 changes · master
Enhancements to existing features
This update reorganizes product description fields and Gelato options so sales and ecommerce information appears in a clearer order. It also makes Gelato settings accessible from the main sales settings, helping teams configure related options more easily.
Original PR description
Ecommerce description is moved before quotation description and gelato group is moved after quotation description. Gelato setting is visible from sales settings. See also: https://github.com/odoo/upgrade/pull/7271
Miscellaneous changes
After this commit: ================== - To approve filter will only appear if the Purchase Order Approval is set to be true. - Records not draggable when we have warehouse filter in inventory view. - In case of multi-step receiving/deliveries, the tracking reference will be propagated. - Create Bills smart button only to appear, removed “Create Vendor Bills” from the action menu. - UI improvement in pricelist report view. task 3859453 Forward-Port-Of: odoo/odoo#168713
Original PR description
After this commit: ================== - To approve filter will only appear if the Purchase Order Approval is set to be true. - Records not draggable when we have warehouse filter in inventory view. - In case of multi-step receiving/deliveries, the tracking reference will be propagated. - Create Bills smart button only to appear, removed “Create Vendor Bills” from the action menu. - UI improvement in pricelist report view. task 3859453 Forward-Port-Of: odoo/odoo#168713
**Problem**: When the selection moves out of the viewport while typing, the user cannot see what they are typing. **Solution**: Automatically scroll to the selection if it moves out of the viewport. **Steps to Reproduce**: 1. Open the editor. 2. Keep adding paragraphs by pressing Enter repeatedly. 3. When the selection goes out of the viewport, type some text. - The typed content is not visible. opw-4356668 --- I confirm I have signed the CLA and read the PR guidelines at w
Original PR description
**Problem**: When the selection moves out of the viewport while typing, the user cannot see what they are typing. **Solution**: Automatically scroll to the selection if it moves out of the viewport. **Steps to Reproduce**: 1. Open the editor. 2. Keep adding paragraphs by pressing Enter repeatedly. 3. When the selection goes out of the viewport, type some text. - The typed content is not visible. opw-4356668 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193498
Before this commit, the invoice cancelled with payment state set to "Invoicing App Legacy" is actually not really cancelled, it seems to just be a way to create accounting entry. However, the timesheets are considered as not billed if there is no invoice linked to them or if the invoice is cancelled (that is, if the state is set to "Cancelled"), which means, if the invoice is in "legacy status", the timesheets could move in a new invoice since those ones are considered as not billed. This com
Original PR description
Before this commit, the invoice cancelled with payment state set to "Invoicing App Legacy" is actually not really cancelled, it seems to just be a way to create accounting entry. However, the…
Before this commit, the invoice cancelled with payment state set to "Invoicing App Legacy" is actually not really cancelled, it seems to just be a way to create accounting entry. However, the timesheets are considered as not billed if there is no invoice linked to them or if the invoice is cancelled (that is, if the state is set to "Cancelled"), which means, if the invoice is in "legacy status", the timesheets could move in a new invoice since those ones are considered as not billed. This commit adds a condition to determine to know if a timesheet is not billed. The timesheet should now be: - not linked to an invoice - or the invoice linked should be cancelled and payment status should not be "Invoicing App Legacy". Steps to reproduce the issue: ---------------------------- 1. install Accounting, Sales and Timesheets app 2. Create a SO with a service product and confirm the SO 3. Create a timesheet for the SOL contained the service product 4. Create a invoice to partially invoice the service made for the SO. 5. Go to "Accounting app > Settings" 6. Enable the "Invoicing Switch Threshold" feature and make sure the date set on that feature is most recent than the one set on the invoice created in step 4. By doing that, the invoice created in step 4 should now be cancelled but with payment status set to "Invoicing App Legacy". 7. Create another timesheet for the same SOL 8. Go back to the SO created in step 2 and create another invoice to invoice the another timesheet. Current behavior: ---------------- The timesheet linked to the first invoice is now linked to the second one with the other timesheet. Expected behavior: ------------------ Since the first invoice is not really cancelled, the timesheet should still be linked to the invoice and so that timesheet should be considered as billed. opw-4556956 Forward-Port-Of: odoo/odoo#198669 Forward-Port-Of: odoo/odoo#198277
Versions -------- - 18.0+ Steps ----- 1. Have an expired credit card[^1]; 2. have an Odoo subscription; 3. pay subscription with expired credit card. Issue ----- Subscription chatter shows: > Automatic payment failed. No email sent this time. > Error: Worldline: The communication with the API failed. > Details: Cause ----- When a payment gets rejected for any reason like card expiration, Worldline returns the 402 HTTP response code[^2]. This is a nonstandard response indic
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have an expired credit card[^1]; 2. have an Odoo subscription; 3. pay subscription with expired credit card. Issue ----- Subscription chatter shows: >…
Versions -------- - 18.0+ Steps ----- 1. Have an expired credit card[^1]; 2. have an Odoo subscription; 3. pay subscription with expired credit card. Issue ----- Subscription chatter shows: > Automatic payment failed. No email sent this time. > Error: Worldline: The communication with the API failed. > Details: Cause ----- When a payment gets rejected for any reason like card expiration, Worldline returns the 402 HTTP response code[^2]. This is a nonstandard response indicating "Payment Required"[^3]. Because the 4xx HTTP status code range is reserved for client errors, we currently interpret the 402 response as a communication failure with the API instead of a rejected payment. Solution -------- Don't `raise_for_status` if the response belongs to one of the "expected" responses according to their API: - 200: Successful - 201: Created - 402: Payment rejected opw-4481602 [^1]: Wordline doesn't provide a way to easily test rejected payments. [^2]: https://apireference.connect.worldline-solutions.com/s2sapi/v1/en_US/json/response-codes.html [^3]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402 Forward-Port-Of: odoo/odoo#198652
Commit 9d986db17f14c7fcc05ba30df59b07b8c37d0a9d introduced a regression that caused `l10n_latam_invoice_document` to lose its header for the striped layout. In addition due to different position of the header img tag in the standard layout template HTML tree, `l10n_hu_edi` also required explicit base standard layout header classes in its attributes. This was caused by the xpath `//img/../..` introduced in f86238d7c872b3f025085831d50f1896168b6274 which thus unintentionally removed these classe
Original PR description
Commit 9d986db17f14c7fcc05ba30df59b07b8c37d0a9d introduced a regression that caused `l10n_latam_invoice_document` to lose its header for the striped layout. In addition due to different position of the header img tag in the standard layout template HTML tree, `l10n_hu_edi` also required explicit base standard layout header classes in its attributes. This was caused by the xpath `//img/../..` introduced in f86238d7c872b3f025085831d50f1896168b6274 which thus unintentionally removed these classes opw-4593505 Forward-Port-Of: odoo/odoo#198744
Current behavior before PR: - If a sequence_override_regex is set to a custom year regex, the default year_range regex is used instead if it matches the invoice name too. - Creating a new invoice fails if the custom sequence regex doesn't accept an empty or draft (i.e. '/') invoice name. Desired behavior after PR is merged: - If a sequence_override_regex is set, the default regexes are never used. - Creating a new invoice succeeds even if the custom sequence regex doesn't accept an e
Original PR description
Current behavior before PR: - If a sequence_override_regex is set to a custom year regex, the default year_range regex is used instead if it matches the invoice name too. - Creating a new invoice fails if the custom sequence regex doesn't accept an empty or draft (i.e. '/') invoice name. Desired behavior after PR is merged: - If a sequence_override_regex is set, the default regexes are never used. - Creating a new invoice succeeds even if the custom sequence regex doesn't accept an empty or draft (i.e. '/') invoice name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198710 Forward-Port-Of: odoo/odoo#196106
add a function to add discount Forward-Port-Of: odoo/odoo#198716 Forward-Port-Of: odoo/odoo#198588
Original PR description
add a function to add discount Forward-Port-Of: odoo/odoo#198716 Forward-Port-Of: odoo/odoo#198588
**Problem**: When the selection is empty (`anchorNode` and `focusNode` are `null`), calling `getRangeAt(0)` results in an error in Firefox. **Solution**: Properly check for an empty selection before accessing the range. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198807
Original PR description
**Problem**: When the selection is empty (`anchorNode` and `focusNode` are `null`), calling `getRangeAt(0)` results in an error in Firefox. **Solution**: Properly check for an empty selection before accessing the range. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198807
**Steps to reproduce:** - Install Accounting - Go to Accounting dashboard - Make sure that one journal has more action links than the other ones of the same row **Issue:** There is an offset between the bottom border of the kanban card and the graph that depends on the difference between the number of action links in the current card and the higher number of action links in a card on the same row.  **Cause:** The view has been refactored in version 18.0 and some css has been lost in the process. opw-4473451 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198106
**Steps to Reproduce:** 1. Create a new page using the **"New"** button and save it. 2. Publish the page using the **"Publish/Unpublish"** button. 3. Enter **Edit** mode (without reloading the page), update the page content, and save. 4. The SEO notification does not appear. **Reason for Change:** This PR fixes an issue where SEO notifications were not displayed after creating, publishing, editing, and saving a page. The fix ensures SEO data includes the website's publish s
Original PR description
**Steps to Reproduce:** 1. Create a new page using the **"New"** button and save it. 2. Publish the page using the **"Publish/Unpublish"** button. 3. Enter **Edit** mode (without reloading the page), update the page content, and save. 4. The SEO notification does not appear. **Reason for Change:** This PR fixes an issue where SEO notifications were not displayed after creating, publishing, editing, and saving a page. The fix ensures SEO data includes the website's publish status, which was previously missing in [1](https://github.com/odoo/odoo/commit/45ea6e4a4a5c8e314b110a45198fbe3d57bb996e). This update guarantees that the notification appears only when necessary. task- 4046471 Forward-Port-Of: odoo/odoo#198292 Forward-Port-Of: odoo/odoo#173793
SPECIFICATIONS Similar to '_mail_get_partners' being based on '_mail_get_partner_fields', define a helper to fetch primary email of records. It allows inheritance in some cases where directly field access is not possible. Use it in default recipients computation so that overrides are taken into account. This is going to be used notably in salary offer model which has linked models (applicant, employee), without or without partner, but no email field per se. Make suggested recipient
Original PR description
SPECIFICATIONS Similar to '_mail_get_partners' being based on '_mail_get_partner_fields', define a helper to fetch primary email of records. It allows inheritance in some cases where directly field…
SPECIFICATIONS Similar to '_mail_get_partners' being based on '_mail_get_partner_fields', define a helper to fetch primary email of records. It allows inheritance in some cases where directly field access is not possible. Use it in default recipients computation so that overrides are taken into account. This is going to be used notably in salary offer model which has linked models (applicant, employee), without or without partner, but no email field per se. Make suggested recipients computation being based on default recipients with some additional being added. This allows to remove some duplicated computation. Make suggested recipients computation available as a base method, to be used notably in templates on non-thread models. Also make it batch-enabled as it is currently running on a singleton recordset. This allows its usage in batch flows, like composers, templates, ... This requires some rewriting and code move in order to benefit from batch searches and prefetchs. Update tests and addon code accordingly. This has some impact on query counters. This will be fixed in upcoming PR, to allow testing and feedback on 18.2. Optimizing the code can be done in a few days. Todo in master: rework those methods to have a cleaner API and single return type. LINKS Direct followup of odoo/odoo#198173: cleanup default recipients computation Followup of odoo/odoo#172714: improve default behavior of templates Followup of odoo/odoo#188642 : main branch for email-like recipients Task-4555506: Cleanup / Mergeup default / suggested recipients Forward-Port-Of: odoo/odoo#198095
SPECIFICATIONS Similar to '_mail_get_partners' being based on '_mail_get_partner_fields', define a helper to fetch primary email of records. It allows inheritance in some cases where directly field access is not possible. Use it in default recipients computation so that overrides are taken into account. This is going to be used notably in salary offer model which has linked models (applicant, employee), without or without partner, but no email field per se. Make suggested recipient
Original PR description
SPECIFICATIONS Similar to '_mail_get_partners' being based on '_mail_get_partner_fields', define a helper to fetch primary email of records. It allows inheritance in some cases where directly field…
SPECIFICATIONS Similar to '_mail_get_partners' being based on '_mail_get_partner_fields', define a helper to fetch primary email of records. It allows inheritance in some cases where directly field access is not possible. Use it in default recipients computation so that overrides are taken into account. This is going to be used notably in salary offer model which has linked models (applicant, employee), without or without partner, but no email field per se. Make suggested recipients computation being based on default recipients with some additional being added. This allows to remove some duplicated computation. Make suggested recipients computation available as a base method, to be used notably in templates on non-thread models. Also make it batch-enabled as it is currently running on a singleton recordset. This allows its usage in batch flows, like composers, templates, ... This requires some rewriting and code move in order to benefit from batch searches and prefetchs. Update tests and addon code accordingly. Todo in master: rework those methods to have a cleaner API and single return type. LINKS Direct followup of odoo/odoo#198173: cleanup default recipients computation Followup of odoo/odoo#172714: improve default behavior of templates Followup of odoo/odoo#188642 : main branch for email-like recipients Task-4555506: Cleanup / Mergeup default / suggested recipients Forward-Port-Of: odoo/enterprise#79554
Following https://github.com/odoo/enterprise/commit/7de3281404c5e416c1c563cc56bd780e6414d682, column width calculations became incorrect as they didn't account for the fixed 36px width of folded columns. This could result in a scrollbar with varying width and cause a misleading display when only a single folded column was visible. The minimum column width in the month range was also adjusted to reduce rounding inconsistencies. Second commit fixes the pill resize test by allowing extra time fo
Original PR description
Following https://github.com/odoo/enterprise/commit/7de3281404c5e416c1c563cc56bd780e6414d682, column width calculations became incorrect as they didn't account for the fixed 36px width of folded columns. This could result in a scrollbar with varying width and cause a misleading display when only a single folded column was visible. The minimum column width in the month range was also adjusted to reduce rounding inconsistencies. Second commit fixes the pill resize test by allowing extra time for the badges to update before releasing the handles. The test previously failed intermittently because the badge text was incorrect, as it didn't have enough time to process all drag action events before being checked. Forward-Port-Of: odoo/enterprise#79847
Before when sending request to hmrc we had a fraud prevention headers creation but only with part of the data needed, client_data was provided for one of the two request. Another problem was the ips. If we are in a private network we should still send the public IP. task-4387562 Forward-Port-Of: odoo/enterprise#79108 Forward-Port-Of: odoo/enterprise#75383
Original PR description
Before when sending request to hmrc we had a fraud prevention headers creation but only with part of the data needed, client_data was provided for one of the two request. Another problem was the ips. If we are in a private network we should still send the public IP. task-4387562 Forward-Port-Of: odoo/enterprise#79108 Forward-Port-Of: odoo/enterprise#75383
- Fix the tags and attributes html to xml replacement to use longest matching - Fix the price calculations when a discount is added to an order line Forward-Port-Of: odoo/enterprise#79902 Forward-Port-Of: odoo/enterprise#79827
Original PR description
- Fix the tags and attributes html to xml replacement to use longest matching - Fix the price calculations when a discount is added to an order line Forward-Port-Of: odoo/enterprise#79902 Forward-Port-Of: odoo/enterprise#79827