Tuesday, April 15, 2025
15 changes · saas-17.4
Resolved issues and error corrections
This update tidies Swiss localization screens by documenting hidden technical fields that are still needed for compatibility checks. It helps keep stable-version tests passing while avoiding disruption to customized views.
Original PR description
Before this commit, several invisible fields were present in the views in `l10n_ch`, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed. The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031. This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views. We will removes the unnecessary invisible fields in master. opw-4629332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Log notes posted on a record from a chat window will now remain as separate entries instead of being merged together. This makes record discussions clearer and helps users avoid missing individual internal notes.
Original PR description
Purpose of this commit: This commit aims to restrict the log notes to not be squashed when posted on a record from a chat window. task-4718225
A test setup for timesheet and holidays was corrected so it uses the right employee and user relationship when creating leave records. This prevents internal automated tests from failing after stricter access rules were applied, helping keep the module stable without changing business behavior.
Original PR description
https://runbot.odoo.com/odoo/error/163099 This issue became visible as part of the change to test ACLs (removal of demo data, possibly change to groups too) as well as running the "single app tests" on *every module*, not just the apps. The issue is that `self.Requests.user` and `self.employee_user` are unrelated (the amazingly named `self.employee_user` doesn't even have a user). On leave creation, this triggers the rule `hr_leave_rule_employee_update` which checks if: - The current user is the employee's, which is not the case because the employee doesn't have a user. - Or the current user is the employee's leave manager, which is also not the case because the employee does not have a leaves manager. As a result the creation of the leaves fails immediately. Fix in 17.4 as the test was introduced in #53940 which was merged in (what would become) 17.3, even though the test setup means it might not be possible to trigger there because of all the demo messing with groups.
Miscellaneous changes
Versions -------- - 16.0+ Steps ----- 1. Enable Paypal as payment provider; 2. have a US-based partner; 3. sent them a payment link; 4. pay using Paypal; 5. open transaction on Paypal backend. Issue ----- No delivery address is registered, making the merchant ineligible for seller protection. Cause ----- Commit 00259dc44a981 added the `no_shipping: '1'` value to the form sent to Paypal to prevent buyers from changing their shipping address on Paypal's end. A side-effect is t
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Enable Paypal as payment provider; 2. have a US-based partner; 3. sent them a payment link; 4. pay using Paypal; 5. open transaction on Paypal backend. Issue…
Versions -------- - 16.0+ Steps ----- 1. Enable Paypal as payment provider; 2. have a US-based partner; 3. sent them a payment link; 4. pay using Paypal; 5. open transaction on Paypal backend. Issue ----- No delivery address is registered, making the merchant ineligible for seller protection. Cause ----- Commit 00259dc44a981 added the `no_shipping: '1'` value to the form sent to Paypal to prevent buyers from changing their shipping address on Paypal's end. A side-effect is that it doesn't even register the address provided with the transaction. Solution (16.0 up to saas-17.4) ------------------------------- Use the `address_override: '1'` value instead, which prevents buyers from changing the address while still registering the address on the transaction. In stable, keep the `no_shipping: '1'` value in the rendering values so that user's cannot suddenly change the address again if template hasn't been updated yet. Solution (18.0+) ---------------- Change the `shipping_preference` value from `NO_SHIPPING` to `SET_PROVIDED_ADDRESS`[^1]. opw-4681336 [^1]: https://developer.paypal.com/docs/checkout/standard/customize/shipping-module/#:~:text=Configuring%20shipping%20preferences Forward-Port-Of: odoo/odoo#205751 Forward-Port-Of: odoo/odoo#205686
### Steps to reproduce: - Install "l10n_hu" and switch to Hungarian company - In Settings set NAV credentials to "demo" - Make sure accounts are set on the company & customer - Create an invoice, confirm, Sent & Print - Create a Credit Note for this invoice, Send & Print - On the Credit Note PDF the account of the customer is displayed under the "Supplier" ### Cause: The account always shows under the supplier `if 'out' in o.move_type` so also for credit notes ('out_refund'). ### So
Original PR description
### Steps to reproduce:
- Install "l10n_hu" and switch to Hungarian company
- In Settings set NAV credentials to "demo"
- Make sure accounts are set on the company & customer
- Create an invoice, confirm, Sent & Print
- Create a Credit Note for this invoice, Send & Print
- On the Credit Note PDF the account of the customer is displayed under the "Supplier"
### Cause:
The account always shows under the supplier `if 'out' in o.move_type` so also for credit notes ('out_refund').
### Solution:
Change the condition of the display and add the bank account in a xpath.
opw-4710449
Forward-Port-Of: odoo/odoo#205724Currently ssl certificates are only generated on odoo.com based on db_uuid and enterprise_code. Since we won't be needing enterprise_code anymore we adapt our code to still recover the ssl certificate and be able to recover and log the new 'error' values sent by odoo.com task-4585446 Related PR: https://github.com/odoo/internal/pull/3425 Forward-Port-Of: odoo/odoo#203834 Forward-Port-Of: odoo/odoo#203328
Original PR description
Currently ssl certificates are only generated on odoo.com based on db_uuid and enterprise_code. Since we won't be needing enterprise_code anymore we adapt our code to still recover the ssl certificate and be able to recover and log the new 'error' values sent by odoo.com task-4585446 Related PR: https://github.com/odoo/internal/pull/3425 Forward-Port-Of: odoo/odoo#203834 Forward-Port-Of: odoo/odoo#203328
There is an issue in the line template, where the 'vals' of the line are reassigned to the 'price_vals' when building the 'cac:Price'. This means that any extension done to add values after the price no longer have access to the line vals but only the price ones. This is unwanted, and the template is adapted to avoid reassigning 'vals'. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205827
Original PR description
There is an issue in the line template, where the 'vals' of the line are reassigned to the 'price_vals' when building the 'cac:Price'. This means that any extension done to add values after the price no longer have access to the line vals but only the price ones. This is unwanted, and the template is adapted to avoid reassigning 'vals'. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205827
__Current behavior before commit:__ The Cloudflare Turnstile token expires every 300 seconds (see [Cloudflare doc][1]) which makes the widget reload. There was currently no callback handling this event. If the check had already succeeded, the spinner of the button would have been removed. Thus the second time `turnstileSuccess` would be called, `spinner` would be `null` and it would throw an error when reading `spinner.parentElement`. __Description of the fix:__ Hid the spinner in `
Original PR description
__Current behavior before commit:__ The Cloudflare Turnstile token expires every 300 seconds (see [Cloudflare doc][1]) which makes the widget reload. There was currently no callback handling this…
__Current behavior before commit:__ The Cloudflare Turnstile token expires every 300 seconds (see [Cloudflare doc][1]) which makes the widget reload. There was currently no callback handling this event. If the check had already succeeded, the spinner of the button would have been removed. Thus the second time `turnstileSuccess` would be called, `spinner` would be `null` and it would throw an error when reading `spinner.parentElement`. __Description of the fix:__ Hid the spinner in `turnstileSuccess` instead of removing it. Added an `expired-callback` to show the spinner back on the button. __Steps to reproduce the issue on runbot:__ 1. Enable and configure Cloudflare Turnstile 2. Go to the `/contactus` page 3. Check the box, wait 5 minutes and check the box again [1]: https://developers.cloudflare.com/turnstile/get-started/client-side-rendering/#:~:text=the%20next%20300%20seconds opw-4629962 opw-4681945 opw-4620019 opw-4615863 opw-4640032 Forward-Port-Of: odoo/odoo#202893
Steps to reproduce the bug: - Create a storable product P1: - Tracked by: Lot - Update the quantity of P1 with one unit and Lot 1 - Create a storable product C1 - Tracked by: Serial Number - Update the quantity of C1 with one unit and SN1 - Navigate to Product P1 → Lot/SN → Click on Lot 1 → Repair Orders - Create a repair order: - Add part: Select product C1 with SN1 - Try to save Problem: The lot "Lot 1" is incompatible with the product "C1". Since we access
Original PR description
Steps to reproduce the bug:
- Create a storable product P1:
- Tracked by: Lot
- Update the quantity of P1 with one unit and Lot 1
- Create a storable product C1
- Tracked by: Serial Number
- Update the quantity of C1 with one unit and SN1
- Navigate to Product P1 → Lot/SN → Click on Lot 1 → Repair Orders
- Create a repair order:
- Add part: Select product C1 with SN1
- Try to save
Problem:
The lot "Lot 1" is incompatible with the product "C1".
Since we access the Repair Order view from the Lot/SN view, a default
key is added with "Lot 1". As a result, when trying to create the
"stock.move.line" for C1, this incorrect lot is used.
opw-4576741
opw-4576004
Forward-Port-Of: odoo/odoo#202979Problem: When calling `modify_image` for an attachment linked to a record that hasn't been created yet (`res_id` is `None`), a traceback occurs. This is because `fields` lacks the `res_id` key when we call: request.env[fields['res_model']] .browse(fields['res_id']) .check_access_rights('write') Solution: Use `0` as default `res_id`. This is consistent with what `get_existing_attachment` already does: fields['res_id'] = fields.get('res_id') or 0 Steps to re
Original PR description
Problem:
When calling `modify_image` for an attachment linked to a record that hasn't been created yet (`res_id` is `None`), a traceback occurs. This is because `fields` lacks the `res_id` key when we call:
request.env[fields['res_model']]
.browse(fields['res_id'])
.check_access_rights('write')
Solution:
Use `0` as default `res_id`. This is consistent with what `get_existing_attachment` already does:
fields['res_id'] = fields.get('res_id') or 0
Steps to reproduce:
1. Go to "Email Marketing" > "New".
2. Fill in the "Subject" and choose a mailing list.
3. In the mail body, insert a template containing an image.
4. Click on the image and replace it.
5. Save (only at this step). → Traceback occurs since `modify_image` is called with a `None` res_id.
opw-4715999
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#205838Even though uploaded image was .png it gives such error, reason behind this was `DecompressionBombWarning` occurred in `PIL (Pillow)`  Before this PR: - When uploading an image that is too large, the error message notification was showing wrong message. After this PR: - The error message notification will show the correct message. task-4606136 --- I confirm I have signed the CLA and
Original PR description
Even though uploaded image was .png it gives such error, reason behind this was `DecompressionBombWarning` occurred in `PIL (Pillow)`  Before this PR: - When uploading an image that is too large, the error message notification was showing wrong message. After this PR: - The error message notification will show the correct message. task-4606136 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205864 Forward-Port-Of: odoo/odoo#199564
…simplfied When the partner has no VAT and it is within Europe and it is below the simplified invoice limit, we could indicate the invoice as simplified by default. If it is wrong, the user can still change it. opw-4633564 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#204630
Original PR description
…simplfied When the partner has no VAT and it is within Europe and it is below the simplified invoice limit, we could indicate the invoice as simplified by default. If it is wrong, the user can still change it. opw-4633564 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#204630
The miscellaneous were displayed in the VIES summary report (even if it was rare as it needs to have the field l10n_cz_transaction_code set). A common case would be to create deferred entries with this transaction field set. opw-4688616 Forward-Port-Of: odoo/enterprise#83112
Original PR description
The miscellaneous were displayed in the VIES summary report (even if it was rare as it needs to have the field l10n_cz_transaction_code set). A common case would be to create deferred entries with this transaction field set. opw-4688616 Forward-Port-Of: odoo/enterprise#83112
**Steps to reproduce:** - Install Accounting and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - Go to "Settings / Technical / Database Structure / Decimal Accuracy" - Set 4 digits for "Product Price" - Create a product with a lower price than 0.01 (e.g. 0.0045) - Create an invoice: * Customer: [a Peruvian customer] (e.g. Comercial Constructora los Patitos S.A.) * Product: [the created product] * Quantity: 100 - Confirm the invoice - Process the invoice by the E-i
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - Go to "Settings / Technical / Database Structure / Decimal Accuracy" - Set 4 digits for…
**Steps to reproduce:** - Install Accounting and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - Go to "Settings / Technical / Database Structure / Decimal Accuracy" - Set 4 digits for "Product Price" - Create a product with a lower price than 0.01 (e.g. 0.0045) - Create an invoice: * Customer: [a Peruvian customer] (e.g. Comercial Constructora los Patitos S.A.) * Product: [the created product] * Quantity: 100 - Confirm the invoice - Process the invoice by the E-invoicing service **Issue:** An error is triggered because "PriceTypeCode" is set to "02", which is the code used to declare that it is free. But in this case, it is not free. **Cause:** "PriceTypeCode" is computed by using "is_zero" method of the currency on the unit price. As the decimal accuracy of the currency is set to 2 and the unit price is 0.0045, "is_zero" is returning True. **Solution:** Compute "PriceTypeCode" from the line subtotal instead of the unit price. This is not perfect as it can also be lower than 0.01, but it's less probable. opw-4608671 Forward-Port-Of: odoo/enterprise#83369 Forward-Port-Of: odoo/enterprise#82019
At the moment, if a cancellation has been requested, the 'Update SAT' button isn't always visible on the invoice. Analysis: The condition for the 'Update SAT' button being visible is that at least one of the EDI documents falls under one of the domains in `_get_update_sat_status_domains`. In particular, the 'Update SAT' status is visible if there is an EDI document with the 'invoice_sent' status and whose SAT status is not 'cancelled' or 'skip'. If the user requests the cancellation of th
Original PR description
At the moment, if a cancellation has been requested, the 'Update SAT' button isn't always visible on the invoice. Analysis: The condition for the 'Update SAT' button being visible is that at least…
At the moment, if a cancellation has been requested, the 'Update SAT' button isn't always visible on the invoice. Analysis: The condition for the 'Update SAT' button being visible is that at least one of the EDI documents falls under one of the domains in `_get_update_sat_status_domains`. In particular, the 'Update SAT' status is visible if there is an EDI document with the 'invoice_sent' status and whose SAT status is not 'cancelled' or 'skip'. If the user requests the cancellation of the CFDI before the SAT status is fetched for the first EDI document (which represents the sending of the invoice), its SAT status will be set to 'skip'. As a result, the 'Update SAT' button will no longer be visible, meaning that the user can not update the invoice's state from fetching the SAT status.  Fix: The Update SAT button should also be visible if there is a document in 'invoice_cancel_requested' whose SAT state is valid. opw-4375788 Forward-Port-Of: odoo/enterprise#83289