Monday, May 19, 2025
32 changes · saas-18.3
Resolved issues and error corrections
This fixes an internal automated test that could fail when run on Sundays because two date systems represented Sunday differently. The change makes the comparison consistent, reducing false test failures and helping keep release validation reliable.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. Run `test_ir_sequence_iso_directives` on a Sunday. Issue ----- Test fails on the weekday. Cause ----- The sequence considers Sunday to be day `0`, whereas the control, based on `datetime.isocalendar` considers Sunday to be day `7`. Solution -------- Compare on the weekday, modulo 7. runbot-223209
Event registration searches now filter by the correct event start date. This ensures users get accurate results whether an event has a single schedule or multiple time slots.
Original PR description
Purpose ======= Fix the event_begin_date filtering on the event.registration search view. Specification ============= Following the addition of multi slots, the field has been changed to be computed. This messes up the filtering on the field in the search view. Adding a search method on the field to make sure the domain correctly applies on the slot start datetime if event is multi slots else on the event start date. related: odoo/odoo#205945 Task-4804722 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents edited link text from disappearing when a user opens the link editing popover and then chooses discard. It protects content changes made directly in the editor, reducing accidental data loss while editing website or document content.
Original PR description
Before the commit, changes made to the link text from outside the edit popover would not be saved if discard is clicked in the edit popover. Steps to reproduce: - click on a link - whitout clicking on the edit link button, change the link text - click the edit link button and then click discard - the changes done to the link text have been deleted
This update adjusts the Manufacturing work center screens so they can be redirected more reliably from related enterprise features. It is a small behind-the-scenes fix that helps users land on the correct work center view when moving between connected pages.
Original PR description
Add a path to the workcenter action to facilitate a redirect in the linked enterprise PR. task-4731403 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
**Purpose of this commit:** Attempting to use the Reply All or Forward actions from the mobile view results in a traceback. This occurs because the corresponding callbacks were not defined in the MessageActionMenuMobile component, which utilizes the action registry. This PR fixes the adding the function with the actions itself as that is the only place they will be used. **task-4794318** Forward-Port-Of: odoo/odoo#209879
Original PR description
**Purpose of this commit:** Attempting to use the Reply All or Forward actions from the mobile view results in a traceback. This occurs because the corresponding callbacks were not defined in the MessageActionMenuMobile component, which utilizes the action registry. This PR fixes the adding the function with the actions itself as that is the only place they will be used. **task-4794318** Forward-Port-Of: odoo/odoo#209879
Versions -------- - 17.4+ Steps ----- 1. Configure UoM decimal accuracy to be 0 digits; 2. create, confirm a SO; 3. create a downpayment invoice; 4. go back to the SO; 5. modify the product line's price. Issue ----- > AssertionError: precision_rounding must be positive, got 0. Cause ----- When checking for quantity changes to log on `write`, a fallback rounding value is retrieved using `precision_get`. This returns a `precision_digits` value, but is being used as a `precisio
Original PR description
Versions -------- - 17.4+ Steps ----- 1. Configure UoM decimal accuracy to be 0 digits; 2. create, confirm a SO; 3. create a downpayment invoice; 4. go back to the SO; 5. modify the product line's…
Versions -------- - 17.4+ Steps ----- 1. Configure UoM decimal accuracy to be 0 digits; 2. create, confirm a SO; 3. create a downpayment invoice; 4. go back to the SO; 5. modify the product line's price. Issue ----- > AssertionError: precision_rounding must be positive, got 0. Cause ----- When checking for quantity changes to log on `write`, a fallback rounding value is retrieved using `precision_get`. This returns a `precision_digits` value, but is being used as a `precision_rounding` value, resulting in an error when it is 0. In previous versions, this fallback value was never used, as `display_type` lines were skipped, and any other line is guaranteed to have a `product_uom.rounding` value. As of 9aa52dd6418e, the constraint was changed for `is_downpayment` lines not having to be of `display_type` nor require a `product_uom` value, meaning the faulty fallback value now gets used. Solution -------- Remove the fallback value, and only log lines with a `product_uom` value. opw-4566621 Forward-Port-Of: odoo/odoo#210417 Forward-Port-Of: odoo/odoo#205581
Consumption taxes are required for alcohol and other products, withthe POS module for Colombia coming out soon it's necessary to support such taxes out of the box for when it's released. A migration script has been added to automatically load these new taxes and accounts that will be necessary. task-4634313 Enterprise PR: https://github.com/odoo/enterprise/pull/84717 Forward-Port-Of: odoo/odoo#210394 Forward-Port-Of: odoo/odoo#208500
Original PR description
Consumption taxes are required for alcohol and other products, withthe POS module for Colombia coming out soon it's necessary to support such taxes out of the box for when it's released. A migration script has been added to automatically load these new taxes and accounts that will be necessary. task-4634313 Enterprise PR: https://github.com/odoo/enterprise/pull/84717 Forward-Port-Of: odoo/odoo#210394 Forward-Port-Of: odoo/odoo#208500
Before this commit, resizing columns in list views when being in right-to-left didn't work as expected: when resizing a column, the column was resized in the opposite direction. This commit makes it work. opw~4782197 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#210516 Forward-Port-Of: odo
Original PR description
Before this commit, resizing columns in list views when being in right-to-left didn't work as expected: when resizing a column, the column was resized in the opposite direction. This commit makes it work. opw~4782197 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#210516 Forward-Port-Of: odoo/odoo#210290
Scheduling a custom activity plan on a single record should do a `soft_reload` of the current view in order to avoid breadcrumbs pollution. The most frequent use case for that action is scheduling a plan from the chatter of the form view of a record, and retriggering an unnamed default form act_window would only restrict possible operations for the user. After this commit, the current view will be reloaded and the user will most probably be able to see its enabled plan in the chatter. t
Original PR description
Scheduling a custom activity plan on a single record should do a `soft_reload` of the current view in order to avoid breadcrumbs pollution. The most frequent use case for that action is scheduling a plan from the chatter of the form view of a record, and retriggering an unnamed default form act_window would only restrict possible operations for the user. After this commit, the current view will be reloaded and the user will most probably be able to see its enabled plan in the chatter. task-4525830 Forward-Port-Of: odoo/odoo#210168
- Add tour to set/unset preset and slot hours on a PoS order. task-id: 4684840 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208405 Forward-Port-Of: odoo/odoo#204251
Original PR description
- Add tour to set/unset preset and slot hours on a PoS order. task-id: 4684840 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208405 Forward-Port-Of: odoo/odoo#204251
A new amount type match was added for reconcile lines in the form of `from_transaction_details`. There is a value that is proposed by default for `regex`, but not for the new one, while the matching follows the same rule. We do expect atleast a group in the regex currently, but the user has no example on which to base itself. (they currently have a traceback but it will be fixed in https://github.com/odoo/enterprise/pull/84769) Description of the issue/feature this PR addresses: Current b
Original PR description
A new amount type match was added for reconcile lines in the form of `from_transaction_details`. There is a value that is proposed by default for `regex`, but not for the new one, while the matching follows the same rule. We do expect atleast a group in the regex currently, but the user has no example on which to base itself. (they currently have a traceback but it will be fixed in https://github.com/odoo/enterprise/pull/84769) 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#209492
Versions -------- - 17.0+ Steps ----- 1. Set up a Next Order Coupon program; 2. add Free Shipping as a reward; 3. create a coupon for current user with enough points to claim reward; 4. add a product to your cart; 5. go to check out; 6. claim Free Shipping. Issue ----- Free Shipping is still displayed as claimable Cause ----- The `_get_claimable_and_showable_rewards` method does not factor in whether the rewards have already been claimed on the current order. For discoun
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Set up a Next Order Coupon program; 2. add Free Shipping as a reward; 3. create a coupon for current user with enough points to claim reward; 4. add a product to your cart; 5. go to check out; 6. claim Free Shipping. Issue ----- Free Shipping is still displayed as claimable Cause ----- The `_get_claimable_and_showable_rewards` method does not factor in whether the rewards have already been claimed on the current order. For discounts & free products, this isn't an issue, as claiming them will use as many points as possible, meaning there's no points left to claim more, but free shipping can only be claimed once per order. Solution -------- Filter out rewards that have already been claimed. opw-4784359 Forward-Port-Of: odoo/odoo#210383 Forward-Port-Of: odoo/odoo#209508
Currently an error occurs during post-processing of a payment transaction. Steps to Reproduce: - Install the `website_sale` module. - Open `Reports > Quotation / Order` and enable the Invoice report option. - Go to the Website, place an order using the Wire Transfer payment provider. - Open `Scheduled Actions`. - Find and manually run the `Payment: Post-process transactions action`. `MissingError: Record does not exist or has been deleted. (Record: account.move(22,), User: 1)
Original PR description
Currently an error occurs during post-processing of a payment transaction. Steps to Reproduce: - Install the `website_sale` module. - Open `Reports > Quotation / Order` and enable the Invoice report…
Currently an error occurs during post-processing of a payment transaction. Steps to Reproduce: - Install the `website_sale` module. - Open `Reports > Quotation / Order` and enable the Invoice report option. - Go to the Website, place an order using the Wire Transfer payment provider. - Open `Scheduled Actions`. - Find and manually run the `Payment: Post-process transactions action`. `MissingError: Record does not exist or has been deleted. (Record: account.move(22,), User: 1)` This issue was generated because the user clicked on the invoice report option on the report Quotation / Order as a result, when we try to print qutation /order it tries to browse the sale.order with id 22 as an account.move. This commit ensures that the is_invoice_report field is only visible when the model is account.move. Additionally, the_is_invoice_report method has been modified to return True only when the model is account.move, thereby preventing a MissingError during scheduled actions. Sentry-6563415103 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209255 Forward-Port-Of: odoo/odoo#207635
- creating pos config and payment method requires pos admin (or sudo) - creating a pos order requires pos user Blows up during nightly single app tests. https://runbot.odoo.com/odoo/error/223001 Forward-Port-Of: odoo/odoo#210368
Original PR description
- creating pos config and payment method requires pos admin (or sudo) - creating a pos order requires pos user Blows up during nightly single app tests. https://runbot.odoo.com/odoo/error/223001 Forward-Port-Of: odoo/odoo#210368
Creating POS metaobject requires pos admin access, or sudo. https://runbot.odoo.com/odoo/error/223012 Forward-Port-Of: odoo/odoo#210373
Original PR description
Creating POS metaobject requires pos admin access, or sudo. https://runbot.odoo.com/odoo/error/223012 Forward-Port-Of: odoo/odoo#210373
before this commit, in the profitability dashboard the cogs section is show with label cost_of_goods_sold  after this commit, the label will be shown as Cost of Goods Sold  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo
Original PR description
before this commit, in the profitability dashboard the cogs section is show with label cost_of_goods_sold  after this commit, the label will be shown as Cost of Goods Sold  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210013 Forward-Port-Of: odoo/odoo#209868
Description: --- The action to update Taxes and Accounts when changing the fiscal pos on invoice isn't considering the change in price_unit for lines with price included taxes. Steps to Reproduce: --- 1- Create a 21% tax and another 6% tax, both are included in price 2- Create a fiscal position that will map the 21% tax by the 6% tax 3- Create a product with Price = 121€, and Tax = 21% 4- Create an invoice with this product. 5- On the (Other info) tab, set the Fiscal Position to the o
Original PR description
Description: --- The action to update Taxes and Accounts when changing the fiscal pos on invoice isn't considering the change in price_unit for lines with price included taxes. Steps to Reproduce:…
Description: --- The action to update Taxes and Accounts when changing the fiscal pos on invoice isn't considering the change in price_unit for lines with price included taxes. Steps to Reproduce: --- 1- Create a 21% tax and another 6% tax, both are included in price 2- Create a fiscal position that will map the 21% tax by the 6% tax 3- Create a product with Price = 121€, and Tax = 21% 4- Create an invoice with this product. 5- On the (Other info) tab, set the Fiscal Position to the one created (from 21 to 6). 6- Click on update taxes and accounts: The price will still be 121 while the taxes will change to 6%, and total = 121. 7- Then if you added a new line with the product now after setting the fiscal pos , you will get price= 106, tax=6%, total = 106. which are the right values. Cause: --- The action created for updating taxes and accounts didn't consider price changes for price included taxes. Fix: --- Add call to _compute_price_unit() opw-4672466 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208780
When generating the JO UBL file, we want to keep the PartyIdentification and its ID node, even if the latter is empty. Also, in the same file, the country code of a partner should be set to 'PN' if the partner doesn't have its country set. task-4656827 Forward-Port-Of: odoo/odoo#210356 Forward-Port-Of: odoo/odoo#206488
Original PR description
When generating the JO UBL file, we want to keep the PartyIdentification and its ID node, even if the latter is empty. Also, in the same file, the country code of a partner should be set to 'PN' if the partner doesn't have its country set. task-4656827 Forward-Port-Of: odoo/odoo#210356 Forward-Port-Of: odoo/odoo#206488
Why the fix: ------------ This fix https://github.com/odoo/odoo/commit/9002edacd210730a97f5ddc9459cfaa1fb9631bd wasn't fully forward ported. On 18.2, the fix had to include this one https://github.com/odoo/odoo/commit/180c46f8ab0df68cd469ddf4bc68895f0e7b8e12 and the part were we fetch the oustanding account if there is none after creation was forgotten. We now re-introduce it. opw-4317320 Forward-Port-Of: odoo/odoo#210069
Original PR description
Why the fix: ------------ This fix https://github.com/odoo/odoo/commit/9002edacd210730a97f5ddc9459cfaa1fb9631bd wasn't fully forward ported. On 18.2, the fix had to include this one https://github.com/odoo/odoo/commit/180c46f8ab0df68cd469ddf4bc68895f0e7b8e12 and the part were we fetch the oustanding account if there is none after creation was forgotten. We now re-introduce it. opw-4317320 Forward-Port-Of: odoo/odoo#210069
Before this commit: We did not handle the date format in case the ewaybill is generated through IRN. After this commit: We handle the format where the ewaybill is generated through IRN --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210316
Original PR description
Before this commit: We did not handle the date format in case the ewaybill is generated through IRN. After this commit: We handle the format where the ewaybill is generated through IRN --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210316
### Steps to reproduce: - In the settings enable Multi-Step - Unarchive the MTO route - Create a storable product P with bom of type kit: - 1 x MTO COMP: with routes MTO and buy and set vendor - 1 X not MTO COMP: without routes - Create and confirm a sale order for 1 units of P - Update the quantity of the sale order line from 1 to 5 #### > The delivery is now for 6 units of both kit component ### Cause of the issue: Updating the quantity on the SOL will launch a call of
Original PR description
### Steps to reproduce: - In the settings enable Multi-Step - Unarchive the MTO route - Create a storable product P with bom of type kit: - 1 x MTO COMP: with routes MTO and buy and set vendor - 1 X…
### Steps to reproduce:
- In the settings enable Multi-Step
- Unarchive the MTO route
- Create a storable product P with bom of type kit:
- 1 x MTO COMP: with routes MTO and buy and set vendor
- 1 X not MTO COMP: without routes
- Create and confirm a sale order for 1 units of P
- Update the quantity of the sale order line from 1 to 5
#### > The delivery is now for 6 units of both kit component
### Cause of the issue:
Updating the quantity on the SOL will launch a call of the `_action_launch_stock_rule`.The quantity of the new procurement is then processed by these lines based on the kit data's: https://github.com/odoo/odoo/blob/65704e58fda293af727f76d5c0741b135817db99/addons/sale_stock/models/sale_order_line.py#L359 https://github.com/odoo/odoo/blob/65704e58fda293af727f76d5c0741b135817db99/addons/sale_mrp/models/sale_order_line.py#L153-L160 However, since one component uses the MTO route and the other does not the filter based on rules will fail since one of the component move refer to the mto rule and the other one to the delivery rule. In particular the computation will always lead to a result of 0 no matter how many are really processed because only one of the 2 moves can respect the filter.
opw-4700925
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#209168
Forward-Port-Of: odoo/odoo#205538Steps to reproduce: 1. Go to Events. 2. Create a new event with a long name. 3. Add a product. 4. Print the "Badge Example". Issue: When printing a badge from an event with a long name, the QR code overlaps or clips the information above it, making the badge unreadable. Cause: The issue is due to the large font size used for the event name. Solution: Reduced the font size of the event title to fs-5 to ensure enough spacing is maintained between the text and the QR code, avoiding
Original PR description
Steps to reproduce: 1. Go to Events. 2. Create a new event with a long name. 3. Add a product. 4. Print the "Badge Example". Issue: When printing a badge from an event with a long name, the QR code overlaps or clips the information above it, making the badge unreadable. Cause: The issue is due to the large font size used for the event name. Solution: Reduced the font size of the event title to fs-5 to ensure enough spacing is maintained between the text and the QR code, avoiding layout overlap. opw : 4783750 Before FIX:  After FIX:  Forward-Port-Of: odoo/odoo#209816
Like the sugar tax, alcohol is also taxed differently in Colombia such that we need a special case for how to compute it. The Per Unit Amount is the total tax amount divided by the alcohol percentage. To facilitate this change, the field that was previously used for the volume in ml for sugary drinks has been made into a generic "Specific Component Nominal Tax" field which can be used for any extra tax data depending on what type of tax is on the product. Comm PR: https://github.com/odoo/o
Original PR description
Like the sugar tax, alcohol is also taxed differently in Colombia such that we need a special case for how to compute it. The Per Unit Amount is the total tax amount divided by the alcohol percentage. To facilitate this change, the field that was previously used for the volume in ml for sugary drinks has been made into a generic "Specific Component Nominal Tax" field which can be used for any extra tax data depending on what type of tax is on the product. Comm PR: https://github.com/odoo/odoo/pull/208500 task-4634313 Forward-Port-Of: odoo/enterprise#85764 Forward-Port-Of: odoo/enterprise#84717
In the Italian balance sheet, the section for “d-bis. Other enterprises” is not added to the calculation for the section “1. Holdings in:”. As a result, it is not included in the calculation for assets in the balance sheet. This commit adds the section “d-bis. Other enterprises” to the calculation of “1. Holdings in”. This specification is based on Article 2424(1) of the Italian Civil Code: https://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:regio.decreto:1942-03-16;262 Steps to Repro
Original PR description
In the Italian balance sheet, the section for “d-bis. Other enterprises” is not added to the calculation for the section “1. Holdings in:”. As a result, it is not included in the calculation for assets in the balance sheet. This commit adds the section “d-bis. Other enterprises” to the calculation of “1. Holdings in”. This specification is based on Article 2424(1) of the Italian Civil Code: https://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:regio.decreto:1942-03-16;262 Steps to Reproduce on Runbot: 1. Install l10n_it_reports 2. Create an account starting with 1306 3. Create a journal entry using account 1306 as the debit line and balance it with a credit line 4. Check the Italian balance sheet and notice that “d-bis. Other enterprises” is not included in the calculation for assets in the Italian balance sheet Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4763868) opw-4763868 Forward-Port-Of: odoo/enterprise#84586
The overhaul of html editor into knowledge introduced an issue involving the auto-vaccuum. This commit https://github.com/odoo/enterprise/commit/08d84f8b61450a0ebd0d2aadfe8f227bda283edd passes the res_id value of the currently existing knowledge.cover record. However, when we set a new cover image, we will always create a new cover record and the new cover image attachments are linked to the previous cover record. The auto-vaccuum then deletes unused cover images and any attachments linked,
Original PR description
The overhaul of html editor into knowledge introduced an issue involving the auto-vaccuum. This commit https://github.com/odoo/enterprise/commit/08d84f8b61450a0ebd0d2aadfe8f227bda283edd passes the res_id value of the currently existing knowledge.cover record. However, when we set a new cover image, we will always create a new cover record and the new cover image attachments are linked to the previous cover record. The auto-vaccuum then deletes unused cover images and any attachments linked, which will delete the actual cover image. The web_unsplash/attachment/add does not need to pass in a res_id of the cover image since we always create a new record at the end of the workflow. opw-4629300 Forward-Port-Of: odoo/enterprise#85549
The rental_cart_update_duration tour was failing due to a timeout while selecting for the .o_time_picker_select:eq(0) element. This change add a wait step was to ensure the rental options are fully loaded before proceeding. Avoiding flaky behavior caused by timing issues in the UI. build_error-161173 Forward-Port-Of: odoo/enterprise#85393
Original PR description
The rental_cart_update_duration tour was failing due to a timeout while selecting for the .o_time_picker_select:eq(0) element. This change add a wait step was to ensure the rental options are fully loaded before proceeding. Avoiding flaky behavior caused by timing issues in the UI. build_error-161173 Forward-Port-Of: odoo/enterprise#85393
**Steps** 1. Upload a PDF & Sign > Upload PDF 2. Add a text item 3. Sign Now > Sign Now 4. Enter 123456789123456789 as text 5. Validate & Send Completed Document 6. Go to Documents > All Documents > Open the Document The number displayed is wrong by a small amount (123456789123456780). This happens because the number is bigger than Javascript's MAX_SAFE_INTEGER. Other problematic example: a sign item with "false" as text. **Solution** We can avoid parsing the text of the sign item.
Original PR description
**Steps** 1. Upload a PDF & Sign > Upload PDF 2. Add a text item 3. Sign Now > Sign Now 4. Enter 123456789123456789 as text 5. Validate & Send Completed Document 6. Go to Documents > All Documents > Open the Document The number displayed is wrong by a small amount (123456789123456780). This happens because the number is bigger than Javascript's MAX_SAFE_INTEGER. Other problematic example: a sign item with "false" as text. **Solution** We can avoid parsing the text of the sign item. opw-4479406 Forward-Port-Of: odoo/enterprise#85195 Forward-Port-Of: odoo/enterprise#77422
**Steps to reproduce** - Install website_sale_subscription - On the website page of a product, enter the editor and enable the "Tax Indication" setting for the product page. - The tax indication information doesn't appear for subscription products.  **Cause** Issue since commit 7d160198be779095660e7f6fb68ae231e4621972 which hides default pricing information from `website_sale` for subscription produc
Original PR description
**Steps to reproduce** - Install website_sale_subscription - On the website page of a product, enter the editor and enable the "Tax Indication" setting for the product page. - The tax indication information doesn't appear for subscription products.  **Cause** Issue since commit 7d160198be779095660e7f6fb68ae231e4621972 which hides default pricing information from `website_sale` for subscription products, including the tax indication. opw-4637308 Forward-Port-Of: odoo/enterprise#84669
- 18.0 **Steps to Reproduce:** - Create a subscription with a custom end date (e.g., 2025-04-09). - Manually generate an invoice covering a specific period (e.g., March 10 to April 9). - Wait until after the end date has passed (e.g., run expiration cron on 10 April or later). - The expiration cron triggers and overwrites the manually set end_date with the current date **Issue:** - The expiration cron overrides the existing end_date of the subscription. **Cause:** - The _get_c
Original PR description
- 18.0 **Steps to Reproduce:** - Create a subscription with a custom end date (e.g., 2025-04-09). - Manually generate an invoice covering a specific period (e.g., March 10 to April 9). - Wait until after the end date has passed (e.g., run expiration cron on 10 April or later). - The expiration cron triggers and overwrites the manually set end_date with the current date **Issue:** - The expiration cron overrides the existing end_date of the subscription. **Cause:** - The _get_closing_end_date method sets the end_date unconditionally during closure, even when an end_date is already defined. **Solution:** - Update the _get_closing_end_date logic to return the existing end_date if it is already set and valid, preventing it from being overridden when called by the expiration cron. task-4703577 Forward-Port-Of: odoo/enterprise#85465 Forward-Port-Of: odoo/enterprise#84475
After ELM Certification, monthly summary was not properly adapted for the two available aggregation modes Forward-Port-Of: odoo/enterprise#85754 Forward-Port-Of: odoo/enterprise#85287
Original PR description
After ELM Certification, monthly summary was not properly adapted for the two available aggregation modes Forward-Port-Of: odoo/enterprise#85754 Forward-Port-Of: odoo/enterprise#85287
Before this commit, the #84245 adds an extra_domain to find the customer to assign on the ticket based on the email address received. The problem is the partners could also have no company set and so the method could not find the existing partner with the email given and will create a duplicate partner because of that. This commit adds inside the extra_domain to also search on partner without any company set to be sure to not create duplicate the partner. Forward-Port-Of: odoo/enterprise#856
Original PR description
Before this commit, the #84245 adds an extra_domain to find the customer to assign on the ticket based on the email address received. The problem is the partners could also have no company set and so the method could not find the existing partner with the email given and will create a duplicate partner because of that. This commit adds inside the extra_domain to also search on partner without any company set to be sure to not create duplicate the partner. Forward-Port-Of: odoo/enterprise#85605 Forward-Port-Of: odoo/enterprise#85173
This fixes two issues with the report. The first one is automatically requesting an English report if the customer's preferred language is not Spanish. This way the lang field on the partner is somewhat respected for these externally generated reports too. The second fix requests a dedicated addenda page when appropriate. By default, the addenda (e.g. terms and conditions) is added in a small box at the bottom of the standard PDF report. This can only accomodate roughly 6 lines of 140 charact
Original PR description
This fixes two issues with the report. The first one is automatically requesting an English report if the customer's preferred language is not Spanish. This way the lang field on the partner is somewhat respected for these externally generated reports too. The second fix requests a dedicated addenda page when appropriate. By default, the addenda (e.g. terms and conditions) is added in a small box at the bottom of the standard PDF report. This can only accomodate roughly 6 lines of 140 characters. If the addenda exceeds that, the remainder is silently cut off which is problematic for mandatory disclosures etc. It's possible to request a dedicated addenda page in the PDF that fixes this issue. We considered always requesting it, but it looks strange to have a whole page in the PDF if the addenda is very short. We therefore make a best effort attempt to figure out if the addenda will fit in the standard report or not. task-4750717 Forward-Port-Of: odoo/enterprise#81188