Friday, October 11, 2024
25 changes
2 changes
Resolved issues and error corrections
This fixes how accounting taxes are calculated when one tax affects the base used by later taxes. Follow-up tax amounts and reporting tags are now only applied when the next tax is configured to be affected by the previous tax, helping prevent incorrect invoice tax totals and reports.
Original PR description
we have the same functionality before this commit https://github.com/odoo/odoo/commit/ab0bdf0192120671010634978f202da35ddfc79f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customers can now use recently viewed product carousels to return to a previous product variant correctly. This fixes a broken page update when shoppers changed variants and then selected another variant from the carousel, improving the browsing experience on online stores.
Original PR description
Versions -------- - saas-17.2+ Steps ----- 1. Go to eCommerce; 2. go to a product page with variants; 3. open editor; 4. drag & drop a "Products" block from Dynamic Content; 5. click on the newly…
Versions -------- - saas-17.2+ Steps ----- 1. Go to eCommerce; 2. go to a product page with variants; 3. open editor; 4. drag & drop a "Products" block from Dynamic Content; 5. click on the newly added block; 6. set filter to "Recently Viewed Products"; 7. save; 8. change an attribute of the current product; 9. use the added carousel to go back to the previous variant. Issue ----- Nothing happens. Cause ----- Commit 016a72bae9c3 changed the event listener on website_sale from `hashchange` to `popevent` with a check on the event's `state?.newURL` attribute. Issue is that this will always be `undefined`, as there's no logic in place to push or replace states[^1] when viewing products. Solution -------- Revert the change, and have the listener trigger on `hashchange` events[^2] again. > [!Note] > In the future we could consider moving away from using the URL hash property[^3] for storing product attribute ids to a more conventional practice, as was intended by the commit that made this change. opw-4150284 [^1]: https://developer.mozilla.org/en-US/docs/Web/API/PopStateEvent/state [^2]: https://developer.mozilla.org/en-US/docs/Web/API/Window/hashchange_event [^3]: https://developer.mozilla.org/en-US/docs/Web/API/URL/hash
10 changes
Resolved issues and error corrections
Paid point-of-sale orders can no longer be deleted before they have been synced to the backend. This helps prevent lost sales records and reduces the risk of discrepancies between the register and central system.
Original PR description
Before this commit it was possible to delete a paid order that wasn't yet synced to the backend. This commit adds a check to prevent this behavior. taskId: 4250522
This fixes an issue that prevented users from printing quotations when working with a Brazilian company. The Brazilian sales tax totals template now receives the needed quotation values correctly, avoiding the error during report generation.
Original PR description
Currently, you can't print quotations with a Brazilian company. ### Steps to reproduce * install `l10n_br_sales` * switch to a Brazilian company * attempt to print a quotation You should be met with…
Currently, you can't print quotations with a Brazilian company.
### Steps to reproduce
* install `l10n_br_sales`
* switch to a Brazilian company
* attempt to print a quotation
You should be met with the following traceback:
```
TypeError: 'NoneType' object is not subscriptable
Template: l10n_br_sales.document_tax_totals_brazil
Path: /t/tr[1]
Node: <tr t-if="\'cash_rounding_base_amount_currency\' in tax_totals"/>
```
### Cause
The `l10n_br_sales.document_tax_totals_brazil` currently overrides `sale.document_tax_totals` using the following code:
```xml
<xpath expr="//t[@t-call='sale.document_tax_totals']" position="replace">
<t t-call="l10n_br_sales.document_tax_totals_brazil"/>
</xpath>
```
However, there was a recent update (d0e7be7832672d476f1b289af52d3a425990d719) to the `sale.document_tax_totals` call, as shown below:
```diff
- <t t-set="tax_totals" t-value="doc.tax_totals"/>
- <t t-call="sale.document_tax_totals"/>
+ <t t-call="sale.document_tax_totals">
+ <t t-set="tax_totals" t-value="doc.tax_totals"/>
+ <t t-set="currency" t-value="doc.currency_id"/>
+ </t>
```
With this change, the override in `l10n_br_sales.document_tax_totals_brazil` will no longer have access to the `tax_totals` and `currency` values because they are now passed inside the `t-call` block of `sale.document_tax_totals`.
opw-4239563Kiosk ordering now stops gracefully when an order cannot be created, such as during an offline connection. Instead of showing a technical error, users see an appropriate message, improving the self-ordering experience.
Original PR description
Traceback is shown when making an order in kiosk because we try to proceed even if no order is created in the backend. In this fix, we return early in the `confirmOrder` procedure when no order is created (e.g. when offline). The following is shown instead of the traceback: 
This fixes a form validation issue where fields that were no longer required could remain marked as invalid after a related field was filled in. Users can now save records normally without entering and removing temporary values, improving reliability in forms such as approval rules.
Original PR description
Have a form view with two fields A and B, which are both required if the other one is unset: ```xml <form> <field name="A" required="not B"/> <field name="B" required="not A"/> </form> ``` Open a…
Have a form view with two fields A and B, which are both required if the other one is unset:
```xml
<form>
<field name="A" required="not B"/>
<field name="B" required="not A"/>
</form>
```
Open a form view and unset A and B. Try to save: both fields are marked as invalid (highlighted in red). Fill one of them and click out.
Before this commit, the other field was still marked as invalid. Worse: the save button was still disabled. One thus had to fake a value in that field, then remove it, to be able to save the record.
The issue occurred because when a field changed, we only removed that field from the list of invalid field. We didn't considerer other invalid fields (unset, but required) that could become valid with the change because they are no longer required. With this commit, we remove from the list of invalid fields those that were unset and required, but are no longer required now.
The issue could be reproduced in the `studio.approval.rule` form view with fields `approver_ids` and `approval_group_id`.
Followup of task~4122644
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-prThis fix restores invoice printing for Saudi companies after a recent internal tax calculation change caused an error. Businesses using Saudi e-invoicing can generate and print invoices again without hitting a traceback.
Original PR description
### Steps to reproduce * install `l10n_sa_edi` * switch to a Saudi company * create an invoice and attempt to print it You should be met with a traceback: ``` odoo.addons.base.models.ir_qweb.QWebException: Error while render the template KeyError: 'id' Template: l10n_gcc_invoice.arabic_english_invoice Path: /t/t/div/table/tbody/t[3]/tr/t[1]/td[2]/span Node: <span class="text-nowrap" t-field="line.l10n_gcc_invoice_tax_amount"/> ``` ### Cause The calculation of `l10n_gcc_invoice_tax_amount` relies on code that was recently refactored, and therefore doesn't work anymore opw-4243831
This fix ensures additional Ecuadorian companies can be created without running into journal access errors. It also sets up default withholding accounts automatically, reducing manual configuration and setup issues for new companies.
Original PR description
In v18 I installed the EC localization and the first EC company was created. I try to create the second EC company. Cannot create and I get the following error Solution Use `@template` annotation to create journals in l10n_ec_edi Additionally, we call the method `_l10n_ec_configure_default_withhold_accounts` in load() to set accounts by default 
This fix prevents an error when saving Ecuadorian vendor bills that include reimbursement lines. It helps accounting users complete reimbursement-related bills reliably without interruption.
Original PR description
- Replicate error in runbot v18: 1. Create a Vendor Bill with partner 'Instituto Ecuatoriano de Seguridad Social' 2. Add a reimbursement line with all the fields set up 3. Press the save button - Solution: Call the method _round_base_lines_tax_details before the _get_tax_totals_summary method to add the raw base amount in the base lines dictionary - Screenshot 18.0 runbot 
Creating an employee from a candidate with skills no longer triggers an error caused by duplicate skill records. This ensures recruiters can complete the candidate-to-employee conversion smoothly without manual workarounds.
Original PR description
Steps --- * Create a candidate * Give them a skill * *Create Employee* * => Traceback -> "Two levels for the same skill is not allowed" Cause --- * on `hr.employee.skill` we have a unique constraint on the skill employee pair * but when creating an employee we would attepmt to create the skills twice, once through regualr create and once from the override of `_update_employee_from_candidate` call in the write Fix --- Remove the `_update_employee_from_candidate` method, which seems unnecessary. task-4207776
Subscription invoice tracking has been cleaned up so the latest invoiced date is recalculated when invoices change, such as being reset or refunded. This helps keep subscription billing information accurate and reduces ambiguity in the underlying process.
Original PR description
In this commit we try to clean some ambiguity to improve the code readability.
The mobile web interface now avoids triggering native mobile app communication and related permission prompts unless the feature is actually used. This reduces unnecessary Bluetooth permission requests and prevents startup error noise in the mobile app, improving the first-use experience.
Original PR description
This commit adds a system to enable the loop communication with the native Odoo Mobile App only when the bus is actually used.
13 changes
Resolved issues and error corrections
This fix corrects an issue where auditing expense categories with vehicle split enabled was showing duplicate line items. Lines associated with vehicles were appearing both in the category audit and in individual vehicle audits. The fix ensures vehicle-related lines are excluded from category audits when vehicle split is active, eliminating the duplication.
Original PR description
…le split Currently, when auditing a DNA category with the vehicle split option leads to incorrect values. All the lines from the account being audited are displayed, including those with a 'vehicle_id'. That is wrong, since these lines will be grouped with the corresponding vehicle inside said category. They will appear both when auditing the category as well as when auditing each vehicle from this category. The solution is simply to exclude lines related to a vehicle when auditing a category while the vehicle split is active. task-4023543 Forward-Port-Of: odoo/enterprise#71382
This fix prevents incorrect validation errors when posting expense reports with incomplete partner addresses. The tax address validation is now only applied to customer invoices and credit notes, where external tax integrations are actually used, rather than blocking expense report processing.
Original PR description
1. Enable "auto-detect" on the Avatax fiscal position, 2. Go to "Abigail Peterson" contact and set "United States" as country 3. Expenses > My Expenses > New 4. Enter a description, set a total and "Abigail Peterson" as employee 5. "Create Report" > "Submit to Manager" > "Approve" > "Post Journal Entries" Issue: Validation error will raise because of the incomplete address However we only handle customer invoices and customer invoice refunds (aka credit notes) with external tax integrations so the constraint should only show for journal entries of this type. opw-4151193 Forward-Port-Of: odoo/enterprise#71543
When a company changes its global appraisal plan in settings and has appraisal automation enabled, the system now automatically recalculates the next appraisal date for all employees. This ensures that employee appraisal schedules stay synchronized with the company's current plan settings.
Original PR description
There is an *Appraisal Plan* section in the setting that allows setting the global plan for the company. If *Appraisal Automation* is enabled and the plan is changed, we want to recompute the next appraisal date based on it for all the company employees. task-4167727
This fix ensures that when two support tickets are merged together, the total hours spent on both tickets are correctly combined and displayed. Previously, the system was not recalculating the total hours after a merge, resulting in incomplete time tracking data.
Original PR description
### Steps to reproduce: - Create two helpdesk tickets - Create a timesheet for each one of those tickets - Merge the tickets together - Check the 'Hours spent' field where it doesn't show the addition of the two tickets' total_hours_spent ### Current behavior before PR: This is happening because when flushing after merging the tickets the total hours spent does not show in the recomputation tree so it doesn't get recomputed. ### Desired behavior after PR is merged: The idea of the fix came from this commit https://github.com/odoo-dev/enterprise/commit/f4aedadbd6180049573c2b4d90ffc0dd4656ea06#diff-9a1216d4c95d4f60296c59d0294e505970b4d97ad4ac256e1a87c7289f1f8129R17 since the issue got resolved in 17.4 because of this commit where it changed the dependency of the project_id which leads to the existance of the total_hours_spent in the tree of recomputation that is depending on the helpdesk.ticket.project_id opw-4226970
This fix corrects an error in the Holiday Attest (N-1) document used in Belgian payroll processing. The end date on the attestation was incorrect and has been updated to match the end of the notice period, ensuring employees receive accurate documentation when leaving the company.
Original PR description
The end date on the Holiday Attest (N-1) was wrong. It should be the same as the end of the notice period.
This fix resolves an error that occurred when generating customer statement reports for WhatsApp templates. The system was failing to retrieve the correct data needed for the report, causing the template generation to crash. This update ensures that customer statement reports can now be successfully created and submitted for approval.
Original PR description
Install whatsapp Create a new template as follows: - Account: any (real values not needed to reproduce the issue) - Header Type: Document - Report: Customer Statement - Body: Any Save and Submit for Approval Issue: Tracback will raise during template generation """ TypeError: 'NoneType' object is not subscriptable Template: l10n_account_customer_statements.customer_statements """ This occurs because when generating the report for the template we miss the correct data. Partial backport of f0a82fc57826346d7edae1465b35303bc7d1649c opw-4133970
This fix corrects a display issue in inter-company transactions where purchase order confirmation messages were showing the wrong company name. When syncing sales orders across companies, the system was incorrectly displaying the current user's company instead of the actual company that created the order. This fix ensures users see accurate company information in their purchase order notifications.
Original PR description
Reproduce the issue: - Turn on inter-company transactions to sync Sales and Purchases - Create an SO in one company for the second company - Chatter displays an incorrect message noting the record was created from the current company instead of the triggering company The issue: In the sale_order.py model of sale_purchase_inter_company_rules.py, the field of the current company was used instead of the field of the order's company. opw-4199979 Forward-Port-Of: odoo/enterprise#71624
This fix enables customers to print receipts directly from the self-order kiosk using IoT-connected printers, a capability that was previously unavailable. This improves the customer experience by allowing them to obtain physical receipts at the point of sale without manual intervention.
Original PR description
This commit is a backport of https://github.com/odoo/enterprise/commit/e2da8c4fbbfb50ddc033cf30885fef4394cbe2dc It enables printing receipts in the kiosk using the iot which was not supported before. opw-4120145
This fix corrects how currency exchange rates are calculated for Mexican invoices paid in a different currency. Previously, the system was using rounded amounts to calculate rates, which caused inconsistent exchange rate values in payment documents. The fix now uses the proper conversion rate calculation to ensure all payment records show consistent and accurate exchange rates.
Original PR description
### Steps to reproduce the issue: 1. Activate Mexican localization 2. Create multiple Invoices in USD with different amounts (add the Invoice Date) 3. Send and Print them for the CFDI 4. Register a…
### Steps to reproduce the issue: 1. Activate Mexican localization 2. Create multiple Invoices in USD with different amounts (add the Invoice Date) 3. Send and Print them for the CFDI 4. Register a grouped Payment in MXN for those invoices 5. Go to one of the Invoices and click on Update Payments 6. Go to the CFDI tab and, on the Payment line, click on Force CFDI 7. On the Payment line, you should now be able to Download an XML document 8. In the document, the EquivalenciaDR attributes should have the same values, which is not the case ### Explanation: When calculating the rate (which then is used in EquivalenciaDR) in `_l10n_mx_edi_add_payment_cfdi_values`, we are using amounts that have been rounded out, leading to rates that differ when aiming for certain decimal precisions. ### Fix reasoning: While `_get_conversion_rate` can be used to avoid the inconsistencies of the rounded amounts, it should not be used if the values do not match once they are converted, since the rate would then be wrong. opw-4090269
This fix corrects an accounting discrepancy in German DATEV tax reports where invoice line amounts were being rounded incorrectly, causing amounts to appear 0.01 currency units lower than actual (e.g., 19.94 instead of 19.95). The fix ensures that the original invoice price is used directly in the report rather than a recalculated rounded value, improving accuracy of exported financial data for German tax compliance.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_de_reports - Switch to a German company - Create a 19% included tax - Create an invoice with the following line: * Product: [any] * Quantity:…
**Steps to reproduce:** - Install Accounting and l10n_de_reports - Switch to a German company - Create a 19% included tax - Create an invoice with the following line: * Product: [any] * Quantity: 1.00 * Price: 19.95 * Taxes: [the 19% included tax] - Confirm the invoice - Go to "Accounting / Reporting / Audit Reports / General Ledger" - Download "DATEV DATA (ZIP)" and check "EXTF_accounting_entries.csv" **Issue:** The line for the created invoice has an amount of 19.94 instead of 19.95. **Cause:** As the tax is included, the balance on the line is computed and rounded. When the report is generated, "compute_all" is executed with the rounded balance to retrieve the total price with the taxes. Because the balance used in "compute_all" has been rounded and therefore is not exactly the same than the original computed value, there can be a 0.01 difference. **Solution:** Use directly "price_total" field when available. opw-4191876 Forward-Port-Of: odoo/enterprise#70801
The restart buttons for the Odoo service and IoT box in the backend were not functioning after the IoT homepage was redesigned. This fix updates the restart buttons to use the correct endpoints from the new homepage, restoring their functionality.
Original PR description
In the rewrite of the IoT homepage, the endpoint for restarting the Odoo service or rebooting the IoT box was changed, leaving the restart buttons in the backend nonfunctional. This PR changes the endpoints used by the buttons to match the new homepage, fixing the issue.
Fixed a bug in the General Ledger search functionality where searching for non-existent accounts would display all lines instead of showing no results. The search filter now correctly shows an empty result set when no matching accounts are found, improving the accuracy and usability of the search feature.
Original PR description
Open General Ledger Search for a non existing account/aline (ex. "1111111111111") Issue: All lines are shown This occurs because we update matched lines only if there is a match, otherwise we reset the filter opw-4160605
This fix ensures that when a subscription product is purchased and paid for at the point of sale, the next invoice date is properly updated in the system. Previously, the next invoice date was not being updated after payment, which could cause billing timing issues for recurring subscriptions.
Original PR description
Steps to reproduce: - Install subscription and pos_sale_subscription - Create a sale order with a recurring product (a subscription) - Settle the sale order in the point of sale - The date of the next invoice is not updated To fix this issue, when the pos_order is paid, we will update the next invoice date of all sale orders in lines that are of type subscription. opw-4072950