Daily updates from Odoo
Monday, September 1, 2025
30 changes · saas-18.3
Resolved issues and error corrections
This fixes an issue where selecting an afternoon time in a 12-hour clock format could save it as a morning time instead. Users working with AM/PM date and time fields can now rely on the selected time being recorded accurately.
Original PR description
Be in (or configure) a language with the 12 hour time format (i.e. such that times are displayed with am/pm). In a datetime field, open the datepicker and set the time in the afternoon (e.g. 6pm). Before this commit, the value that was actually set in the input was in the morning (6am in this case). The cause of the issue came from the date parsing. As we do not display the seconds in the input, the value was "06:00 pm", which couldn't be parsed properly. This commit fixes the issue by adding a step in parseDateTime, to try to parse with the short time format. opw~4996133 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
The POS now correctly calculates additional down payments on the same sales order by subtracting amounts already paid. This prevents customers from being charged the full down payment percentage again and keeps payment requests accurate.
Original PR description
- Create a SO of 450 with 15% tax for a total of 517.50 - Create a first down payment from the POS of 10% => you pay 51.75 - Create a second down payment from the POS of 10% => we ask you to pay 51.75 again => We should ask him to pay 10% of 517.50 - 51.75 instead --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The update adds a clear log entry when a user retries India EDI, e-waybill, or e-waybill IRN processing. This helps businesses identify who retried a government tax request, which is important because too many requests can temporarily block access for 24 hours.
Original PR description
Manual fw-port of https://github.com/odoo/odoo/pull/223957, https://github.com/odoo/odoo/pull/223886, https://github.com/odoo/odoo/pull/207184 *=edi,ewaybill,ewaybill_irn Following the implementation of [Black list request by GST](odoo/iap-apps#1039) the users are blocked for 24 hours on generating too many request. When processing through EDI there is no log when clicked on the retry button, Which is more essentially needed now to know by which user the EDI was retried and we logged the same on the move --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224169
Hungarian electronic invoicing now classifies credit notes more accurately when invoices have already received payments. This helps ensure reports sent to NAV use the correct cancellation or modification status, reducing compliance errors.
Original PR description
Before this PR: - Previously, a credit note was marked as STORNO if the base invoice's residual amount was zero, regardless of whether any payments had been made. This led to incorrect STORNO reports being sent to NAV in cases where the invoice had been partially or fully paid before reversal. After this PR: - If any payment was made, the credit note is marked as MODIFY instead of STORNO. Example: - Case 1: No payments before reversal Invoice: 1000 Credit Note 1: -100 Credit Note 2: -900 => Credit Note 1 should be sent as a Modification, Credit Note 2 as STORNO. - Case 2: Payments before reversal Invoice: 1000 Payment: -100 Credit Note: -900 => The Credit Note should be sent as a Modification. task-4818762 Forward-Port-Of: odoo/odoo#224861 Forward-Port-Of: odoo/odoo#211831
This fix avoids checking empty PDF documents for encryption in the sales PDF quote builder. It prevents unnecessary errors when empty documents are encountered, helping sales quote setup and data loading complete reliably.
Original PR description
If the document is empty we don't need to check for encryption. Otherwise we risk getting an error. ``` Traceback (most recent call last): File "/home/odoo/src/odoo/18.0/odoo/tools/convert.py", line…
If the document is empty we don't need to check for encryption. Otherwise we risk getting an error.
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/18.0/odoo/tools/convert.py", line 544, in _tag_root
f(rec)
File "/home/odoo/src/odoo/18.0/odoo/tools/convert.py", line 444, in _tag_record
record = model._load_records([data], self.mode == 'update')
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5500, in _load_records
data['record']._load_records_write(data['values'])
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5418, in _load_records_write
self.write(values)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4827, in write
real_recs._validate_fields(vals, inverse_fields)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 1631, in _validate_fields
check(self)
File "/home/odoo/src/odoo/18.0/addons/sale_pdf_quote_builder/models/product_document.py", line 46, in _check_attached_on_and_datas_compatibility
utils._ensure_document_not_encrypted(base64.b64decode(doc.datas))
File "/home/odoo/src/odoo/18.0/addons/sale_pdf_quote_builder/utils.py", line 12, in _ensure_document_not_encrypted
if pdf.PdfFileReader(io.BytesIO(document), strict=False).isEncrypted:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/tools/pdf/__init__.py", line 91, in __init__
super().__init__(stream, strict)
File "/home/odoo/.local/lib/python3.12/site-packages/PyPDF2/_reader.py", line 317, in __init__
self.read(stream)
File "/home/odoo/.local/lib/python3.12/site-packages/PyPDF2/_reader.py", line 1408, in read
self._basic_validation(stream)
File "/home/odoo/.local/lib/python3.12/site-packages/PyPDF2/_reader.py", line 1449, in _basic_validation
raise EmptyFileError("Cannot read an empty file")
PyPDF2.errors.EmptyFileError: Cannot read an empty file
```
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#224674Point of Sale now calculates combo child item prices using the currency's rounding precision instead of product price precision. This prevents small rounding discrepancies, ensuring POS order totals match expected sale totals such as 31.00 instead of 31.01.
Original PR description
Currently, when you have a difference in precision between currency and product price, there can be a discrepency in the computation of the line prices, leading to a difference in the price total…
Currently, when you have a difference in precision between currency and product price, there can be a discrepency in the computation of the line prices, leading to a difference in the price total between the sale and pos app. Steps to reproduce: ------------------- * Modify the product precision to have 4 digits * Modify the burger menu combo product * Sale price 26.5 * Burger choice: Cheese burger, remove taxes, change price to 10 * Drinks choice: Coca cola, remove taxes, change price to 10, extra price set to 4.5 * Add another combo choice with 1 product only, no tax, price 10 * Open pos session * Add the combo, select the product that were modified > Total is 31.01 when it should be 31.00 Why the fix: ------------ Point of sale was using the decimal precision set on the product price to compute the price unit of the child lines. We can notice that the sale app was using the currency precision. We will use the same approach as sales. The decision was driven by the fact that 1) both scenarios could make sense, 2) total should be as set, 3) child line prices are not as important as the total and don't have a big influence. opw-4769227 Forward-Port-Of: odoo/odoo#220352
This fixes an issue where applying a gift card in Point of Sale could create an extra gift card line with a zero amount. Orders now avoid confusing duplicate discount lines, making checkout totals clearer for cashiers and customers.
Original PR description
When selling some product and applying a giftcard, there could be 2 giftcard lines applied on the order one with a correct amount and the other one with 0 as amount. Steps to reproduce: ------------------- * Create a gift card with 50€ * Open PoS and add a Desk Pad and a Black Drawer > Observation: There are 2 giftcard lines applied on the order Why the fix: ------------ Sometimes the discountable amount could get weird values that are really close to 0 but that was not interpreted as False. To fix this we use `floatIsZero()` instead. Note: ---------- I will introduce a hoot test in 18.3 to cover this weird use case. opw-4866358 Forward-Port-Of: odoo/odoo#224777 Forward-Port-Of: odoo/odoo#223948
This fixes an internal automated test so its expected results no longer vary depending on cached routing data. It helps keep quality checks reliable and reduces false alarms during development, with no direct change for end users.
Original PR description
runbot-231489
Fixed an issue where the calendar's 'show more' link could not be clicked on non-working days with many events. Users can now open the full event list instead of accidentally triggering the event creation popup.
Original PR description
**PROBLEM** If you add a lot of daily event on a off-day, the "show more" link to show all events is not clickable. Clicking bring the event creation popover. **REPRO STEPS** 1. install calendar and hr. 2. on a off day (grey background) in the week or day view, add events until the "show more" link shows up. 3. click on it, and notice the event creation popover pops up instead of the event list popover. **CAUSE** FullCalendar css class fc-non-business have a zindex of 1, a div with this class is "above" the link. **FIX** Removing a line that removed the css class fc-daygrid-more-link to the "more-link" element. Modifying css to keep the style consistent even with this new class. opw-4844719 Forward-Port-Of: odoo/odoo#221007
Saving a form can now correctly guide users to the intended follow-up action when a validation warning includes a redirect and extra context. This helps users resolve save-blocking issues through the right screen instead of being left with a broken or incomplete error flow.
Original PR description
Have a web_save that raises a RedirectWarning which has the ID of an action and an additional context in its parameters. Trigger the warning in the form view by clicking on the save button in the form view. Before this commit, this feature did not work like at all. - The additional context was not taken into account - the path taken by clicking on the form's save button was not able to handle interacting with the main form view - The error dialog did not handle going into an action in target other than new After this commit, all this is fixed and the whole flow, that allow an error to be enriched such that the user could do the correct action to correct the error now works. opw-4742952 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#224536 Forward-Port-Of: odoo/odoo#223198
This fix ensures returned dropshipped products sent to an internal subcontracting location are recorded with the correct accounting direction. It prevents inventory value from being reduced incorrectly, improving financial accuracy for companies using subcontracting and automated stock valuation.
Original PR description
…ml internal dropship return **Problem:** when the subcontracting setting is active, the return of a dropshipped product (not necessarily subcontracted) to the internal subcontracting location will…
…ml internal dropship return **Problem:** when the subcontracting setting is active, the return of a dropshipped product (not necessarily subcontracted) to the internal subcontracting location will create an account move that credits "stock valuation" instead of debitting it **Steps to reproduce:** - enable the "Anglo-Saxon Accounting","Multi-steps routes" and "Subcontracting" settings - create a storable product with dropshipping route and a vendor - in 'general information' write a non null cost - make sure the product category's inventory valuation' is 'automated' - create a new quotation for this product, confirm it and confirm the linked purchase order - click on the dropship smart button and validate the picking - click on return and select 'Physical Locations/Subcontracting Location' as the return location - validate and click on the valuation smart button - on the only stock valuation layer for this move, click on the book shaped widget **Current behavior:** the account move credits Stock Valuation and debits stock interim (received) **Expected behavior:** As we are returning the product to stock it should increase the value of the stock valuation account. Therefore, it should debit stock valuation and credit stock interim (received) **Cause of the issue:** If the mrp_subcontracting_dropshipping module is active, and if we call _is_dropshipped_return on a stock move which is the return (to the subcontracting location) of a dropshipped move : the method will return true. https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/mrp_subcontracting_dropshipping/models/stock_move.py#L29-L35 Therefore, inside _account_entry_move, _is_in will be false (contrary to if mrp_subcontracting_dropshipping is not installed or if the destination is another internal location) https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/stock_account/models/stock_move.py#L580 The aml vals will be computed inside _prepare_anglosaxon_account_move_vals https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/stock_account/models/stock_move.py#L596 Here the fact the destination location is internal does not change the fact that it should debit the stock valuation account (meaning it should used acc_valuation as the second parameter of _prepare_account_move_vals) if the cost is positive. https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/stock_account/models/stock_move.py#L610-L614 opw-4894755 Forward-Port-Of: odoo/odoo#221771 Forward-Port-Of: odoo/odoo#221009
Purchase order lines now consistently display both the vendor-specific product name and the internal product name across all pages. This helps buyers avoid confusion when reviewing multi-page purchase orders with vendor product naming.
Original PR description
#### Issue: Only the vendor name of a product is displayed on a purchase order on all pages except the first one. #### Step to reproduce: - make sure "Variant grid entries" is disabled in the…
#### Issue: Only the vendor name of a product is displayed on a purchase order on all pages except the first one. #### Step to reproduce: - make sure "Variant grid entries" is disabled in the settings. If you can't disable it, you can disable the view `purchase.order.form.inherit.matrix` to trigger the bug. - Create a product - Go to the purchase sheet - Add a vendor - Add the field "Vendor Product Name" and "Vendor Product Code" and fill them - Create a purchase order - Add your product - Add your product a second time (on a second line) - Confirm the PO - Activate debug mode - Go to the view and add a limit to have only 1 POL per page - Return to your PO - Go to the second page #### Current behavior: - Only the vendor name is displayed #### Expected behavior: - The vendor name should appear at the top, while the db name should be displayed under as in the first page. #### Cause of the issue: On the first page, POLs data are fetch through a `web_read` on the PO, while on other pages data are fetch through `web_read` on the POLs of the page. While fetching POL data with a `web_read` the client ask for several informations including: `name` and `product_id.display_name`. If both return the same, the client show only one, else it shows the `display_name` on top and the `name` below. - `name` return the vendor name - `product_id` is fetch with the context `partner_id` which transform the `display_name` from the db_name to the Vendor name Therefore it fetches twice the vendor name and don't have the name from the db. #### Solution: - remove the `partner_id` from the context. #### Consequence: - When adding a product to the PO, the name of the product displayed in the dropdown list will be the name from the db instead of the name of the vendor. PO confirmed that consequence is OK as long as it's still possible to search for product using vendor code, which is still possible. opw-4737337 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223250
The Saudi localization now hides the “THIS IS NOT A LEGAL DOCUMENT” warning on vendor bills, vendor credit/debit notes, purchase receipts, and sales receipts. This keeps the warning limited to customer documents that need it when a QR code is missing, reducing confusion for accounting users.
Original PR description
Before this commit: - The message "THIS IS NOT A LEGAL DOCUMENT" was also displayed on Vendor Debit Notes, Vendor Credit Notes, Purchase Receipt and Sales Receipt. - The warning should only appear on Customer Invoices, Credit Notes, and Debit Notes when the QR code is missing After this commit: - The warning message is no longer displayed on all Vendor Debit Notes, Vendor Credit Notes, Purchase Receipt and Sales Receipt. Task-5044870 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224473
Kit products now follow quantity-on-hand filters based on their actual computed availability from component stock. This prevents kits from appearing in product lists when they do not truly match the selected stock range, improving inventory search accuracy.
Original PR description
#### Issue: - When filtering products on "Quantity on hand", kits may appear when they shouldn't #### Step to reproduce: - with MRP - create a new product - create a BoM for this product as kit - make sure you have product of the BoM on hand - go to product - add filters: - "Quantity on hand" > 1 - "Quantity on hand" < *less_than_you_have* #### Current behavior: - kit appears #### Expected behavior: - kit doesn't show #### Cause: - kit were filtered has having both 0 quantity (as unstored product) and their quantity (computed from stock of BoM products). Therefore they were compliant with both filter. #### Solution: - remove kits from products compliant with the filter if they don't comply with the filter with their computed quantity opw-4967763 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224681 Forward-Port-Of: odoo/odoo#221224
This fix ensures the Point of Sale loyalty setup always has the pricing information it needs during testing and operation. It prevents loyalty points from being calculated or shown incorrectly when a price list setting was missing.
Original PR description
Task: [#4974071](https://www.odoo.com/odoo/my-tasks/4974071)
Runbot build error: [#182003](https://runbot.odoo.com/odoo/runbot.build.error/182003)
## Error
FAILED: [9/16] Tour PosLoyaltyTour6 → Step .loyalty-points-won:contains("26.5"). Element (.loyalty-points-won:contains("26.5")) has not been found.
## Qualifiers
{
"module": "pos_loyalty",
"test_path": "/pos_loyalty/tests/test_frontend.py", "tour_name": "PosLoyaltyTour6",
"tour_step": ".loyalty-points-won:contains("26.5")", "test_class": "TestUi",
"test_method": "test_point_per_money_spent",
"test_module": "pos_loyalty"
}
## Fix
In some cases, the POS config's pricelist_id was not available in the frontend, causing some issues. By explicitly setting use_pricelist to True on the POS config, we ensure that config.pricelist_id is properly loaded.Point of Sale now correctly reflects changes to extra prices for product options that do not create separate variants. This prevents outdated prices from appearing during sales and helps ensure customers are charged the intended amount.
Original PR description
Before this commit, when changing the extra price of a ptav with the no variant creation mode, the updated price was not loaded. After this commit, the updated extra price is correctly loaded. opw-5015868 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224091
The leave statistics view has been adjusted to prevent information from visually overlapping. This makes time off data easier for employees and managers to read in the calendar and leave reporting areas.
Original PR description
This commit addresses an overlapping styling issue in the leave stats task-4945729 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes self-order checkout so every selected product option is saved on the order line, matching the regular Point of Sale behavior. It helps ensure orders with configurable products are recorded accurately and can be processed consistently.
Original PR description
Before this commit, the ptav of attributes configured to create variants was not saved in the order lines. This was inconsistent with the behavior in Point of Sale, where all ptav values are saved in the order lines. opw-5020130 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224080
Razorpay payments now check whether the payment access token has expired before processing. If needed, the system automatically generates a new token, helping prevent payment failures for customers using Razorpay.
Original PR description
Version: - saas-18.2 Issue: - The refresh token method was removed in PR https://github.com/odoo/odoo/pull/188774. Because of this, the Razorpay access token expiry was no longer being checked. Fix: - When a user makes a payment, the system now checks if the Razorpay access token has expired. If it has, a new token will be generated automatically. opw-4953953 Forward-Port-Of: odoo/odoo#224233
This fix prevents accounting demo data loading from failing when a currency value is unexpectedly empty. It uses the company currency as a safe fallback, making setup and testing environments more reliable.
Original PR description
While loading demo data, there is a possibility of error from this line [1]. According to [2], the currency may come as a null recordset. And if then it causes the error [3]. [1]…
While loading demo data, there is a possibility of error from this line [1]. According to [2], the currency may come as a null recordset. And if then it causes the error [3].
[1]
https://github.com/odoo/odoo/blob/f33451af032453746ccd662580f2cf26b85031d6/addons/account/models/account_move.py#L1183
[2]
https://github.com/odoo/odoo/blob/f33451af032453746ccd662580f2cf26b85031d6/addons/account/models/account_move.py#L1174
[3] - **Traceback:-**
```ValueError: not enough values to unpack (expected 1, got 0)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/models.py", line 5623, in ensure_one
_id, = self._ids
ValueError: Expected singleton: res.currency()
File "/home/odoo/src/odoo/saas-18.3/odoo/http.py", line 2467, in __call__
response = request._serve_db()
File "/home/odoo/src/odoo/saas-18.3/odoo/http.py", line 1970, in _serve_db
return self._transactioning(
File "/home/odoo/src/odoo/saas-18.3/odoo/http.py", line 2034, in _transactioning
return service_model.retrying(func, env=self.env)
File "/home/odoo/src/odoo/saas-18.3/odoo/service/model.py", line 166, in retrying
env.cr.flush() # submit the changes to the database
File "/home/odoo/src/odoo/saas-18.3/odoo/sql_db.py", line 179, in flush
self.transaction.flush()
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/environments.py", line 545, in flush
self.default_env.flush_all()
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/environments.py", line 366, in flush_all
self._recompute_all()
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/environments.py", line 362, in _recompute_all
self[field.model_name]._recompute_field(field)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/models.py", line 6746, in _recompute_field
field.recompute(records)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields.py", line 1639, in recompute
apply_except_missing(self.compute_value, recs)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields.py", line 1612, in apply_except_missing
func(records)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields.py", line 1661, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/saas-18.3/addons/mail/models/mail_thread.py", line 467, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/models.py", line 4623, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields.py", line 73, in determine
return needle(*args)
File "/home/odoo/src/odoo/saas-18.3/addons/account/models/account_move.py", line 1182, in _compute_payment_state
if invoice.state == 'posted' or (invoice.state == 'draft' and not currency.is_zero(invoice.amount_total)):
File "/home/odoo/src/odoo/saas-18.3/odoo/addons/base/models/res_currency.py", line 261, in is_zero
self.ensure_one()
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/models.py", line 5626, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
**Solution:-**
- This commit adds a fallback to `self.env.company.currency_id` to ensure a valid currency is always available.
**Sentry - 6427055389**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix prevents an error that could occur in Discuss calls when someone leaves or crashes just as another participant joins. It makes calls more reliable by safely handling timing conflicts during connection events.
Original PR description
Before this commit, since https://github.com/odoo/odoo/pull/200981, a race condition could occur where the call is over when the the rtc session matching a track event is obtained. This could occur if you crash or leave at the moment another user arrives. You could get a track event from the SFU, wait for the rtc session record from Odoo, leave te call, finally get the rtc session from odoo. This would lead to a traceback as this handler expected that the call was still ongoing. Forward-Port-Of: odoo/odoo#224658 Forward-Port-Of: odoo/odoo#224588
The Chilean electronic invoicing demo setup now includes the required certificate serial number. This prevents errors when users test sending invoices to the Chilean tax authority in demo environments, without affecting real production certificates.
Original PR description
**Issue** When installing l10n_cl_ed, the `subject_serial_number` field is left empty. This causes an error when attempting to send an invoice to the SII. **Steps to Reproduce** 1. Install Accounting and l10n_cl_edi 2. Create and confirm an invoice 3. Click "Send Now to SII" 4. Error: Invalid Operation **Root Cause** The `subject_serial_number` is not set during installation, and this field is required for electronic document generation. **Fix** Restore the behavior from version 17.0 by setting a default `subject_serial_number` if it's missing and the certificate is available. This ensures the demo data is functional and allows users to test the SII integration out-of-the-box. Opw-4961801 Forward-Port-Of: odoo/enterprise#90636
Tax return warning checks now refresh when a user opens them, so resolved issues such as draft entries no longer appear incorrectly. This helps users see the current status of a return without slowing down the broader Tax Returns overview.
Original PR description
Before, when opening a Return that had bypassed checks such as Draft Entries, and we had deleted or confirmed those entries it wouldn't have refreshed the check number and would still display that there are draft entries. Now, we are forcing the check to be refreshed when someone wants to see them as to not crash the performances when someone opens the Tax Returns Kanban view. task-4850581
Odoo Studio now correctly keeps the “Extra rights / Technical Features” group visible when editing field visibility rules. This prevents fields from unexpectedly disappearing for users working outside debug mode and makes Studio customization more predictable.
Original PR description
Steps to reproduce ================== - In debug mode - Go to Contacts - Open any record - Open studio - Click on any field - Add the "Extra rights / Technical Features" group to "Allow visibility to…
Steps to reproduce ================== - In debug mode - Go to Contacts - Open any record - Open studio - Click on any field - Add the "Extra rights / Technical Features" group to "Allow visibility to groups" => The group is not displayed as a tag - Restore the view - Now without debug mode (?debug=0), repeat the same steps => The field disappears, we need to toggle "Show Invisible Elements" to see it again Cause of the issue ================== https://github.com/odoo/odoo/pull/179354/commits/15aeaf88c268f047b8b83a5aa66f5da246c2b675 When calling get_views, the "base.group_no_one" is removed from the groups attribute and "invisible" is set to true if we are in debug mode. Solution ======== Adding "base.group_no_one" is still the way to have the expected behavior for now. We override some ir.ui.view functions when in studio to be able to edit it. According to the docstring of _postprocess_debug_to_cache, this feature is temporary. Another solution will be needed in the future. opw-4969262 Forward-Port-Of: odoo/enterprise#91647
Credit note validation for Kenyan OSCU e-invoicing now only considers credit notes that are actually reconciled with the original invoice. This prevents cancelled or draft credit notes from incorrectly blocking valid new credit notes due to overstated quantity or value totals.
Original PR description
[FIX] l10_ke_edi_edi_oscu: ensure quantity and monetary values checks are performed on reconciled reversals only. Fixes a behavior where the checks performed on the credit notes related to their quantities and monetary values include non reconciled credit notes. Steps to reproduce: 1 - activate `l10n_ke` on some company. 2 - Create an invoice. 3 - Create a partial or full credit note ( this one will be reconciled with the invoice automatically ) 4 - cancel the credit note or reset it to draft. 5 - create another credit note where the quantities and/or monetary values exceed that of the invoice if summed up with the cancelled credit note. Following the steps will result in an error message saying that the monetary value or quantities on the credit notes exceed that of the invoice. The correct behavior is to simply not count any credit note that isn't explicitly reconciled with the invoice. opw-4779976 Forward-Port-Of: odoo/enterprise#92319
Italian POS receipts now exclude negative change payments before sending payment details to the fiscal printer. This prevents the printer from rejecting affected orders, helping ensure sales are properly processed and reported to authorities.
Original PR description
Before this commit, specifying the payment method used to give back the change in a POS order would lead to the fiscal printer receiving a negative payment as input, which is not supported, thus leading to the order not being treated by the fiscal printer (so not reported to the government). Only the payments with is_change=true where filtered out. I am now adding a filter to only keep the positive payments in the receipt, as the fiscal printer is computing the change itself. opw-4931671 Forward-Port-Of: odoo/enterprise#91794
This fix ensures sales orders in the Mexican localization show the correct invoiced quantity after an invoice cancellation is completed through CFDI. It prevents sales order quantities from incorrectly dropping to zero when the original invoice has been cancelled and replaced, improving billing accuracy and follow-up.
Original PR description
How to reproduce the issue: In l10n_mx: 1. Create a sale order. 2. Create an invoice from the SO, with yesterday’s date, and send it to the CFDI. 3. Lock the period at yesterday’s date. 4. Request the invoice cancellation with the “01” method. This creates a new invoice — confirm it. 5. Create a credit note for the original invoice. 6. Retry sending the cancel request to the CFDI; the CFDI state is now cancelled for the original invoice. On the original SO, the quantity invoiced is 0 despite the CFDI state of the original invoice being cancelled. This commit forces a recompute of the quantity invoiced when the CFDI state changes. Since _compute_qty_invoiced uses _get_invoice_lines, which filters out invoices in sent state, only lines from invoices in cancelled state will be taken into account. opw-4910139 Forward-Port-Of: odoo/enterprise#93480 Forward-Port-Of: odoo/enterprise#91924
Gantt popover cards now show standard labels such as Name, Start, and Stop in the user's selected language. This fixes an issue where custom Studio menus using Gantt views displayed these labels in English even for non-English users.
Original PR description
Steps to Reproduce: - Change the language to something other than English. - Create a new menu in the Appointment module using Studio. - Link that menu with the existing model (Resource Time of…
Steps to Reproduce: - Change the language to something other than English. - Create a new menu in the Appointment module using Studio. - Link that menu with the existing model (Resource Time of Detail). - Save the changes and add the Gantt view - Save the changes and close Studio. - View this new menu in the Gantt view Issue: - When clicking onto the kanban popover card for any record, the labels will remain as "Name" , "Start" , and "Stop" in English, and it will not translate. Reason: - [1] changed the rendering of default kanban card templates from XML to JS. This changed the default template to be static. Fix: - Add a call to the translation core tool "_t" on the three labels upon their generation in _getKanbanViewParams(). This ensures that the arch template that is generated is translated correctly into the user's set language. [1] : b2e31239041e6b7850888a3ae070c3f8a40ea5ee [opw-4861899](https://www.odoo.com/odoo/my-tasks/4861899) Forward-Port-Of: odoo/enterprise#90605
The French VAT report preparation now handles missing setup information more safely, avoiding crashes in certain payroll accounting configurations. This improves reliability when the system calculates VAT amounts before all required report dates or report details are available.
Original PR description
steps to reproduce the issue : 1- install l10n_fr_hr_payroll_account without demo data 2- and run this test .test_computed_fields_without_dependencies Added a dependencies using…
steps to reproduce the issue :
1- install l10n_fr_hr_payroll_account without demo data
2- and run this test .test_computed_fields_without_dependencies
Added a dependencies using @api.depends('report_id', 'date_from', 'date_to') on the _compute_vat_amount method to ensure automatic re-evaluation when any of these fields change.
In test_computed_fields_without_dependencies, the record is created using model.new(), which means required fields like report_id, date_from, and date_to may not be set yet. This caused a crash due to ensure_one() on an empty report_id.
Even though these fields are required, they are not automatically filled when using model.new() (unlike saved records).
Also introduced early exits by setting default values (vat_amount = 0.0, is_vat_due = False) and skipping computation when any of the required fields (report_id, date_from, date_to) or result VAT lines are missing because of ensure_one() in options.
These safeguards prevent errors in the test
build_error-115299
Forward-Port-Of: odoo/enterprise#87608This fix updates French VAT reporting so reimbursement entries use the proper account. It helps ensure VAT reimbursement accounting is posted correctly and reduces the risk of manual corrections.
Original PR description
This commit will change the account used for the reimbursement move. task-4932427 Forward-Port-Of: odoo/enterprise#91212