Daily updates from Odoo
Monday, July 13, 2026
46 changes · saas-19.3
New functionality added to Odoo
Odoo now supports the Latvian VAT report with four detailed annexes covering domestic, EU, purchase, sales, import, and export transactions. Businesses can also export the complete report, including annex details, as XML for easier statutory filing and compliance.
Original PR description
This commit adds 4 attachments to the Latvian tax report and an XML export for the tax report (including the attachments). The attachments are the following - PVN 1-I: domestic purchase / import -…
This commit adds 4 attachments to the Latvian tax report
and an XML export for the tax report (including the attachments).
The attachments are the following
- PVN 1-I: domestic purchase / import
- PVN 1-II: EU purchase
- PVN 1-III: domestic sales / export
- PVN 2: EU sale
The attachments give more details for the tax report.
The lines of the attachments are "transactions"
A "transaction" is identified by the move and the transaction type or document type.
The transaction type is given via a tax tag (see community PR).
- PVN 1-I: transaction type, move
- Small transactions (< 150€) are aggregated separately under transaction types 'V' or 'T'
independently of the move
- 'V': All small transactions of a partner in case the total of all their small transactions reaches 150€
- There is max 1 line per partner
- 'T': All small transactions that are not grouped under some 'V' line
- There is max 1 line like this; it has no partner information
- PVN 1-II: transaction type, move
- Small transactions (< 150€) are aggregated separately under transaction types 'V' or 'T'
(like PVN 1-I)
- PVN 1-III: document type, move and line in the main tax report
- All transactions with (document) type 'X' are aggregated on a single line
- Small transactions (< 150€) are aggregated separately under document types 'V' or 'T'
(like PVN 1-I)
- The line in the main tax report is ignored for 'X' and small transactions
- PVN 2: transaction type, move
- No aggregation is performed here
Only account move lines that are tagged with a transaction type (1-I, 1-II, 2)
or a relevant tag for the main report (1-III) are shown in the reports.
The tags `Rep` and `C (car)` only take 40% and 50% respectively of the
base amounts. The tax amount is assumed to be split correctly.
task-4251184
Forward-Port-Of: odoo/enterprise#84135This update introduces two new tax types for Latvian businesses – 'car tax' and 'representation tax' – impacting VAT deductions. The changes include tagging tax reports and adjusting financial calculations based on these new tax types, ensuring accurate reporting and compliance.
Original PR description
#### [IMP] l10n_lv: add tax report attachment tags Add tags for the tax report attachments added in the related enterprise PR and tag all existing taxes. They determine the transaction type. It also adds the special tag `Rep` that is irrelevant for the transaction type. From a base amount line tagged with `Rep` we only put 40% of the amount for the attachments. #### [IMP] l10n_lv: add a car and a representation purchase tax This commit adds 2 new taxes - "car tax": 50% of the VAT is deductible - "representation tax": 40% of the VAT is deductible #### references task-4251184 Forward-Port-Of: odoo/odoo#212698
Enhancements to existing features
Odoo can now use official exchange rates from the Central Bank of Azerbaijan for automatic currency updates. This helps companies working in Azerbaijan convert multi-currency accounting and tax transactions into AZN using the correct daily official rate, including rates quoted for larger nominal amounts.
Original PR description
This commit adds the Central Bank of Azerbaijan (CBA) as a supported service provider for automatic currency rate updates. Purpose: To ensure multi-currency accounting entries and taxable transactions are accurately translated into the national currency (AZN) using the official exchange rate defined by the CBA for the transaction day. Functionality: -Enables fetching official daily exchange rates directly from CBA via XML. -Automatically handles rates defined for different nominal quantities (e.g., rates quoted per 100 units instead of 1 unit). Backport of: https://github.com/odoo/enterprise/pull/122626 task-6112867 Forward-Port-Of: odoo/enterprise#123436
The website AI Assistant is now unavailable to users who do not have permission to edit and design website pages. This avoids confusion by disabling the button and showing a clear explanation when the feature cannot be used.
Original PR description
Restricted Editors do not have permission to edit website pages. However, the AI Assistant button remains available, giving the impression that the feature can be used even though any changes cannot be saved. This commit disables the AI Assistant button for users without 'Editor and Designer' access and adds a tooltip explaining why the feature is unavailable
The AI module now moves away from an embedding model that will soon be discontinued. It also automatically refreshes older AI-generated embeddings that used deprecated models, helping keep AI features reliable without manual intervention.
Original PR description
The model gemini-embedding-001 will be deprecated soon, so this commit is: - Deprecating that model. - Introducing an autovacuum to recompute embeddings that were done using embedding models that have been deprecated. task-6004597
Resolved issues and error corrections
This fix ensures Colombian postal codes with fewer digits are formatted correctly before being sent to the Envia delivery service. It helps prevent delivery failures for affected Colombian cities such as Santa Fe de Antioquia.
Original PR description
Issue ----- Delivery does not always work from/to some cities in Colombia, like Antioquia. Cause ----- There was an oversight in fix 7654c55 where only 5 digit postal codes taken from the colombian…
Issue ----- Delivery does not always work from/to some cities in Colombia, like Antioquia. Cause ----- There was an oversight in fix 7654c55 where only 5 digit postal codes taken from the colombian localisation were padded in https://github.com/odoo/enterprise/blob/390acf532e8932fd9b9a708382a5e36cdbb35754/delivery_envia/models/envia_request.py#L726-L727 However, some of the colombian cities listed in `l10n_co_edi/data/res.city.csv` have 4 digit codes (like `SANTA FÉ DE ANTIOQUIA`, code `5042`). https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/l10n_co_edi/data/res.city.csv#L12 These 4 digit codes have to be right-padded to 5 characters before the left-padding to match the official colombian zip codes. See colombian gov official document (PDF download) where the code is actually `05042`. https://www.dane.gov.co/files/censo2005/provincias/subregiones.pdf ----- Ticket: opw-6248252 Forward-Port-Of: odoo/enterprise#123344 Forward-Port-Of: odoo/enterprise#120164
Fixed an issue where Chilean export invoice PDFs could show customs information under the wrong column when origin or destination port details were missing. The printed export document now keeps blank cells in place so package quantities and port information remain correctly aligned.
Original PR description
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by…
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by QWeb, causing the remaining columns to shift left This results in `Qty of Packages` appearing under `Origin Port` or `Destination Port` in the printed document ### Cause: `l10n_cl_port_origin_id` and `l10n_cl_port_destination_id` have no default value and are optional fields `t-out` on a falsy value omits the `td` entirely in QWeb, breaking the column alignment Adding `or ''` ensures an empty `td` is always rendered, preserving the table structure regardless of whether the fields are set ### Steps to reproduce: - Install `l10n_cl_edi_exports` and switch to CL Company - Create an Invoice (any customer, any line) - In the gear menu, select Print > Invoice PDF copy (Chile) Before the fix, `Qty of Packages` appears under `Origin Port` when neither port field is set opw-6304670 Forward-Port-Of: odoo/enterprise#122906 Forward-Port-Of: odoo/enterprise#121923
This fix ensures Belgian CODA bank statement files are read correctly after a prior change added an extra returned value. It prevents import failures or incorrect statement data handling, helping accounting teams continue processing bank statements reliably.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/54ff6637af96533e7f035eeff84f79336dc4650b we made a fix because thanks to this commit:https://github.com/odoo/enterprise/commit/c66995fda83e19b28a38312af8efdc1601881cf0 where we did a backport of the extension number. The backport adds the extension number to the return of the _parse_bank_statement_file. With that we have 4 args returned. Without the * we would have the "too many value to unpack" error. But when doing that we miss to change the stmt_vals = data to take the last element. Otherwise, we will have a list of two elements. no task id Forward-Port-Of: odoo/enterprise#124019
This fixes an incorrect display of the total exemption amount in Belgian payroll declaration 274. The change helps payroll teams review declarations with accurate displayed totals, without changing the underlying payroll process.
Original PR description
The total exemption amount (only used for display) was wrongly computed. Forward-Port-Of: odoo/enterprise#123714
Fixed FedEx label creation so enabling return labels no longer marks the original outbound shipment as a return. This keeps the expected reference field visible on outbound shipping labels, helping teams identify shipments correctly.
Original PR description
Issue ----- When setting the delivery method to create return labels aswell, the reference (`REF`) field is not present on the original outbound shipment. <img width="438" height="148" alt="image" src="https://github.com/user-attachments/assets/42acce7b-6177-4f8f-81d3-ad6dfd3e4bb2" /> Steps to reproduce ----- - Setup Fedex - Enable returns - Create a product (set weight) - Create a delivery for the product - Set carrier as Fedex - Validate delivery - Open the label > REF field is empty Cause ----- Fedex doesn't include references on the label of returns. When the option for returns is enabled, the outbound shipment is marked as a "Courtesy return". It doesn't make sense to specify a return reason on the original shipment. Expected outcome (after fix) ---- <img width="428" height="146" alt="image" src="https://github.com/user-attachments/assets/0d22e147-da90-4aa4-b3ca-2d996c7cc147" /> ----- Ticket: opw-6101620 Forward-Port-Of: odoo/enterprise#118659
The payroll payrun warning for missing payslips now checks the right information after an older filter was removed. This helps payroll teams notice incomplete payruns reliably before processing payroll.
Original PR description
The missing payslip in a payrun warning wasn't triggered correctly because we were filtering on the schedule pay of the payrun and this field was removed in a previous PR. task-6329134
Payroll users can now access the payslip correction option from the payslip itself. This makes it easier to correct payroll documents without needing to use a separate entry point, reducing friction in payroll processing.
Original PR description
The payslip correction should also be available on the payslip. This is a backport of commit 117f0117a839cd29cb9f52aaf52b1e25efe1e314 task-6374294
This fixes a commission subscription test so it correctly clears currency rate data across companies when demo data is present. It helps keep automated checks reliable and prevents false failures in subscription commission calculations.
Original PR description
Steps to reproduce: 1- Initialize a new database with demo data 2- Run the test `test_sub_commission_no_currency_rate` Issue: `AssertionError: 0 != 10 : Regular invoice, 10 percent of 100` Why this happens: The test used to delete all rows in the res_currency_rate table for the current company only. When we load the database with demo data, the query in `_get_subscription_currency_rates` would find entries for the other companies and wouldn't resort to the default. Later when joining, it would find no rates for the current company and the test fails. runbot-243440 Forward-Port-Of: odoo/enterprise#116197
The Odoo Box Point of Sale module is now included in the translation setup. This allows the module's text to be translated for users in different languages, improving localization coverage.
Original PR description
In odoo/enterprise#118646 the `obox_point_of_sale` module was added in stable, but the `.weblate.json` file wasn't updated, meaning it cannot be translated. This commit fixes the issue.
Payslip email activity now records a neutral sent-by-email note instead of incorrectly saying the payslip was re-sent. This avoids misleading payroll chatter entries and prevents duplicate notes when emailing payslips for multiple employees.
Original PR description
**Issue:** Clicking Send By Email on a payslip opens the hr.payslip.send.mail wizard. Its action_send() always logs "The payslip has been re-send to the employee." in the payslip chatter, even when…
**Issue:** Clicking Send By Email on a payslip opens the hr.payslip.send.mail wizard. Its action_send() always logs "The payslip has been re-send to the employee." in the payslip chatter, even when the payslip is being sent for the first time. The log call also runs inside the loop over the employees and goes through all the payslips of the wizard on each pass, so when the wizard sends payslips of several employees every payslip gets the same note once per employee. This started with the rework of the wizard in https://github.com/odoo/enterprise/commit/39e0488a7e076ee648b47cc3d1cad41cadfd692e **Fix:** The wizard cannot tell a first send from a resend. There is no field on the payslip that keeps track of a previous send, and the chatter cannot be used for that either because the mail sent automatically on validation can be deleted after sending. The fix changes the log in action_send() to say the payslip has been sent by email, which is true in both cases, and moves it out of the employee loop so each payslip gets exactly one note. **Steps to reproduce:** 1. In Payroll > Configuration > Settings, set "Send payslips to employees" to When Paid and save 2. In Payroll > Payslips, create an off-cycle payslip for an employee, click Compute, then Validate 3. Go back to the settings and set "Send payslips to employees" to When Confirmed 4. On the payslip, click Pay, then Mark as Paid 5. Click Print so the payslip document is generated 6. Click Send By Email and send the mail 7. Check the payslip chatter => The chatter shows "The payslip has been re-send to the employee." while the payslip was never sent before Ticket [link](https://www.odoo.com/odoo/project.task/6324204) opw-6324204 Forward-Port-Of: odoo/enterprise#123298
This fix reverts a previous change in the Belgian payroll employee form to prevent the same information from appearing twice. It keeps the employee record screen clearer and avoids confusion for HR users.
Original PR description
- A previous change has been reverted to avoid appearing twice.
Canadian EFT payment exports now use each payment’s unique ID as the Item Trace Number instead of zero-filled values. This helps ensure CPA-005 payment files meet Canadian banking requirements and avoids transaction rejections.
Original PR description
Issue: The Item Trace Number according to CPA-005 standard should be a nonzero sequence that serves as unique reference ID for payments. Currently, Odoo sets the Item Trace Number of all payments as…
Issue: The Item Trace Number according to CPA-005 standard should be a nonzero sequence that serves as unique reference ID for payments. Currently, Odoo sets the Item Trace Number of all payments as a zero-filled sequence According to CPA-005 standards on the Item Trace Number: "The data elements (b), (c) and (d) each must be greater than zero or the TRANSACTION WILL BE REJECTED" (page 36). https://www.payments.ca/sites/default/files/standard005eng.pdf Steps to reproduce: 1. Install the module l10n_ca_payment_cpa005 2. Go into "CA Company" 3. In the configuration for "CA Company", add something to the fields "Short Name used in Canadian EFT" and "Company ID" i.e. "CCC" 4. Set all the fields in the "Canadian EFT/CPA Configuration" section of the bank journal 5. Set the bank record on the bank journal. Set the field "Financial Institution ID Number" field of the "Account Number" record of the bank journal to any numerical sequence 6. Create a bank account on "Azure Interior" and make sure to check the field to trust the bank account that you created (otherwise there will be an error) 7. Create two payments with the vendor of "Azure Interior" using the payment method of "Canadian EFT" 8. Create a batch payment for both payments created 9. Validate the batch payment and the export file should show up in the chatter 10. Note that in the export file, the Item Trace Number for each payment is set to be all zeros, whereas it should be a nonzero identification sequence Solution: Set the Item Trace Number to be the payment's id opw-6323432 Forward-Port-Of: odoo/enterprise#123975 Forward-Port-Of: odoo/enterprise#123633
The Colombian DIAN invoicing flow now correctly hides the Reset to Draft option for credit notes that have already been accepted by DIAN. This prevents accepted documents from being accidentally reverted, helping maintain compliance and data consistency.
Original PR description
Issue: The reset button would still appear for credit notes that were already accepted by the DIAN. Steps to reproduce: Create a credit note, confirm it and send it to DIAN. You will be able to select Reset to Draft even though it shouldn't be possible to convert to draft after accepted by DIAN. Cause: The function to compute if the reset button would appear or not was only taking into account Invoices. Solution: Added credit notes, to the function that verifies if the reset button should appear. opw-6219265 Forward-Port-Of: odoo/enterprise#119696
This fixes an issue where payroll rule settings reused by the system could be accidentally changed during calculations. The change helps prevent hard-to-trace payroll inconsistencies by ensuring each calculation works with its own safe copy of the setting data.
Original PR description
Cached functions with `@ormcache` should not return immutable values, yet `_get_parameter_from_code()` could return dicts/sets/lists/etc. It could lead to very obscure bugs such as: ```python def…
Cached functions with `@ormcache` should not return immutable values, yet `_get_parameter_from_code()` could return dicts/sets/lists/etc.
It could lead to very obscure bugs such as:
```python
def some_innocent_code():
category_dict = self.env["hr.rule.parameter"]._get_parameter_from_code('l10n_be_work_entry_categories')
incapacity_codes = category_dict['partial_incapacity']
incapacity_codes |= category_dict['total_incapacity']
# ... then use incapacity_codes
def print_rule_param():
print(self.env["hr.rule.parameter"]._get_parameter_from_code('l10n_be_work_entry_categories')['partial_incapacity'])
print_rule_param() # OrderedSet(['LEAVE281'])
some_innocent_code()
print_rule_param() # OrderedSet(['LEAVE281', 'LEAVE264', 'LEAVE266', 'LEAVE217', 'LEAVE218', 'LEAVE219', 'MEDIC01'])
```
The solution was to either deepcopy the returned value each time, or to change all the rule parameters to their frozen equivalent. Since we don't have access to frozen objects in rule parameters's xml definitions, we opted for the deepcopy approach.
task-6329380Fixed an issue where subscription product pages could crash when a discount was configured directly on a recurring plan without a pricelist. Customers can now view the product page and see the correct discounted recurring price, avoiding checkout disruption.
Original PR description
**Problem:** On the website, a subscription product page returns a 500 error when a discount is set directly on the recurring plan (a time-based pricing rule with a plan but no pricelist). **Steps to…
**Problem:** On the website, a subscription product page returns a 500 error when a discount is set directly on the recurring plan (a time-based pricing rule with a plan but no pricelist). **Steps to reproduce:** 1. Create a subscription product with a recurring plan. 2. Add a recurring price rule for that plan with no pricelist, set as a percentage discount (base = sales price). 3. Open the product page on the website. **Current behavior:** The page fails with a 500: Internal Server Error during price computation. **Expected behavior:** The page loads and shows the discounted recurring price. **Cause of the issue:** For a recurring price rule based on the sales price, `_compute_base_price` looks up "the no-pricelist rule for the plan" to use as its base, via `_get_applicable_rules_domain(plan_id=...)`. When the discount is set directly on the plan, the rule being computed has no pricelist itself, so that search returns the very same rule and calls `_compute_price` on it again, leading to infinite recursion. **Fix:** Excluding the rule itself from the base-rule lookup lets a no-pricelist plan rule resolve its base from the product's sales price (the super() fallback) instead of re-entering its own computation. A rule applied through a pricelist is unaffected, since its no-pricelist base rule is a different record. opw-6306105 Forward-Port-Of: odoo/enterprise#121466
Fixed a payroll correction action so it consistently applies the chosen popup option to every affected payslip in a batch. This helps payroll teams avoid missed corrections when processing multiple payslips at once.
Original PR description
**What:** - Corrected the method logic 'action_keep_wrong_version' to make sure that it works for both option in the view popup. task-6356957 Forward-Port-Of: odoo/enterprise#122625
The POS now loads only the Kenya e-invoicing classification records that are actually used by products. This avoids unnecessary data loading, helping improve POS startup performance and reduce resource usage.
Original PR description
Before `product.unspsc.code` and `l10n_ke_edi_oscu.code` records were loaded without domain, which could lead to loading all records of these models in POS, which is not necessary. This commit adds a domain to the loading of these records, so that only the records that are actually used in the products are loaded in POS. Forward-Port-Of: odoo/enterprise#123992 Forward-Port-Of: odoo/enterprise#123684
This update resolves a problem preventing users from successfully downloading files through the FileViewer feature in Odoo. The previous issue stemmed from an incorrect port configuration, which has now been corrected. This ensures reliable file downloads for all users.
Original PR description
fix bad forward port 9a7ebe96750 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
This update fixes an issue where the 'Load Demo Data' button in the Employee app would overflow text when the app was set to French or Arabic. The fix automatically adjusts the button's width to fit the text, ensuring a cleaner and more user-friendly experience. This improves readability and usability for all users.
Original PR description
Steps to reproduce: ---------------------------------------- - Be in a company with no employees - Switch to French or Arabic - Open the Employee app - The text in the button overflows Cause: ---------------------------------------- The button has a specified width: `w-100` And the text is `text-nowrap` So it overflows from the button box Solution: ---------------------------------------- Make the width auto adapt to the text with `w-auto`. Before: <img width="727" height="201" alt="image" src="https://github.com/user-attachments/assets/0347125b-1595-44ea-a0bd-b7c77e6c753d" /> After: <img width="723" height="236" alt="image" src="https://github.com/user-attachments/assets/18e40b39-f7b9-488c-9e47-3b9b82bdb445" /> opw-6345094 Forward-Port-Of: odoo/odoo#274405
This update resolves an issue where attachments were incorrectly flagged as 'unsupported' when using non-UBL sending methods. The fix also corrects a minor typo, ensuring accurate attachment identification. This improves the reliability of UBL invoice sending.
Original PR description
In the send wizard, don't mark attachments as "unsupported" if the sending method is not ubl dependent Also fix a typo in "Unspported" no-task Forward-Port-Of: odoo/odoo#275301
This update streamlines the verification of EU VAT numbers during company creation. Previously, a redundant check was performed twice, impacting performance. This change consolidates the verification process to a single call, optimizing efficiency and reducing potential issues with external service limitations.
Original PR description
When we create a company with a EU VAT, we used to do 2 IAP call to verify the VAT number. One was on the create() and the other one on the write(). For performance reason and because the vies check service may limit ip address, the verification was already disable when importing files (in both create and write). This commit remove the compute on the create one (and keep the one on write), so that it only do 1 IAP call to verify the VAT. Task-6139346 Forward-Port-Of: odoo/odoo#275456 Forward-Port-Of: odoo/odoo#274644
This update fixes several issues within the HTML editor's file box functionality, specifically within the Todo module. It now correctly handles plain text pasting, prevents unexpected cursor movement, and eliminates a scrollbar that appeared when the file box was empty. These changes ensure a smoother and more reliable editing experience.
Original PR description
### Purpose of this PR: * Prevent the powerbox from opening inside a static file box. * Paste content as plain text inside a static file box, since formatting is not supported there. * Prevent the cursor from leaving an empty file name box when pressing `ArrowLeft` or `ArrowRight`. * o_we_preview_favicon had a fixed height larger than its content, causing the link popover to overflow and show an unwanted scrollbar when the file input was empty as there was nothing to preview. Reduced the height to match the actual content size. * Shorthands (such as `#` for headings or `*` for lists) should not trigger when editing inside a file box. task-6283420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275308 Forward-Port-Of: odoo/odoo#268827
This update fixes an issue where employees were incorrectly showing as having no remaining holiday days after a new allocation. The fix ensures the system accurately reflects available leave time by correctly passing the allocation date through the calculation process, even when using sudo contexts.
Original PR description
Bug : - Create a new employee (also works with old employees) - Create an allocation of Paid Time Off that is available in the future. - Create a Time Off request for this employee in the future. -…
Bug : - Create a new employee (also works with old employees) - Create an allocation of Paid Time Off that is available in the future. - Create a Time Off request for this employee in the future. - When Selecting Time off type you'll see that he has (0 remaining out of 0 days) even though he has just be allocated leaves. Reason : clicking on the many2one field => triggers web_name_search (line 53 in web/models/modeld.py) => triggers name_search (line 1514 in orm/models.py) , here we fetch the searched records with sudo , and when switching to sudo we call a function called clean_context this function (line 952 in odoo/tools/misc.py) remove elements from the context that start with the prefix default_ , in our case , we when clicking on the field we pass the target date through default_date_from , thus we lose it , and instead we make the calculations as if the target date was today Fix : pass the date_from through 'leave_date_from' given that _ compute_leaves already checks this context entry, this way we make sure to keep our start_date in the context even if we switch to sudo during some point in the calculation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273670
This update corrects a bug where clickable carousel slides linked to 'odoo.com' would incorrectly redirect users to a website URL followed by 'odoo.com'. The fix ensures that carousel links function as intended, directing users to the correct Odoo domain. This resolves a potential usability issue for website visitors.
Original PR description
Steps to reproduce: - Drop any carousel - Set any slide to clickable - Set the link to "odoo.com" (without https://) - Save => On click, you are redirected to "yourwebsite.url/odoo.com" task-5949973
This update corrects a visual inconsistency in the website's accordion controls. A previous change caused the accordion to display two different colors depending on whether it was open or closed. This fix ensures a consistent color scheme across all accordion states, improving the overall user experience.
Original PR description
In commit[1] we restyled the accordion snippets, removing the background-image to use oi-icons instead. However due to selector specificty, the rule was taking priority. This :not is actually wrong since we want the color to apply as well when the accordion is collapsed (else you have 2 different colors between the collapsed uncollapsed state) task-6361379 [1]: f26a1535b96c728e4360d94c0c06de138a6b1b3f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274577 Forward-Port-Of: odoo/odoo#274016
This update fixes an issue where the quantity delivered in the Sales Order was incorrectly reduced after a refund was processed in the POS. The fix ensures accurate tracking of order quantities, even when refunds are issued, preventing discrepancies in order reporting. A new test has been added to proactively prevent this issue from recurring.
Original PR description
**Note: issue is not reproducible anymore, but still, we add the test to ensure, bug does not reappear in future** Step to reproduce: - create a SO with a order line - settle it in pos, notice in SO line, qty_delivered is 1 - refund the pos order - notice, in SO qty_delivered is -1 , not 0 Cause: - After commit [1] , `pos_order_line_ids` now includes order and refund lines - while the `_prepare_qty_delivered` relied on fact that refund lines are not part of `pos_order_line_ids` - due to this, quantity was reduced twice (refund amount are considered twice) [1] https://github.com/odoo/odoo/commit/a12db424a6986a58d1a328fd311078994ac17aee Fix: - in the compute, we now seperate refund and order lines and thus compute works perfectly opw-6290161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269996
This update corrects a bug that occurred when attempting to merge empty distribution models within Odoo. The fix removes unnecessary merging logic, preventing errors that arose when this operation was performed. This ensures smoother and more reliable distribution model management.
Original PR description
It is possible to have an empty distribution model, there is therefore ne need to merge it, especially since it raises when doing this ```python self.env['account.analytic.plan'].mapped(lambda p: p._column_name()) ``` Forward-Port-Of: odoo/odoo#275839
A technical bug in the restaurant order tour was prematurely closing the user session, preventing error reporting. This fix ensures that errors related to order cancellations are properly logged and displayed, improving the reliability of the restaurant order process. The change addresses a reported runbot error.
Original PR description
The tour was closing the session in frontend and in the backend, which was causing a missing error. runbot error: 242197
This update fixes an issue where a 'Products' snippet added above the variant selector on a product page incorrectly displayed the snippet's first product instead of the selected variant. The fix ensures that selecting a variant always shows the correct variant information, improving the user experience. This was caused by a change in how product IDs were identified.
Original PR description
When a "Products" snippet is dropped above the variant selector on a product page, selecting a variant displays one of the snippet's products instead of the chosen variant (its image/price take over…
When a "Products" snippet is dropped above the variant selector on a product page, selecting a variant displays one of the snippet's products instead of the chosen variant (its image/price take over the page).
Steps to reproduce
===================
1. Create a product with 2+ variants and publish it.
2. Edit the product page, drag any block above the variant selector and add the "Products" dynamic snippet, then save.
3. Select a variant. => The page shows the snippet's first product instead of the variant.
Root cause
==========
`ProductPage._getCombinationInfo` reads the product ids from `parent.querySelector('button[name="add_to_cart"]')`, with `parent` being the whole `.js_product`. `querySelector` returns the first match in DOM order, and the dynamic "Products" snippet's cards reuse the same `button[name="add_to_cart"]` markup with their own product ids. When the snippet sits above the variants, its button comes first, so `/website_sale/get_combination_info` is called with the snippet product's ids and the page is updated with that product's data.
The interaction was introduced in saas-19.1 (See [1]) and the lookup switched from the unique `#add_to_cart` id to the by-name selector in (See [2]), which is what started matching the snippet's cards.
Fix
===
Pick the first `add_to_cart` button that is not inside a product card (`.oe_product_cart`), i.e. the main product's button.
[1]: https://github.com/odoo/odoo/commit/4682748e6e3c#diff-7e1a99da9e95d0c4df79ee4d7aa718e46bcb8b7f1ed78cde58782e075c833cd1R326
[2]: https://github.com/odoo/odoo/commit/1c732cf75a4a4faa960d6a98f08ae9dbe99b2b69#diff-7e1a99da9e95d0c4df79ee4d7aa718e46bcb8b7f1ed78cde58782e075c833cd1R329
opw-6248285
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#268518This update removes a confusing message ('Connect your software...') from sales quotations that was appearing in PDF documents for customers with portal access. The change ensures all quotes, regardless of customer portal usage, display the standard, streamlined portal button. This improves the customer experience and avoids unnecessary confusion.
Original PR description
Steps to reproduce: 1. Install Contacts and Sales 2. Open any of the contacts, click on the gear icon at the top and click on "Grant portal access" 3. Grant access to all contacts 4. Create a Sale Quotation for that contact and print it Issue: The sentence 'Connect your software... ' appears in the pdf when sending the quote to a contact who was portal access, while it does not appear if the contact does not have portal access Expected behavior: Should not appear regardless of whether the customer has a portal account or not since they have it appear as a smart button in their portal. opw-6308357 Forward-Port-Of: odoo/odoo#275469 Forward-Port-Of: odoo/odoo#272893
This update automatically sets accounts as non-reconcilable when reconciliation with banks or cash transactions isn't expected. This simplifies the accounting process for various Odoo localization modules (like CA, KE, US, etc.) by preventing unnecessary reconciliation steps. It ensures that accounts are configured correctly from the start, reducing potential errors and improving data accuracy.
Original PR description
Changing the "payment reconciliation" boolean to false where it should be, ie. when no reconciliation with the bank nor cash transaction is expected. task-4902124
This update fixes an issue where duplicated point-of-sale printers would lose their configured IP addresses. The fix ensures that when a printer is duplicated, it retains the original IP address, simplifying setup and preventing connection problems. This improves the reliability of the POS system.
Original PR description
Steps to reproduce: ==== - Configure a printer from printers menu. - Duplicate the printer. Issue: ==== - The duplicated printer's IP address is reset to `0.0.0.0`. Cause: ==== - copy_data()` unconditionally overrides `printer_ip` with `0.0.0.0`. Fix: ==== - Stop overriding `printer_ip` so the duplicated printer inherits the original IP address by default. task-6365809 Forward-Port-Of: odoo/odoo#274964
This update fixes several issues within the Odoo spreadsheet component, ensuring improved stability and functionality. It addresses problems with chart rendering, conditional formatting, and named range selection, enhancing the user experience. Multiple developers collaborated on this update to ensure a robust solution.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/35c06d3a8 [REL] 19.3.11 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/35c06d3a8 [REL] 19.3.11 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/ed527c0f5 [FIX] named range selector: select hidden named range [Task: 6171849](https://www.odoo.com/odoo/2328/tasks/6171849) https://github.com/odoo/o-spreadsheet/commit/2e56727ca [FIX] conditional_formatting: handle zero color scale midpoint [Task: 6312961](https://www.odoo.com/odoo/2328/tasks/6312961) https://github.com/odoo/o-spreadsheet/commit/da294bd6a [FIX] charts: handle undefined values in treemap chart [Task: 6329404](https://www.odoo.com/odoo/2328/tasks/6329404) https://github.com/odoo/o-spreadsheet/commit/a40202e4f [FIX] config: filter-out claude folder from prettier [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update improves the accuracy of PDP verification tracking within the French localization module. It now ensures that PDP-specific tracking is only applied when the company is correctly configured for PDP, preventing incorrect tracking data from being displayed. This change addresses a potential issue where companies not set up for PDP could incorrectly show PDP tracking information.
Original PR description
The PDP-specific verification tracking must only be used when the active company is configured for PDP. Otherwise, a recipient using the 0225 identifier could show PDP/annuaire tracking while being checked from a non-PDP company. Related to odoo/odoo#275186
This update resolves an issue where pressing the space key in the Contact app could cause a technical error. The fix ensures the system handles missing configuration data gracefully, preventing the error and maintaining a stable user experience. This improvement enhances reliability for users working with Contact records.
Original PR description
**Steps to reproduce:** - Go to Contact app - Open any record - Press "Space" key - Traceback: `Cannot read properties of undefined (reading 'groupId')` **Issue:** `quickCreateState` props is undefined (as it is optional). **Fix:** Add check to safely handle such cases. [introduced by] https://github.com/odoo/odoo/commit/22c07c7dcb2a93d9ebef5a83e48aa3d252128519 opw-6377425 Forward-Port-Of: odoo/odoo#275329
A recent update to the website builder was causing slow loading times due to a delay in fetching image sources. This fix resolves the issue by ensuring images have the correct source data, preventing performance bottlenecks and improving the builder's responsiveness. This impacts the user experience when updating website content.
Original PR description
Commit [1] introduced a cache for images' src in `_getValidSrc`. An undefined src will work but block the thread for a moment (up to seconds in some cases) until `fetch` returns a 404. The bug can be seen from the website builder: - Open the builder - Open your dev tools on the "network" tab - Click on the website logo => a failed fetch (404) appears and blocks the builder from being updated quickly. It happens because the element doesn't have any `dataset.originalSrc` (in this case, because it is an image field). [1]: https://github.com/odoo/odoo/commit/5164080cbadddaa7052dd4d2f997b944bd7a16e8 task-6247171 Forward-Port-Of: odoo/odoo#275078
This update ensures that all user-defined descriptions for invoice lines are accurately exported in UBL format. Previously, the system only captured one description tag, but this change now correctly handles multiple descriptions, preventing data loss and improving the accuracy of invoices.
Original PR description
1) Previously, we were supposing that only one <cbc:Description> tag could be found on InvoiceLine item. After checking the UBL XSD, I found we could have multiple Description tags for one item. 2) The import order of <cbc:Name> and <cbc:Description> on the invoice line now has been changed to be more accurate and prevent loss of information. The export has been adapted to this change too. Now, we export the actual description written by the user. task-6153895 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270308 Forward-Port-Of: odoo/odoo#261949
This update adds a check to ensure contact emails entered during the French PDP registration process are valid. Previously, invalid emails could lead to errors later, causing frustration for users. This change improves data quality and prevents potential issues during the registration workflow.
Original PR description
No verification was done on the contact email in the wizard but if the email is invalid the user would have an error later task-6344324 Forward-Port-Of: odoo/odoo#274065
This update resolves an error that occurred when multiple product images with the same content were used on the website's 'Optimize SEO' feature. The fix ensures that image IDs are uniquely identified, preventing the 'duplicate key' error and improving the stability of the SEO optimization process. This ensures the website's SEO tools function correctly for all users.
Original PR description
## Problem: when snippets with identical images are added in the e-commerce website product page, the "Optimize SEO" option in debug mode causes an error to occur with a traceback. The traceback…
## Problem:
when snippets with identical images are added in the e-commerce website product page, the "Optimize SEO" option in debug mode causes an error to occur with a traceback. The traceback calls out a duplicate key in the `t-foreach` of a loop over `state.altAttributes`. the `t-key` for this loop is `img.id` which is generated by the `/website/get_alt_images` controller endpoint.
## Steps to reproduce:
1. Go to a product page and click on "go to website" smart nav btn.
2. Add a snippet with an image in the `description_ecommerce` field
3. Add a snippet with the same image in the `website_description` field.
4. In debug mode, open `site > Optimize SEO`
5. An error `Got duplicate key in t-foreach` is thrown.
## Solution:
The solution was simple to add a qualifier in the compound key generated by the controller action for the `id` field. The chosen qualifier in this case was `model['field']`. `field` is the position in the template where the image came from.
So now the keys for the two identical images go
FROM
> `${model}-${id}-${index}`
>
> 1st image of `website_description`:
> `product.template-6-0`
>
> 1st image of `description_ecommerce`:
> `product.template-6-0`
TO
> `${model}-${id}-${field}-${index}`
>
> 1st image of `website_description`:
> `product.template-6-website_description-0`
>
> 1st image of `description_ecommerce`:
> `product.template-6-description_ecommerce-0`
task-6325786
Forward-Port-Of: odoo/odoo#275789
Forward-Port-Of: odoo/odoo#272846This update fixes an issue where a database index wasn't being utilized by Odoo's internal queries. The change ensures the index works correctly for all queries, including those generated by Odoo, improving data retrieval performance. This enhances the efficiency of project and to-do related operations.
Original PR description
The index added by 778c09f4ffb4 works for the specific query it was meant to improve. Unfortunately, it cannot be used by ORM-generated queries, which is unfortunate. The reason is that the ORM generates queries with `IS TRUE` or `IS NOT TRUE` for boolean fields. Because `=` and `IS` do not have the same semantics, postgresql cannot use the index for ORM-generated queries. = -> eval(NULL = True) -> NULL IS -> eval(NULL IS TRUE) -> FALSE By changing both the index and the query to use `IS TRUE`, the index is now used by both the specific query and the ORM. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275681
This update fixes a discrepancy in how the VAT tax date is calculated for Serbian invoices. Previously, the default date was set to 'By Issuance Date,' which wasn't compliant with Serbian law. Now, the default is 'By Delivery Date,' aligning with Article 16 of the Serbian VAT Law and ensuring accurate tax reporting.
Original PR description
According to[ Article 16 of Serbia's VAT Law](https://www.paragraf.rs/propisi/law-on-value-added-tax.html#:~:text=of%20Tax%20Obligation-,Article%2016,-A%20tax%20obligation), the tax obligation arises at the time of delivery of goods/services by default. 'By Issuance Date' only applies to a narrow set of services under Article 16(2a) Before: l10n_rs_tax_date_obligations_code defaulted to '3' (By Issuance Date) After: defaults to '35' (By Delivery Date) Upgrade: odoo/upgrade#10657 task-6348377 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273608