Tuesday, September 3, 2024
16 changes · 17.0
Resolved issues and error corrections
This fix prevents the POS box homepage from disconnecting Wi-Fi when updating network settings. It now updates the current configuration instead of removing an outdated file, making device connectivity more reliable for stores.
Original PR description
We still disconnected from wifi unlinking the old file, despite that we moved this configuration to `odoo.conf`. We replaced that.
Grouped views by activity status now include records that do not have any activity assigned. This prevents missing business records in reports or list views and places them in an empty activity-status group instead.
Original PR description
Before this commit: ------------------- If you want to group by records that inherit from mail.activity.mixin like crm.lead for example, only records with an activity will show up in the result, record without activity won't show up. After this commit: ------------------ Read group is not expected to filter record. Record without activity shows up under the group None since the value for activity state is None --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix keeps the date and time picker listening until the input is fully removed, preventing recently entered values from being dropped in rare timing cases. It helps ensure users' datetime changes are reliably saved when fields are closed or removed from the screen.
Original PR description
Before this commit, event listeners set on inputs by the datetime picker service would be removed in the callback of the `useEffect` hook, meaning that these listeners could be unregistered before…
Before this commit, event listeners set on inputs by the datetime picker service would be removed in the callback of the `useEffect` hook, meaning that these listeners could be unregistered before the actual elements would be removed. This is an issue in the specific case where the deletion of the element occurs before the "change" event has been dispatched and after the removal of the listeners. The thing is: the removal of the element also triggers the "change" event (if it hasn't been triggered before), and with the listener gone this means that the value is lost. This commit deletes the removal of event listeners attached on inputs by the hook. This has been done since using the datetime picker service implies that the inputs affected by the feature will never be in an interactive state without the datetime picker actively listening on them. Although a test case setup is easy to reproduce, this behavior is unfortunately impossible to reproduce programmatically as the "change" event dispatched by removing an element only works when a trusted "input" event was triggered to change its value (setting the internal browser "changed" value of the input). Task [4104407](https://www.odoo.com/odoo/all-tasks/4104407) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The IoT Box now closes any existing browser session before opening a new one after Odoo restarts. This prevents browser processes from piling up over time, helping keep connected display hardware stable and responsive.
Original PR description
As we never kill browser instances, IoT Box gets saturated by browser threads if odoo restarts multiple times. We now kill the browser before starting a new.
The Uruguay localization now uses the correct tax accounts for VAT 0% sales and purchases. This prevents invoice and bill creation errors and keeps tax reporting consistent for exempt VAT transactions.
Original PR description
### Description of the issue/feature this PR addresses: Wrong account on tax definition. Taxes should not have related payable and receivable accounts. ### Current behavior before PR: VAT 0% Exempt taxes has a payable account, this not valid one and will result on error when creating an invoice with that tax. We resolve the problem by changing the account used on the tax definition with new accounts, one for Sales (Current liabilities) and another for Purchase (Current Aseste), the same way is made for the VAT 22% and VAT 10%) ### Desired behavior after PR is merged: Taxes has the proper account and we are able to create invoices/bills with tax 0% without problem ADHOC ticket 76475 - task 34060 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Cash App Pay is now correctly recognized when used through Stripe or Adyen. This prevents checkout failures for customers who choose Cash App Pay, helping merchants avoid lost or interrupted payments.
Original PR description
Version : 17 Steps to Reproduce: Install the Stripe or Adyen Payment Provider. Activate the CashApp payment method. Attempt to make a payment using CashApp at checkout. Issue: Users encounter an error when selecting the CashApp payment method during payment. The error is caused by the use incorrect code of Cash App Pay payment method, resulting in a traceback. Cause: The error occurs because Cash App Pay payment method not mapped with correct code. Fix: Add the correct code 'cashapp' to the 'PAYMENT_METHODS_MAPPING' variable of stripe and ayden. opw-4132745
This update speeds up searches in journal entries for large databases by improving how the accounting records are queried. Users should see much faster search results, reducing wait times from tens of seconds to near-instant in the reported case.
Original PR description
**Description of the issue/feature this PR addresses:** In large database, the time to search in Journal Entries is slow. Before 52 000 ms after 100 ms. LATERAL is not the best, use EXIST. @oco-odoo Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4073959) opw-4073959 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customer invoices created for a branch can now select bank accounts belonging to the parent company. This prevents billing delays or manual workarounds when branches need to use shared company banking details.
Original PR description
### Issue: The bank accounts of a company are not accessible from the branches of this company. ### Steps to reproduce: - In Settings, create a company and a branch company - In the contact app, add…
### Issue:
The bank accounts of a company are not accessible from the branches of this company.
### Steps to reproduce:
- In Settings, create a company and a branch company
- In the contact app, add a bank account for the company
- Switch to the branch company
- In the Accounting app, create a Customer invoice
- In the "Other Info", change the Company to the branch
- The bank account created does not show up in the selection of the field "Recipient Bank"
### Cause:
The current domain is `domain="[('partner_id', '=', bank_partner_id)]"` which is only taking the res.partner.bank record linked with the partner of the company (bank_partner_id).
### Solution:
The solution must work on companies not partners and use the 'parent_of' keyword so that the branches can access the records. Changing the domain to `[('partner_id.ref_company_ids', 'parent_of', company_id)]` works.
### Note:
- The field `ref_company_ids` is an old field that is almost not used anymore, but it is the only link between res.partner.bank and the company it is linked to.
- This domain used `partner_id.ref_company_ids` in an old version of Odoo, but it was changed in this commit: https://github.com/odoo/odoo/commit/1db371721f3549276ee622e8b4369db7ce13863c because of a bug. I did not manage to reproduce the bug in v17 with this fix.
Ticket [link](https://www.odoo.com/odoo/project.task/4027680)
opw-4027680Stripe express checkout now carries the customer's phone number into the shipping contact created for the order. This helps sales and delivery teams have complete customer contact details after Apple Pay or Link purchases.
Original PR description
Steps to reproduce: - Install `payment_stripe` and `website_sale` - Configure express checkout for stripe - Add public/secret keys and - Enable "Apple Pay" in settings (to do this comment out this block) https://github.com/odoo/odoo/blob/0527b4b2ffe7d42222334b06a22739cf4963c617/addons/payment_stripe/models/payment_provider.py#L234-L237 - Enable "Link" in Stripe and add payment domain to ngrok domain - Go to website in incognito page and open a product - Add it to cart and click on the express checkout button - Complete process to pay - Go to contact linked to sale Issues: Phone is missing, this is because during the creation of the shipping address `res_partner` record we don't have the phone. https://github.com/odoo/odoo/blob/0527b4b2ffe7d42222334b06a22739cf4963c617/addons/payment_stripe/static/src/js/express_checkout_form.js#L171-L181 opw-4055084
This fixes an issue where Point of Sale incorrectly showed an error when entering payments with larger cash rounding values, such as rounding to 10. Cashiers can now process rounded cash payments without unnecessary interruptions.
Original PR description
Before this commit, entering a payment amount with cash rounding higher than one (e.g., 10) incorrectly triggered an error popup every time. opw-4124332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where the document preview window would unexpectedly close when users tried to add tags to a document. This improves the user experience by allowing users to add tags without losing their place or having to reopen the document preview.
Original PR description
Current behaviour: --- When you open a document, and you want to add a tag, the preview closes. Steps to reproduce: --- 1. Go to Documents 2. Open a document 3. Add a tag 4. The preview closes Cause of the issue: --- In updateRecordTagId from documents_search_model.js Update trigger > load > documents-close-preview trigger opw-3879288
This fix ensures that only service products can be used when creating sales order lines directly from helpdesk tickets. Previously, non-service products could be incorrectly added, which could cause issues with timesheet tracking. Now the system properly validates that only service products are allowed and shows a clear error message if someone tries to use a non-service product.
Original PR description
### Before this PR: ->If we create a product that isn't a service > open the helpdesk ticket form view -> type the name of the product you created from the SOL field and click create -> a new SOL is generated for this product and is successfully set on the ticket ### After this PR: A new SOL is generated only for service products, it should only be allowed for services products, it will throw validation error that isn't service task-3972359
This fix resolves a problem where marketing campaign activities were not displaying correctly when campaigns contained more than 40 activities. The system was splitting activities across multiple pages, but the hierarchical organization of parent and child activities only worked when all activities were loaded together. By removing the page limit, all activities now display properly regardless of quantity.
Original PR description
Current behaviour: --- When you create a campaign, if you add more activity (56) than the default pager limit (40) The next pager page will be empty (instead of showing the remaining 16 activities)…
Current behaviour: --- When you create a campaign, if you add more activity (56) than the default pager limit (40) The next pager page will be empty (instead of showing the remaining 16 activities) Steps to reproduce: --- 1. Go to Marketing Automation 2. Create a campaign 3. Create more than 40 activities 4. Alternate parents/child when creating 5. The pager will appear, with at least 2 pages 6. Go to the second page 7. Nothing displayed NB: When inputting the number of activities in the pager, everything is rendered fine. Cause of the issue: --- To be displayed, the activities are hierarchised, by finding child and parents (`_getSortedRecordsByHierarchy`) However this system works great when all the records are given. Using a pager, some records are not used in the hierarchy, causing the outputted list to be incomplete. (ie if an activity A is in the first 40 and the child in the last 16, it will not be rendered correctly) Fix: --- Disabling the pager by setting a higher limit opw-4006610 Forward-Port-Of: odoo/enterprise#67979
This update fixes how Odoo calculates line discounts when importing Chilean invoices through email. Previously, Odoo would calculate discounts incorrectly, causing amounts to not match official records. The fix prioritizes the actual discount amount from the invoice file and now properly handles surcharges on line items, ensuring accurate financial records for Chilean businesses.
Original PR description
Before this PR: There are two problems: first, if you have a line discount like this: <img width="350" alt="Captura de pantalla 2024-03-27 a la(s) 09 48 55"…
Before this PR: There are two problems: first, if you have a line discount like this: <img width="350" alt="Captura de pantalla 2024-03-27 a la(s) 09 48 55" src="https://github.com/odoo/enterprise/assets/382893/7564b133-c6e9-4bab-97f3-d8a0a2634fe5"> The calculation made by Odoo is: 319319 * 21.35 / 100 = 68175 which does not match the amount placed in "DescuentoMonto". In this case, it is 68173 (difference of 2 CLP) which is why it is better to prioritize the discount amount instead of the percentage in the XML, which is already rounding, leading to a problem. The second: if you have a surcharge in the line, like this: <img width="354" alt="Captura de pantalla 2024-03-27 a la(s) 09 52 40" src="https://github.com/odoo/enterprise/assets/382893/5a7ffa96-a2d9-498f-acf3-7003c95aa789"> Odoo ignores it. After the PR: The first issue is fixed by giving priority to the "DescuentoMonto" tag. The second issue is added as an improvement. Since Odoo does not have a column to show the surcharge separated in the line, we are taking advantage of the feature that supports negative discounts in the line to put that surcharge as negative. Forward-Port-Of: odoo/enterprise#65842 Forward-Port-Of: odoo/enterprise#59532
Fixed an issue where the Spanish VAT Registro de IVA export button was appearing as the main action for all companies worldwide, regardless of their country. The button now only displays for Spanish companies, preventing confusion for users in other countries.
Original PR description
Before this commit, as soon as this module is installed, the button to generate the Libros Registro de IVA was the main button for all the companies. Instead of having a new handler, just add the code in the default handler, and manage the buttons based on the country of the current company.
Customers were receiving subscription renewal invoices twice—once with the standard template and again with the subscription-specific template. This fix ensures invoices are sent only once using the appropriate subscription template, improving the customer experience and reducing confusion.
Original PR description
When validating a payment for a subscription and the sale's setting `sale.automatic_invoice` is enabled, the invoice is send twice to the customer on subscription renewal; first with the normal…
When validating a payment for a subscription and the sale's setting `sale.automatic_invoice` is enabled, the invoice is send twice to the customer on subscription renewal; first with the normal template then a second time with the subscription specific template. To reproduce: - As Administrator: - Enable the "Automatic Invoice" option in the setting - Install/enable the `demo` payment provider and method - Log-in as `portal` user - Go the /shop and add the `Office Cleaning Service (SUB)` to you cart - Pay your order using the `Demo` payment method => The invoice is send once - Go to your subscription (/my/subscriptions) - Click on your new subscription - Scroll to the `Anticipate payment` section and pay for it (again choose the `Demo` payment method) - You get back the the subscription page, click on the last invoice (2nd invoice you created) => Scroll to the history section and see that the invoice is sent twice This commit ensure we're only sending invoice with the subscription specific template on renewal. OPW-3900040