Monday, May 19, 2025
32 changes · saas-18.2
Resolved issues and error corrections
This change updates the Argentine point-of-sale test setup so it has the required permissions when creating POS configuration data. It helps keep automated checks reliable and prevents access-rights errors from blocking validation of POS behavior.
Original PR description
Creating POS metaobject requires pos admin access, or sudo. https://runbot.odoo.com/odoo/error/223012
This fixes an intermittent Point of Sale test failure when opening preset timing repeatedly. The change helps ensure the timing popup finishes opening before another action starts, improving stability without changing the user-facing workflow.
Original PR description
Fix runbot error when using preset timing in tour. Now we have an async lock for the function `openPresetTiming` so when opening this popup we make sure the previous one is finished. Also, inside the tour `test_preset_timing` we added a step to wait for the synchronization to be finished before opening the preset timing popup again. runbot error: 213368 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Mobile users can now use Reply All and Forward in messages without triggering an error. This restores expected email handling behavior on mobile and prevents interruptions when responding to conversations.
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**
This change removes a duplicate field from the ISO 20022 journal setup. It helps keep accounting configuration screens clearer and avoids confusion from seeing the same field more than once.
Original PR description
Duplicate field was introduced in https://github.com/odoo/enterprise/commit/0703cf2834aeca2db498575ac6e0a35e37e7d048 Duplicate of : https://github.com/odoo/enterprise/pull/85692/files#diff-a75131997102fa2a43d54afca5d43c93165f9eb91a0afc1a707d82ad80e35cf9L48
This update prevents a crash when installing loan-related demo data in certain accounting setups. It also adjusts an accounting report test so automated checks work correctly whether the full accounting app is installed or not, improving release reliability.
Miscellaneous changes
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
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
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
This reverts commit 7ce1ba9f29f9b1edd5f2507492e45ef92d9ba868. Before the commit (1) We would iterate through the possible items and see if the partner has the field. As the partner in the test setup does not have `company_registry`, it will iterate on the second value, `vat`, which is set on the partner https://github.com/odoo/odoo/blob/037fabd81efc28c12359700ee8e21e0454e0535e/addons/l10n_dk/models/res_partner.py#L7-L18 which will be the key `0198` For this key, we have mocked the respons
Original PR description
This reverts commit 7ce1ba9f29f9b1edd5f2507492e45ef92d9ba868. Before the commit (1) We would iterate through the possible items and see if the partner has the field. As the partner in the test setup…
This reverts commit 7ce1ba9f29f9b1edd5f2507492e45ef92d9ba868. Before the commit (1) We would iterate through the possible items and see if the partner has the field. As the partner in the test setup does not have `company_registry`, it will iterate on the second value, `vat`, which is set on the partner https://github.com/odoo/odoo/blob/037fabd81efc28c12359700ee8e21e0454e0535e/addons/l10n_dk/models/res_partner.py#L7-L18 which will be the key `0198` For this key, we have mocked the response: https://github.com/odoo/odoo/blob/e62a86939b0b327e2c16a82b0829dac80ef1ff32/addons/account_peppol/tests/test_peppol_messages.py#L153-L155 After the commit (1), we stop at the first iteration since `vat` is defined on the partner's fields. The key is `0184` -> we don't have any mocked response for this key, we we wazt to load the response's body which does not exist -> kaboom I'm not sure that we wanted to change this value in the first place as from Julien, we wanted the company registry https://github.com/odoo/odoo/commit/ad37ebefb9fb7cb3c9593730f174dd6f1d73a31e https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/DK-R-014/ + the company registry == the vat for the danish localisation https://github.com/odoo/odoo/blob/037fabd81efc28c12359700ee8e21e0454e0535e/addons/l10n_dk/models/res_partner.py#L7-L18 --- commit (1) https://github.com/odoo/odoo/commit/7ce1ba9f29f9 runbot-163142 Forward-Port-Of: odoo/odoo#209498
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
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
- 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
This commit removes a useless break line added to the end of chat ratign. Break line is used to put the reason on a different line than the rating smiley but is useless when no reason is passed. task-4791376 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#209776 Forward-Port-Of: odoo/odoo#20
Original PR description
This commit removes a useless break line added to the end of chat ratign. Break line is used to put the reason on a different line than the rating smiley but is useless when no reason is passed. task-4791376 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#209776 Forward-Port-Of: odoo/odoo#209571
**Steps to reproduce:** - Install l10n_it_edi - Switch to an Italian company (e.g. IT Company) - Create an invoice - Confirm the invoice => Document Type (in "Electronic Invoicing" tab) is computed - Create a credit note from the invoice - On credit note wizard, click on "Reverse and Create Invoice" - Check the created credit note **Issue:** The credit note is posted but its Document Type field (l10n_it_document_type) is empty. l10n_it_document_type should be computed when it doesn'
Original PR description
**Steps to reproduce:** - Install l10n_it_edi - Switch to an Italian company (e.g. IT Company) - Create an invoice - Confirm the invoice => Document Type (in "Electronic Invoicing" tab) is computed -…
**Steps to reproduce:** - Install l10n_it_edi - Switch to an Italian company (e.g. IT Company) - Create an invoice - Confirm the invoice => Document Type (in "Electronic Invoicing" tab) is computed - Create a credit note from the invoice - On credit note wizard, click on "Reverse and Create Invoice" - Check the created credit note **Issue:** The credit note is posted but its Document Type field (l10n_it_document_type) is empty. l10n_it_document_type should be computed when it doesn't have a value already and the state of the move is "posted". The credit note will be rejected when sent to SDI because this field is empty. **Cause:** In the reverse method, the field is set to False in order to be recomputed. However, the compute method is triggered when the state changes, but the credit note not is already posted. Therefore the field will not be recomputed. **Solution:** Set the value to False before the creation of the credit note. So that, the field will be recomputed when posting the credit note. opw-4689755 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210361 Forward-Port-Of: odoo/odoo#208654
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
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
After this commit, the full width of the Activities column in a list view will be clickable, for ease of use. task-4525830 Forward-Port-Of: odoo/odoo#210351 Forward-Port-Of: odoo/odoo#210169
Original PR description
After this commit, the full width of the Activities column in a list view will be clickable, for ease of use. task-4525830 Forward-Port-Of: odoo/odoo#210351 Forward-Port-Of: odoo/odoo#210169
Description of the issue/feature this PR addresses: It's possible to setup an inherited view with groups if we update the mode Steps: - Open an inherited view form - Change its mode to "Base" - Add a group - Rollback the mode to "Inherited" - Save, no problem - Try to upgrade a module linked to this view Current behavior before PR: - Traceback as inherited view cannot have groups Desired behavior after PR is merged: - Save is not possible opw-3263438 opw-3774300 --- I
Original PR description
Description of the issue/feature this PR addresses: It's possible to setup an inherited view with groups if we update the mode Steps: - Open an inherited view form - Change its mode to "Base" - Add a group - Rollback the mode to "Inherited" - Save, no problem - Try to upgrade a module linked to this view Current behavior before PR: - Traceback as inherited view cannot have groups Desired behavior after PR is merged: - Save is not possible opw-3263438 opw-3774300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156279
The theme preview feature before selection was disabled in [1]. This commit precises the TODO comment that was added with it. It comes alongside a theme repo commit which actually disables the related nightly test of the feature... that was red since then. [1]: https://github.com/odoo/odoo/commit/7cb71e9479df0ee9af0b7ad39302857666726177 Related to task-3454790 Forward-Port-Of: odoo/odoo#210140
Original PR description
The theme preview feature before selection was disabled in [1]. This commit precises the TODO comment that was added with it. It comes alongside a theme repo commit which actually disables the related nightly test of the feature... that was red since then. [1]: https://github.com/odoo/odoo/commit/7cb71e9479df0ee9af0b7ad39302857666726177 Related to task-3454790 Forward-Port-Of: odoo/odoo#210140
Steps to print the check: 1. Ensure l10n_us_check_printing is installed 2. Set the check layout to Print Check (Middle) - US 3. Create a PO and a bill from it. 4. Create a payment for the bill using checks as your payment method 5. Click Print Check on the payment Current behavior before PR: The checks would print the vendor's name in the stubs, and the date alignment in the (middle) format was overlapping with the check number. Description of the issue/feature this PR addresses: Th
Original PR description
Steps to print the check: 1. Ensure l10n_us_check_printing is installed 2. Set the check layout to Print Check (Middle) - US 3. Create a PO and a bill from it. 4. Create a payment for the bill using…
Steps to print the check: 1. Ensure l10n_us_check_printing is installed 2. Set the check layout to Print Check (Middle) - US 3. Create a PO and a bill from it. 4. Create a payment for the bill using checks as your payment method 5. Click Print Check on the payment Current behavior before PR: The checks would print the vendor's name in the stubs, and the date alignment in the (middle) format was overlapping with the check number. Description of the issue/feature this PR addresses: The checks are aligned with the expected format and conditionally render the correct fields in the document's intended areas. Desired behavior after PR is merged: The printed check will now match the format and alignment of the templates used here: https://checkdepot.net/collections/odoo-checks/products/odoo-checks-top- format. Additionally, the check will now avoid printing the issuing company name on the stubs when the manual numbering setting on the bank journal is switched off. This assumes that the checks are preprinted with the company name and check number. opw-4557006 opw-4738359 Enterprise PR: https://github.com/odoo/enterprise/pull/84644 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210074 Forward-Port-Of: odoo/odoo#208357
Scenario: - add a cover snippet with 100% height at the top of the page - open the page on a mobile (eg. safari on iOS) - scroll down the page Result: there is a vertical jittering of the content of cover snippet when going down. Cause: we are setting the size in pixel to {viewport height} - {height of stuff (menu, logged in user bar, ...)} but the mobile browser changes the viewport height when going down and hiding the address bar UI, so the fixed pixel height is only updated wh
Original PR description
Scenario:
- add a cover snippet with 100% height at the top of the page
- open the page on a mobile (eg. safari on iOS)
- scroll down the page
Result: there is a vertical jittering of the content of cover snippet
when going down.
Cause: we are setting the size in pixel to {viewport height} - {height
of stuff (menu, logged in user bar, ...)} but the mobile browser changes
the viewport height when going down and hiding the address bar UI, so
the fixed pixel height is only updated when the code is called again
instead of being adapted smoothly.
Fix: set the height of the cover using 100dvh minus the size of the
content, so the height is increased/decreased smoothly by the
application of CSS.
opw-4575726
Forward-Port-Of: odoo/odoo#209926Before 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
Before this commit, the filename for pdf reports when previewed from the portal is "\<database ID\>.pdf" instead of a readable name like "Sales-Order-S00001".pdf. This can be especially confusing if the database ID is a different number from the record's sequence number. Steps to reproduce ----- 1. Open a sales order in the customer portal 2. Select the Print button 3. From the pdf preview, Print -> Save to PDF 4. The downloaded filename is "\<database ID\>.pdf", also the browser title b
Original PR description
Before this commit, the filename for pdf reports when previewed from the portal is "\<database ID\>.pdf" instead of a readable name like "Sales-Order-S00001".pdf. This can be especially confusing if the database ID is a different number from the record's sequence number. Steps to reproduce ----- 1. Open a sales order in the customer portal 2. Select the Print button 3. From the pdf preview, Print -> Save to PDF 4. The downloaded filename is "\<database ID\>.pdf", also the browser title bar is just the database ID Cause ----- No filename is being set in the Content-Disposition header, so the browser takes the filename from the last segment of the URL which is the database ID. Solution ----- Set an inline Content-Disposition with the filename argument when previewing, similar to what is done when downloading. opw-4710501 Forward-Port-Of: odoo/odoo#210424 Forward-Port-Of: odoo/odoo#207357
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
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
Steps to print the check: 1. Ensure l10n_us_check_printing is installed 2. Set the check layout to Print Check (Middle) - US in the settings 3. Create a PO and a bill from it. 4. Create a payment for the bill using checks as your payment method 5. Click Print Check on the payment The printed check will now match the format and alignment of the templates used [here](https://checkdepot.net/collections/odoo-checks?_pos=1&_psq=odoo&_ss=e&_v=1.0). Additionally, the check will now avoid printi
Original PR description
Steps to print the check: 1. Ensure l10n_us_check_printing is installed 2. Set the check layout to Print Check (Middle) - US in the settings 3. Create a PO and a bill from it. 4. Create a payment for…
Steps to print the check: 1. Ensure l10n_us_check_printing is installed 2. Set the check layout to Print Check (Middle) - US in the settings 3. Create a PO and a bill from it. 4. Create a payment for the bill using checks as your payment method 5. Click Print Check on the payment The printed check will now match the format and alignment of the templates used [here](https://checkdepot.net/collections/odoo-checks?_pos=1&_psq=odoo&_ss=e&_v=1.0). Additionally, the check will now avoid printing the issuing company name on the stubs when the manual numbering setting on the bank journal is switched off. This assumes that the checks are preprinted with the company name and check number. Before the fix, the checks printed the vendor's name in the stubs, and the date alignment in the (middle) format overlapped with the check number. After the fix, the checks are aligned with the expected format and conditionally render the correct fields in the document's intended areas. opw-4557006 opw-4738359 odoo PR: https://github.com/odoo/odoo/pull/208357 Forward-Port-Of: odoo/enterprise#85578 Forward-Port-Of: odoo/enterprise#84644
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
### Steps to reproduce: - Create an invoice with a due date past for long time - Accounting > Customers, click on the partner of the invoice - In the page "Accounting" the "Follow-up Status" should be "In need of action" - Go to the Scheduled Action "Account Report Followup; Execute followup" and Run manually - Go back to the partner - The follow-up is send without the invoices ### Cause: This [commit](https://github.com/odoo/enterprise/pull/84114) moved a part of code to fix a bug but
Original PR description
### Steps to reproduce:
- Create an invoice with a due date past for long time
- Accounting > Customers, click on the partner of the invoice
- In the page "Accounting" the "Follow-up Status" should be "In need of action"
- Go to the Scheduled Action "Account Report Followup; Execute followup" and Run manually
- Go back to the partner
- The follow-up is send without the invoices
### Cause:
This [commit](https://github.com/odoo/enterprise/pull/84114) moved a part of code to fix a bug but it also changed it: it moved `'attachment_ids' not in options` from the end to the beginning. By doing that the line
`options.get('attachment_ids', self._get_invoices_to_print(options).message_main_attachment_id.ids)`
does not work anyore because `attachment_ids` is always in `options` so `_get_invoices_to_print` is never called.
### Solution:
Use `setdefault` instead of `get`.
opw-4716458
Forward-Port-Of: odoo/enterprise#85124**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
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
Partial payments in POS are buggy if there is no pay later POS payment method Steps to reproduce: 1. Navigate to Point of Sale > Configuration > Payment Methods 2. Archive the "Customer Account" payment method (which is of `type == 'pay_later'`) 3. Try to settle a partially paid invoice in POS 4. Selecting the the "Validate" button will close the order without settling and will leave the UI in a buggy state where any further interactions produce a traceback Solution: Block the use
Original PR description
Partial payments in POS are buggy if there is no pay later POS payment method Steps to reproduce: 1. Navigate to Point of Sale > Configuration > Payment Methods 2. Archive the "Customer Account" payment method (which is of `type == 'pay_later'`) 3. Try to settle a partially paid invoice in POS 4. Selecting the the "Validate" button will close the order without settling and will leave the UI in a buggy state where any further interactions produce a traceback Solution: Block the user from settling dues or making deposits when no pay_later payment method is loaded. OPW-4712869 The following error dialog is shown: <img width="163" alt="Screenshot 2025-04-18 at 00 28 41" src="https://github.com/user-attachments/assets/7651c863-bc75-4486-8483-8a8ee2fed5db" /> Forward-Port-Of: odoo/enterprise#83702 Forward-Port-Of: odoo/enterprise#83650
- 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