Daily updates from Odoo
Monday, December 2, 2024
30 changes
21 changes
Resolved issues and error corrections
The To-Do app chatter panel now stays within its intended area when activities contain long descriptions. This prevents the page layout from stretching unexpectedly, making the interface easier and more reliable to use.
Original PR description
Steps to Reproduce: - Open the To-Do app and click on the chatter icon. - Create an activity with a long description. - As the description increases, the chatter expands beyond its intended area. Issue: - The chatter did not have a fixed length, causing it to expand with long descriptions . After PR: - The chatter section now maintains a consistent fixed size. task-4256985 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When tasks or applicants are created by email, stage update messages now include the original sender instead of incorrectly excluding them as the message author. This ensures customers, portal users, or applicants receive expected status notifications after their email creates a record.
Original PR description
The issue occurs when an email is sent to create a `project.task`. If the sender of the email is an existing user, this user is later set as the author of any outgoing emails related to that task. Since the system is configured to skip sending emails to the author, no email is delivered to the sender in this scenario. Reproduce --- - -i project,contacts - add `example.com` to domains in the settings - create new project with an alias: `project@example.com` - Have a stage with some "Email Template" set - send email creating project tasks as a portal user - BUG: email about stage update is NOT sent (even tho task appeared in stage) opw-3941928
The screen sharing icon in Odoo Discuss now turns green when screen sharing is active. This makes it easier for users to quickly confirm that their screen is being shared during a call.
Original PR description
Current behavior before PR: The screen share icon did not reflect any change when screen sharing was active Desired behavior after PR is merged: The screen share icon now turns green to indicate that screen sharing is active --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale product options are now easier to select because the option text works together with the radio button. This improves accessibility and makes configuration smoother for cashiers and other users.
Original PR description
Description of the issue/feature this PR addresses: Ensures proper association between `<span> `elements and corresponding `<input>` elements by making the `<span> `act as a label for better accessibility and user experience. Current behavior before PR: The `<span>` displaying the attribute name is not linked to the corresponding `<input>` radio button. Users must click the radio button itself to select an option. Desired behavior after PR is merged: The `<span> `acts as a clickable label for the corresponding `<input>` radio button, allowing users to click either the text or the radio button to select an option. This improves accessibility and enhances the user experience. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update simplifies the Jordan e-invoicing process by removing an unnecessary repeated processing step. It does not change how invoices are sent, but makes the code easier to understand and maintain, reducing the chance of future mistakes.
Original PR description
The method _l10n_jo_edi_send always expects a single invoice. Therefore, the loop over the recordset makes no sense, and is misleading to whoever reads the code. task-3895493 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix stops embedded action data from carrying over when users open a normal action from an embedded one. It prevents the wrong action bar from appearing and avoids crashes caused by using records from the wrong business object.
Original PR description
Before this commit, when executing a regular action from an embedded one, the context wasn't cleared, so all the embedded action feature related keys were propagated to the regular action. As a consequence, the embedded actions bar was displayed on that action as well. Clicking on an item most certainly led to a crash, because a wrong active id (referring to anothe res_model) would be used. For instance 1) Go to Project 2) Open "AGR - S00080 - Sales Order" 3) Add Sales order embedded action 4) Click Sales order 5) Enter a sales order that has tasks or a service product 6) Click the Tasks smart button 7) The embedded actions bar is displayed and, it crashes if an item is clicked opw~4253958 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
OAuth login routes are no longer treated as read-only because they may need to create a user account or record a login event. This prevents failed sign-ins caused by the system blocking required database updates during authentication.
Original PR description
Follow-up of #186319 and #186786 These routes are auth=none but aren't technically read-only, as they can create the user record and need to record the login event anyway. The signin one even as a broad catch for Exception, which would prevent the readonly->read-write fallback to work, leading to a failed login.
Message tracking updates now correctly display the word 'none' when that is the intended value. This prevents blank entries in message histories, making changes clearer for users reviewing updates.
Original PR description
Previously, in the mail message body, setting any tracking value to 'none' would result in an empty value instead of showing 'none'. This commit addresses the issue, ensuring 'none' is displayed as expected. Task-4282534
Invoices now correctly account for online down payments that were made before the invoice existed, even when those payments do not create accounting journal entries. This prevents customers from being asked to pay more than the actual order total and keeps invoice and portal payment displays accurate.
Original PR description
Steps to reproduce: - Install sign; account; sales - Payment Providers > Enable Demo - Sales app > New Quotation > Other Info tab > Online Payment: 50% - Preview > Sign and pay > Make the 50% down…
Steps to reproduce: - Install sign; account; sales - Payment Providers > Enable Demo - Sales app > New Quotation > Other Info tab > Online Payment: 50% - Preview > Sign and pay > Make the 50% down payment - Back to SO > Create invoice > Regular invoice > Confirm > Preview Coupled with https://github.com/odoo/enterprise/pull/74108 The down payment amount is not deducted from the invoice, meaning we essentially force the customer to pay 150% of the total price. This is a by-product of the rework 01b87f1230beac0568f4e3b1b76e547909506892 which made the creation of journal entries optional, on which the invoice was previously dependant to track existing payments. Since the first payment here is made before any invoice is created, we want to create a separate payment with no associated journal entry (See the rework commit for more details on why we would want to do that, but in short we don't necessaily want to track payments that could be cancelled, etc...). However the matched_payment_ids on the invoice we create afterwards is not updated correctly, and above all the field is not taken into account by many views and functions which still assume there will be a corresponding account_move. This fix mostly aims to recompute the amount_residual of the invoice since that is the source most places draw from, and to reestablish the customer displays to prevent excessive payments from being made. To avoid disturbing other functions which could depend on the edited method payment_content is being kept separate (Not all fields are available without an account move so we would risk accessing missing fields unexpectedly by mixing them with regular move lines. opw-4208717 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents payment post-processing from failing when a journal has more than one payment method line. It helps ensure online or point-of-sale payments can complete reliably instead of being blocked by a configuration-related error.
Original PR description
Currently, an exception is generated at the time of the post-processing payment transaction. error: ``` ValueError: Expected singleton: account.payment.method.line(11, 12) File…
Currently, an exception is generated at the time of the post-processing payment transaction.
error:
```
ValueError: Expected singleton: account.payment.method.line(11, 12)
File "addons/payment/models/payment_transaction.py", line 852, in _cron_post_process
tx._post_process()
File "addons/pos_online_payment/models/payment_transaction.py", line 29, in _post_process
super()._post_process()
File "addons/website_payment/models/payment_transaction.py", line 14, in _post_process
super()._post_process()
File "addons/sale/models/payment_transaction.py", line 91, in _post_process
super(PaymentTransaction, done_tx)._post_process() # Post the invoices.
File "addons/account_payment/models/payment_transaction.py", line 122, in _post_process
tx.with_company(tx.company_id)._create_payment()
File "addons/account_payment/models/payment_transaction.py", line 163, in _create_payment
'payment_method_line_id': payment_method_line.id,
File "odoo/fields.py", line 5287, in __get__
raise ValueError("Expected singleton: %s" % record)
```
The above exception was generated because we got multiple payment method lines in a single journal.
This commit fixes the above issue by accessing the first payment method line.
sentry-6007333118Employee remaining leave balances now exclude time off types that are hidden from the dashboard. This prevents employees and managers from seeing inflated or confusing leave totals based on leave categories that should not be displayed.
Original PR description
This commit excludes the time off types which are hidden from dashbaord in the count of employee's remaining leaves. task-4268945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
New databases now include a second default follow-up reminder level, so overdue invoices can receive a gradual sequence of reminders instead of only one. Demo cleanup also prevents deleted snailmail follow-up records from being recreated during module updates.
Original PR description
The second level already configured in demo has been moved in data because having only one follow-up level in a new database is a bit weird. Not only does it look weird, but in practice it also leads to a weird situation that by default the invoices will only be reminded once and never after. + we're failing to convey the usefuleness of the feature of building gradually harded reminders for the partner. Also added forcecreate="False" in snailmail demo data, because we don't waznt to recreate the missing xml ids (if people deleted it) in every module's update. task-4334758
Project managers can now create document folders from project settings without hitting an access error in demo scenarios. Project document links also open the more useful folder document view, making it easier to manage centralized project documents.
Original PR description
Commit 1: Reproduce: 1. Open a project's settings as Admin/Demo (project managers) 2. Make sure "Use Documents" is checked 3. Try quick creating a folder 4. Access Error This occurs because you are not allowed to create in the restricted "Projects" folder. This commit adapts demo data so that flows can easily be demonstrated and tested without requiring extra configuration steps for a common flow. Commit 2: Quick create folders instead of requests to centralize projects' documents. Also, the `documents_folder_many2one` widgets links to the documents kanban view of the folder instead of the less useful form view, as it is done in the other apps and bridges. Task-4344434
This update fixes several issues in Documents, including preventing employees from being automatically granted access to employee-related documents, improving the My Documents and Shared With Me filters, and avoiding crashes when shortcuts point to inaccessible files. It also reduces clutter from frozen spreadsheet folders in Home, making document navigation faster and clearer for users.
Frozen shared spreadsheets are now excluded from the list of available spreadsheets when inserting pivot data. This prevents users from selecting spreadsheets that should no longer be edited, reducing confusion and avoiding failed or inappropriate updates.
Original PR description
Steps to reproduce: - create a spreadsheet - Freeze and Share this spreadsheet - go to a pivot view and hit "Insert in spreadsheet" => the frozen spreadsheet is included in the dialog Task: 4353076
This fix updates the website shop rental flow so unavailable dates are identified more accurately during checkout tests. It helps prevent errors when customers choose rental dates, reducing the risk of blocked or confusing purchase flows.
Original PR description
The previous fix (odoo/enterprise#74860) was incomplete as out of range date also have the .o_date_item_cell class. Runbot Error 108371
This corrects the translation configuration for the FedEx delivery integration. It helps ensure translation updates are managed properly, with no expected change to day-to-day user workflows.
The point of sale quantity control now correctly changes a product quantity to a negative value when the +/- button is pressed. This prevents unexpected zero quantities and supports more accurate adjustments such as returns or corrections.
Original PR description
Before this commit ------------------------ Previously, when adding a product and clicking the "+/-" button, the quantity would change to "0" instead of becoming negative. After this commit ---------------------- After implementing this commit, pressing the +/- button now results in the quantity value changing to negative instead of changing it to 0. task- 4281516 Related PR: https://github.com/odoo/odoo/pull/185441/
Invoices now correctly account for online down payments made before the invoice exists, even when those payments do not create accounting journal entries. This prevents customers from being asked to pay more than the actual order total and keeps invoice payment information accurate.
Original PR description
Steps to reproduce: - Install sign; account; sales - Payment Providers > Enable Demo - Sales app > New Quotation > Other Info tab > Online Payment: 50% - Preview > Sign and pay > Make the 50% down…
Steps to reproduce: - Install sign; account; sales - Payment Providers > Enable Demo - Sales app > New Quotation > Other Info tab > Online Payment: 50% - Preview > Sign and pay > Make the 50% down payment - Back to SO > Create invoice > Regular invoice > Confirm > Preview Coupled with https://github.com/odoo/odoo/pull/185645 The down payment amount is not deducted from the invoice, meaning we essentially force the customer to pay 150% of the total price. This is a by-product of the rework 01b87f1 which made the creation of journal entries optional, on which the invoice was previously dependant to track existing payments. Since the first payment here is made before any invoice is created, we want to create a separate payment with no associated journal entry (See the rework commit for more details on why we would want to do that, but in short we don't necessaily want to track payments that could be cancelled, etc...). However the matched_payment_ids on the invoice we create afterwards is not updated correctly, and above all the field is not taken into account by many views and functions which still assume there will be a corresponding account_move. This fix mostly aims to recompute the amount_residual of the invoice since that is the source most places draw from, and to reestablish the customer displays to prevent excessive payments from being made. To avoid disturbing other functions which could depend on the edited method payment_content is being kept separate (Not all fields are available without an account move so we would risk accessing missing fields unexpectedly by mixing them with regular move lines. opw-4208717
WhatsApp conversations that have been inactive are now automatically unpinned after 5 days instead of 2 weeks. This helps prevent teams with high WhatsApp message volumes from hitting conversation limits that can slow down Discuss.
Original PR description
Follow-up of https://github.com/odoo/enterprise/pull/74131 PR above attempts to solve an issue of every-growing unpinned whatsapp conversations that make it harder to use Discuss for performance reasons, due to reaching the technical limit of around 2000 pinned conversations. To do so, it automatically forces unpinning whatsapp conversation after 2 weeks of inactivity, even if the conversation was unread. While this is an improvement, if there are around 150 whatsapp new whatsapp conversations made every day, then the 2 week force unpin is not enough, because the 2000 pinned conversation limit is reached. This commit fixes the problem by reducing the force unpin of whatsapp conversation to 5 days. The architecture of Discuss should scale better, but this is hardly achievable in short manner, hence why the current solution to this problem is prevent reaching a high amount of pinned conversations. opw-4330847
Appointment notifications in the chatter no longer show unwanted extra spacing. This makes messages look cleaner and easier to read without changing appointment behavior.
Original PR description
Purpose of this commit: This commit resolves an issue in the appointment module where system notifications in the chatter were displaying with unnecessary padding in the message body. Before  After  task-4291913
9 changes
Resolved issues and error corrections
This update resolves a bug that prevented users from selecting the 'id' field when creating global filters within the spreadsheet edition of Odoo. Previously, this functionality was limited to relational filters. This change ensures consistent filter options for all users, improving data selection and reporting.
Original PR description
Steps to reproduce: - Insert a pivot from CRM - Create a global filter, with type date or text => The id field can be selected With this commit, field `id` is now available only on relational global filters. Task: 4348477
This update fixes a bug where the POS system would unexpectedly start clocking in users even if a cashier wasn't selected. The change ensures a cashier is selected before clocking in, preventing errors and ensuring the POS remains usable. This improves the overall reliability of the Point of Sale experience.
Original PR description
Behavior before commit: When opening the POS and selecting a cashier, if the user decides to go back without selecting any cashier, the clock-in function gets called anyways. This leads to pos_blacbox trying to clock in an undefined cashier, which in turn leads to more errors down the line (including an unusable pos). With the modification proposed in this commit, we check that a cashier has indeed been selected and only then proceed with the clocking in. opw-4293988 opw-4182434
This update corrects a problem where multiple cancellation requests for Mexican tax documents (CFDI) could lead to errors. When a customer rejects a cancellation, a new cancellation request is created. When the SAT approves the second request, the original cancellation request is automatically removed, preventing data inconsistencies. This ensures accurate tax reporting and avoids potential issues with the Mexican tax authority.
Original PR description
In a production setup: - Create an invoice and sign it - Ask for a cancellation rejected by the customer => an invoice_request_cancel document is created - Ask for another cancellation request => another invoice_request_cancel document is created - Trigger the SAT to approve the second cancellation request => The first invoice_request_cancel document is unlink.
This update resolves issues with Mexican CFDI invoice generation related to rounding calculations. Specifically, it corrects an error in how taxes are calculated during global invoice creation, ensuring compliance with Mexican tax regulations. The fix improves the accuracy of CFDI invoices for Mexican businesses.
Original PR description
## Steps to reproduce the issue 1. Activate Mexican Localization 2. In Mexican Company, create two Invoices with one product line: - Price Unit of 3.47, 16% Tax - Activate CFDI to Public 3. Select…
## Steps to reproduce the issue
1. Activate Mexican Localization
2. In Mexican Company, create two Invoices with one product line:
- Price Unit of 3.47, 16% Tax
- Activate CFDI to Public
3. Select both Invoices and create Global Invoice ("Actions" drop menu)
4. Check the CFDI tab in one of the Invoices
5. One of those errors pops up depending on your rounding method:
#### Round per line:
> Code : 301
> Message : Error de validaciones adicionales [Error #CFDI40108] El TipoDeComprobante es I,E o N, el importe registrado en el campo no es igual al redondeo de la suma de los importes de los conceptos registrados. Folio: 2. Serie: GINV/. El valor del atributo SubTotal (6.95) no coincide con la suma de los importes (3.47 + 3.47 = 6.94)
#### Round globally:
> Code : CFDI40205
> Message : El valor del campo TotalImpuestosTrasladados no es igual a la suma de los importes registrados en el elemento hijo Traslado.
## Explanation
#### Round per line:
With commit odoo/enterprise@933864a38af21a70b219d2824c64fff488acb15f, base and tax amounts were tweaked in order to satisfy some CFDI constraints. This change calculates amounts in an incorrect order: instead of calculating `tax_amount` with the formula `base_amount * tax_rate`, it calculates the base using `total / (1 + tax_rate)` then subtracts the base from the total to obtain the tax amount.
In our example, with a total of `6.94 + 1.12 = 8.06`, the base is calculated as such: `8.06 / 1.16 = 6.94827586207`, rounded to `6.95`, and the tax as such : `8.06 - 6.95 = 1.11`. The difference between the tweaked base `6.95` and the addition of the base of all invoice lines `3.47 + 3.47 = 6.94` is not accepted.
#### Round globally:
During a Global Invoice creation, we will first calculate the values of the Invoices separately. During this calculation, `total_impuestos_trasladados` is rounded with `precision_digits=2` while values in `traslados_list` are rounded with `precision_digits=6`. https://github.com/odoo/enterprise/blob/800378bfd3fe198647c9b418def3bd36066d9cd7/l10n_mx_edi/models/l10n_mx_edi_document.py#L583-L590 https://github.com/odoo/enterprise/blob/800378bfd3fe198647c9b418def3bd36066d9cd7/l10n_mx_edi/models/l10n_mx_edi_document.py#L950-L961 https://github.com/odoo/enterprise/blob/800378bfd3fe198647c9b418def3bd36066d9cd7/l10n_mx_edi/models/l10n_mx_edi_document.py#L963-L964 https://github.com/odoo/enterprise/blob/800378bfd3fe198647c9b418def3bd36066d9cd7/l10n_mx_edi/models/l10n_mx_edi_document.py#L1000-L1001
In the example, `3.47 * 0.16 = 0.552`, is rounded to `0.56`. The addition of every rounded value gives `1.12` or `1.110400`, which gives the difference between `total_traslados_impuestos` and `traslados_list`.
## Fix reasoning
#### Round per line:
We will add a hack in `_get_post_fix_tax_amount_map`: CFDI accepts a difference of `1e-<precision_digits>`, which means that `precision_digits=2` would allow a difference of `0.01`. If the difference is lower, we will not perform the operation and only round the values.
In our example, the obtained tax amount is `1.12` and the expected tax amount `6.94 * 0.16 = 1.1104`. The difference between the two is lower than `0.01` and is accepted by the CFDI.
#### Round globally:
We will use the calculated values in `_get_global_invoice_cfdi_values` to compute the total price and totals of taxes at the end of the method instead of using the rounded values received from `cfdi_values_list` at the start.
opw-4085403This update fixes an issue with Odoo's report engines, specifically the account_codes engine, that caused incorrect data display when using LIMIT and OFFSET. The fix ensures consistent behavior across report types by adding an explicit ORDER BY clause, addressing a PostgreSQL requirement for reliable LIMIT/OFFSET functionality. This resolves data discrepancies and ensures accurate report results.
Original PR description
[FIX] account_reports, l10n_*_reports: add explicit ORDER BY to report engines for consistent LIMIT and OFFSET behavior As stated here https://www.postgresql.org/docs/current/queries-limit.html ,…
[FIX] account_reports, l10n_*_reports: add explicit ORDER BY to report engines for consistent LIMIT and OFFSET behavior
As stated here https://www.postgresql.org/docs/current/queries-limit.html , postgresql requires an explicit ORDER by within the query for LIMIT and OFFSET to work properly and consistently between query executions. We hence add one to each engine not having one already.
=======================================
[FIX] account_reports: properly handle groupby in account_codes engine for grouping keys used with multiple accounts
// TO REPRODUCE
1) Create a report with a single line, whose computation uses the account_codes engine, with formula "1". Set "partner_id" as the groupby value for that line. Setup a "load more limit" of 2 on your report.
2) Create 3 accounts, with codes 11, 12, 13
3) Create 3 partners: A, B, and C
4) Create journal entries, with the following lines (all balancing lines must use other accounts as the ones defined in 2) ), in that order:
- on account 11, with partner A, debit=10
- on account 11, with partner A, debit=20
- on account 12, with partner A, debit=25
- on account 11, without partner, debit=30
- on account 11, without partner, debit=40
- on account 12, with partner B, debit=50
- on account 13, with partner C, debit=60
5) Open the report for a period covering all the created journal entries, and have a look at the sublines generated for the groupby.
=> With the limit being 2, you'd expect to see "A", "B", and a "Load more..." line allowing to visualize the rest (namely a line for "C", and "Unknown"). Instead of that, you see no "Load more ...", and line "A"'s amount is wrong.
// EXPLANATION
The SQL query of the account_codes engine is grouping not only by groupby key (here, partner_id), but also by account_id, to be able to process the "C" and "D" suffixes of the formula later on. Because of that, the LIMIT passed by the load_more_limit is applied on that grouping.
With a load_more_limit of 2, we try to load 3 lines. If we manage to load 3, we only display 2, but know we need to display the "Load more..." line. Else, we know there are no more results, so no need for that additional line.
So, with our example, the query runs with a LIMIT of 3, returning
- 30 for A on account 11
- 25 for A on account 12
- 70 for no partner on account 11
Then, another issue happens:
The results returned by the SQL query (hence, by the engine) contain two times the same partner_id. From an engine perspective, the grouping key is only partner_id, not account_id (which is only used for an inner computation, with the SQL query). So that means the same grouping key has two different values. This is not legit, and causes one of them to shadow the other.
The report computation then receives 1 result for A, and 1 for "Unknown", so it renders them, and since there is no third result, it does not display the "Load more ...".
Forward-Port-Of: odoo/enterprise#74784This update optimizes the performance of reports displaying large amounts of asset data. By passing currency and expression values directly, the system avoids redundant data retrieval, resulting in faster report generation. This change significantly reduces processing time, especially with a large number of assets.
Original PR description
### Description When opening a report with a lot of data to display, getting some values can be very costly. In this case, for the depreciation schedule, we are retrieving the column expression and currency symbol each time if not found in `_build_column_dict`. To avoid retrieving a value that was already fetched, we can pass the currency and the expression directly. This reduces unnecessary `__get__` calls. ### Benchmark (made in 17.0) | N° of assets | Before | After | |--------------|---------|--------| | 500 | 2 s | 1.55 s | | 7k | 20 s | 19 s | | 17k | 50 s | 41 s | ### Reference opw-4287192
This update resolves a bug preventing the correct rendering of event templates when using sale templates in event communication settings. The fix corrects a misconfiguration in how the system searches for templates, ensuring compatibility with both event and sale templates. This improves the reliability of event communication workflows.
Original PR description
Current behaviour: --- When setting mail templates in the communication tab of an event, you initially only see event templates, unless you click on "Search more ..." which allows you to set…
Current behaviour: --- When setting mail templates in the communication tab of an event, you initially only see event templates, unless you click on "Search more ..." which allows you to set non-event templates. Expected behaviour: --- Only seeing/and being able to set event templates Steps to reproduce: --- 1. Install event_sale 2. Go to Events, pick an event 3. In the communication tab, remove all templates 4. By clicking on "Search more ..." add a sale template 5. Set as Immediately and After each registration 6. Click on the smart button "Attendees" 7. Create a new attendee with an email then save 8. You may need to create multiple attendees 9. Failed to render inline_template template Cause of the issue: --- When selecting a sale template, the render model is `sale.order` So when passing the registration id to get rendered, it tries to read this id on a `sale.order`, causing an error if a `sale.order` with this id doesn't exist. Caused by: https://github.com/odoo/odoo/commit/6abd149259e9caf815fe1804f1322f623f8fcb50 `_name_search` was overriden, but the "Search more ..." option doesn't used `_name_search` but `web_search_read` Fix: --- Overrode `_search` instead opw-4106237
This update fixes an issue where sales order line subtotals were incorrectly displaying tax-included prices when orders were synchronized from Amazon with Avatax. The change ensures that the subtotal accurately reflects the amount before tax by intentionally excluding the Amazon's tax information, which Avatax is best positioned to handle.
Original PR description
When synchronizing orders from Amazon with Avatax enabled, sales order lines currently show no taxes and incorrectly set the tax included price as being the subtotal. This occurs because the fiscal position used does not include any tax, which is the expected behavior for Avatax. The recomputation then uses the full amount of the line (which is tax included), and in the absence of tax, consider this is also the subtotal. We now intentionally do not consider the tax amount from Amazon on the order lines, because the distribution of the Amazon's given tax amount is unknown. The multiple real taxes across that line is not an information that Amazon gives us, and needs to be seen from Avatax. This setup ensures that the subtotal on sales order lines remain accurate. opw-4214775
This update resolves a bug that prevented the 'sign-up tour' from running correctly when the Odoo application was launched with only one app installed locally. The fix ensures the tour functions as expected in this common development scenario, improving the user experience for developers. This change does not impact any business functionality.
Original PR description
When the tour is running in single app locally, it is failing