Tuesday, April 16, 2024
34 changes
2 changes
Resolved issues and error corrections
This update prevents crashes when grouped data is sorted by date fields that include a period such as day or month. It makes reporting and grouped list views more reliable when using date-based sorting.
Original PR description
Before this commit, a mocked read_group with an orderby that contains a date field with granularity (day, month, ...) crashed because the granularity was not removed before looked up in the available fields. 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
Survey radio button questions that filter available choices now keep the original choice labels and order, including translated labels. This prevents users from seeing incorrect or untranslated options in filtered survey selections, such as recruitment surveys.
Original PR description
The "radio selection with filter" widget allows to show/hide some selection values given a list of allowed selection values. The feature is similar to the "filterable selection" widget but for radio buttons. The allowed selection context now takes a list of technical strings instead of a list of (technical string, humain string) pairs. This allow to keep the (possibly translated) original values along with the original selection order. task-3829801
23 changes
Resolved issues and error corrections
Fixed an issue where customers ordering through self-service QR menu on their phones encountered errors when validating orders. The problem was that the payment system wasn't properly initialized when the order was created, only when the cashier processed it. This fix ensures the payment system is ready from the moment the customer places their order.
Original PR description
Current behavior: When doing an order from self ordering on phone, there was an error because the fiskaly_uuid was not created directly when the user was creating the order. But it's created when the order is processed by the cashier. Steps to reproduce: - Setup fiskaly on your db (ask me if you need help) - Setup a pos to use QR Menu + payment in a DE company - Create an order from this PoS - Validate the order, you get an error opw-3773777
When creating a new appointment booking from the Gantt view, the system now automatically sets the start time to the current time (rounded to the nearest half-hour) instead of midnight. This makes scheduling more intuitive and saves users time by starting with a realistic default time.
Original PR description
Steps to reproduce =================== - Open Gantt view of any appointment. - Click on "New' to create a new booking. - The default start is set to today's midnight which is not relevant. After this PR ================== The current Time with rounded in half-hour format will be set as a default start while creating a new booking through the Gantt view. eg 10:10 => rounded to 10:30, 10:40 => rounded to 11. Task-3820387
Fixed an issue where subscription invoice previews displayed incorrect untaxed totals in the sidebar instead of the correct tax-included amount. This ensures customers and sales teams see accurate pricing information when previewing subscription invoices from the sales form.
Original PR description
Problem:
When clicking the preview stat button (1) from the sales forms view,
with a subscription product, the total amount displayed in the sidebar of the rendered document is wrong (untaxed),
(1) The amount is the correct total amount if the preview button is clicked from a draft invoice for the same order.
Desired:
The total dispalyed in the sidebar of the preview is **tax-included**.
opw-3822740The "Use on eBay" column position has been adjusted to match between the form and tree views in the eBay sales module. The column was moved to appear after the "Active" column to maintain consistency and keep related currency columns together, improving the user interface organization.
Original PR description
The column "Use on eBay" was located between "Unit per <currency>" and "<currency> per Unit" columns in the currencies tree view. It was therefore moved after the "Active" column, the same location it has in the form view. The columns "Unit per <currency>" and "<currency per Unit" should always be located next to one another. And the location of "Use on eBay" column should be consistent in both the form and tree views. task-3856386
Payment tokens created during SEPA Direct Debit transactions were not being properly linked to their source transactions. This fix ensures tokens are correctly associated with transactions, allowing subscriptions to save and reuse these tokens as recurring payment methods.
Original PR description
Payment tokens that are created when SEPA Direct Debit transactions are confirmed were not linked to those transactions. This prevented subscriptions from saving the tokens as recurring payment method because they could not be found through the payment transactions. opw-3756773 See also: - https://github.com/odoo/odoo/pull/161561
This fix resolves a critical error that occurred when restaurant staff zeroed out product quantities in POS orders before payment. The system was attempting a mathematical division by zero, causing the payment process to fail. The fix prevents this error by skipping the problematic calculation for items with zero quantity, allowing payments to process smoothly.
Original PR description
**Current behavior:** Adding a product to a POS order then zero-ing out the quantity of the line will result in an instance of division with this qty (now zero) in the denominator. **Expected…
**Current behavior:**
Adding a product to a POS order then zero-ing out the quantity
of the line will result in an instance of division with this qty
(now zero) in the denominator.
**Expected behavior:**
Don't allow a scenario to occur where 0 can appear in the
denominator of a division operation.
**Steps to reproduce:**
1. Switch to the demo German company installed with
`l10n_de_pos_res_cert`
2. Enable Fiskaly in the company settings for the German
company
3. Add a payment method in the POS config
3. Add a POS of type Restaurant and enable the TSS toggle
setting (comment out the `_l10n_de_fiskaly_iap_rpc()` call
in `l10n_de_pos_cert/models/pos_config.py` to save)
4. Add a floor and a table to the restaurant
5. Start a POS session and start an order, add some product
then select the order line and zero out the quantity with
the digital numpad
6. Go to payment -> register payment -> validate
7. Observe the error dialog
**Cause of the issue:**
In `l10n_de_pos_res_cert/models/pos_order.py`, the
`remove_from_ui` method calls `_line_differences()` if fiskaly
is setup for our German company which makes the call to
`_merge_order_lines()` where the following operation:
`str(group[0]['price_subtotal_incl']/group[0]['qty'])` may have
a denominator equal to 0.
**Fix:**
Do not call `_merge_order_lines()` on order lines which have a
quantity of zero.
opw-3751492
Forward-Port-Of: odoo/enterprise#60097This update resolves a technical issue affecting the point-of-sale receipt display for companies using Chilean localization. The receipt component was being incorrectly applied to all companies regardless of their location settings, causing system errors. The fix adds proper validation to ensure the Chilean-specific receipt customization only applies to companies that actually use Chilean localization.
Original PR description
The error was caused by the fact that the receipt component was wrongly overridden. There was no any check to see if the company was using the Chilean localization, so the error was raised. This commit fixes: [runbot/error#61720](https://runbot.odoo.com/web#id=61720&model=runbot.build.error), [runbot/error#61722](https://runbot.odoo.com/web#id=61722&model=runbot.build.error), [runbot/error#61723](https://runbot.odoo.com/web#id=61723&model=runbot.build.error), [runbot/error#61724](https://runbot.odoo.com/web#id=61724&model=runbot.build.error)
This fix resolves memory errors that occurred when exporting large financial datasets in XAF format. The update optimizes how data is processed and streamed, allowing users with large databases (millions of records) to successfully complete exports without system crashes.
Original PR description
Currently, on large databases (several million move lines), the XAF export can cause a `MemoryError`. The way to bypass this limitation is threefold: 1. Reduce memory usage during query results post processing. - First by removing the unnecessary `res_list`, and directly writing each batch in former `vals_dict`. - Second by updating former `vals_dict` instead of creating an additional (and useless) `values` dictionary. 2. Instead of rendering the entire file at once, the process is now divided in two steps: - Render the header first using Qweb (as before). - Generate the journals, moves and move lines manually. 3. Use a generator and stream the content of the file to the user, which will prevent having the entire dataset/file in memory. task-3816030 opw-3332771 Forward-Port-Of: odoo/enterprise#60609 Forward-Port-Of: odoo/enterprise#58612
A unit test for Argentine fiscal vouchers (bono fiscal) in the EDI module has been temporarily removed because the AFIP test environment has implemented new restrictions that require adaptation. The test will be restored once AFIP resolves the underlying issues on their end. This is a temporary measure to prevent test failures while waiting for the external system to be updated.
Original PR description
It is not working because some issues with AFIP test envrionment that added new restrictions that need to adapt- In this case we depend on AFIP to solve it and we do not know when we will have a solution. After everything is ok we will re add the test. Forward-Port-Of: odoo/enterprise#60577
A previous update changed the text of a customer-facing email template in the Helpdesk module. This fix updates the translation template file to reflect that change, ensuring all language translations stay synchronized with the current email content.
Original PR description
Commit 2740da2701557da09566aa25f064fe3cac7a881a modified a mail template's subject, which is translatable. Update the .pot file to reflect the change. opw-3748509
This fix resolves an issue in the Mexican EDI (Electronic Data Interchange) import tests where duplicate partner records were preventing proper customer identification during invoice imports. By removing conflicting demo data, the system now correctly identifies and matches customers when importing Mexican invoices (CFDIs), eliminating unnecessary duplicate customer creation.
Original PR description
When importing a CFDI, we try to retrieve the partner (see `_retrieve_partner`). If more than one partner is retrieved, the partners are not returned. During the `_l10n_mx_edi_import_cfdi_fill_partner` test, there exists two partners with the same VAT (one has a company_id, the other doesn't). Hence, when importing the bill, the `_retrieve_partner` will find 2 and will not return anything, and we end up creating a new partner. To fix that, we remove the VAT of the partner from the demo company. Thus, only one partner will be retrieved. opw-3829223 Forward-Port-Of: odoo/enterprise#60506
Fixed an issue in the Gantt chart view where connector arrows could start from incorrect positions when users moved their mouse very quickly during connector creation. The fix ensures connector arrows always begin from the exact point where the user initially clicked, providing a more reliable and predictable user experience. Additionally, corrected the CSS class assignments for right-to-left language layouts.
Original PR description
- Before: when you start the creation of a connector while going super fast (i.e. with a high DPI pointer device when you drank too much coffee or other energizing drink), you may end up with the connector arrow starting from any place.  - After: the arrow starts where you initially clicked, regardless of how fast you could move your pointer afterwards.  Forward-Port-Of: odoo/enterprise#60729 Forward-Port-Of: odoo/enterprise#60629
This fix corrects a bug where automated actions were being triggered when they shouldn't be. Specifically, when manually updating a record using a server action, automated rules that should only run on creation were incorrectly firing. The fix ensures the system properly distinguishes between creating new records and updating existing ones, preventing unwanted automated actions from executing.
Original PR description
Steps to reproduce: ------------------- [A] Create an automated action with: - Model: Tasks (project.task) - Trigger: On save - When updating: ID (to mimic "on_create" trigger) - Execute code: ```py…
Steps to reproduce:
-------------------
[A] Create an automated action with:
- Model: Tasks (project.task)
- Trigger: On save
- When updating: ID (to mimic "on_create" trigger)
- Execute code:
```py
record.message_post(body="This is a message from automated action (fields triggers: ['id'])")
```
[B] Create a server action (contextual action) with:
- Type: execute code
- Model: Tasks (project.task)
- code:
```py
record.write({})
```
[C] Test:
- create a new task --> message has been posted (OK)
- write some values on the task --> no message has been posted (OK)
- run the server action --> message has been posted (KO)
Issue:
------
No message should be posted as the ID field has not been modified.
Cause:
------
`if not self._context.get('old_values')` is considered as `True` because we have an empty dict.
In fact, when we make a write on a record, old_values will be always a dict.
```py
old_values = {
old_vals.pop('id'): old_vals
for old_vals in (records.read(list(vals)) if vals else [])
}
```
Solution:
---------
Old values are not defined in the context during a create. We can compare `self._context.get('old_values')` with `None` to differentiate between creating and writing on records.
opw-3736068This fix ensures that when a project template is copied (such as when creating a sales order with a project-based product), any sub-tasks are correctly assigned to the new copied project instead of remaining linked to the original template. This restores the correct behavior that existed in version 16.4, ensuring project copies maintain their proper task hierarchy and assignments.
Original PR description
### Steps to reproduce: - Create a project with a task with a sub-task - Assign manually the sub-task to the project - Create a product that creates a project based on this product template - Create…
### Steps to reproduce: - Create a project with a task with a sub-task - Assign manually the sub-task to the project - Create a product that creates a project based on this product template - Create an SO with that product #### > A copy of your project template will be created and assigned to the SO ### Expected Behavior: Just as in 16.4, the copy of the subtask created during this process should be associated with the copy of your project template. ### Current Behavior: The subtask is associated with the original project template. ### Cause of the issue/Fix: Confirming the SO will call the copy method on your project template. During this call copies of its task and sub-task will be created and should then be remapped to the correct project/task using by the `map_tasks` method call: https://github.com/odoo/odoo/blob/f31174e02157e612650e77ebba3ed1fe54b96776/addons/project/models/project_project.py#L436-L437 This use to do the job correctly in 16.4 because of these lines: https://github.com/odoo/odoo/blob/ce28edbaae5a9af0a8c6e1f2addf4285ec56e9e1/addons/project/models/project_project.py#L415-L419 However, these were removed by commit 6303a3e probably because the new write method of the "project.project" model introduced by this commit sometimes relies on the "project_id" of these tasks and this information should be consistent with the future value of the "project_id" of these tasks. However, the "project_id" of these tasks should still be remapped to the copied project at some point and in my opinion this should be done before the new write method is called, so that this method can be used correctly. opw-3823013 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed a bug in the Donation snippet where toggling off the "Pre-Filled Options" setting caused the website to crash. The issue occurred because the system tried to loop over an empty value, which is no longer allowed in the updated template system. The fix ensures the system handles empty donation options correctly without errors.
Original PR description
Steps to Reproduce : - Install eCommerce. - Drag and drop the "Donation" snippet. - Click on the prices in the snippet. - Toggle the "Pre-Filled Options" option. - => There is a traceback. This bug is due to the fact that since commit [1], all templates have been added to the OWL app. With OWL, a t-foreach in a template can no longer loop over a 0 number and causes an error if we try to. This is what happens here, as toggling off the "Pre-filled Options" option sets the donationAmounts to 0, which is then used in a loop in the templates. This commit fixes this by replacing the number by an empty array, so the loop cannot fail. [1]: https://github.com/odoo/odoo/commit/4703e4a2efa9213979307e4d3dedeedc61ad0fc3 task-3859207
This fix corrects the SEPA Direct Debit payment method configuration to properly support tokenization. Previously, the payment method was marked as non-tokenizable despite the system creating tokens automatically, which prevented it from appearing in subscription and payment management pages. This change ensures customers can now use SEPA Direct Debit for recurring payments and manage their payment methods through the portal.
Original PR description
The payment method's `support_tokenization` field was incorrectly set to `False` instead to `True`. This didn't prevent the SEPA Direct Debit provider from tokenizing this payment method because it always creates tokens when a payment transaction is confirmed. However, the payment method was not shown in payment contexts where tokenization is required (e.g., Subscriptions' portal page, /my/payment_method page). opw-3756773 See also: - https://github.com/odoo/enterprise/pull/60562
This fix resolves an issue where the Manufacturing Order Overview would crash when viewing orders with backorders in a two-step warehouse setup. The system now properly handles split orders and backorders by improving how it retrieves related purchase and stock information, ensuring a smoother user experience when managing complex manufacturing scenarios.
Original PR description
Steps to reproduce: - Set warehouse to two-steps reception - Create a BoM using a MTO (buy) component - Create a MO for 2 units of that BoM - Produce 1 and create a backorder - Open the Overview Issue: When there is a backorder (or if the MO is splitted), then when browsing the dests through `_rollup_move_dests()`, at some point it will branch into two differents path, related to each backorders. This will raise a traceback, as we only expected a single MO at that point. To avoid this, we made the `_rollup_move_dests()` method batchable, so we can fetch all moves linked to a manufacturing order in a single call, avoiding this issue. Note: For consistency sake, updated the `_rollup_move_origs()` method to be batchable as well, to avoid confusion when using one or the other. opw-3849252 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161537
A previous fix that added support for the Array 'at' method in older browsers had an unintended side effect: the method was appearing in loops that iterate over object properties. This update corrects that issue by properly hiding the method from these loops, ensuring the code behaves as expected without affecting application functionality.
Original PR description
Commit [1] introduced a fix for old browsers to make the `at` method of the Array class. It did so by simply adding a property on the prototype of the Array class. Unfortunately this way of adding a method means that it is exposed in `for...in` loops. To avoid this, this commit uses Object.defineProperty and sets the property as not enumerable, removing it from the for..in loop. [1]: https://github.com/odoo/odoo/commit/6e39e31030c28a8eb09ddcd93ca9ca382b4f6f10 opw-3824593
A test has been added to the Point of Sale application to ensure partial refunds of orders work correctly. This protects against regressions in refund functionality and maintains the reliability of the refunding process for retail operations.
Original PR description
This commit adds a test to protect the partial refunding of orders in the point of sale app. This commit is an annex of https://github.com/odoo/odoo/commit/59ffd20113b8d42aa2d7d91511c41804a08e01c6 . opw-3827876 Forward-Port-Of: odoo/odoo#161672 Forward-Port-Of: odoo/odoo#160929
This fix resolves an issue where users couldn't use the optional column feature in the Expense list view. The problem was caused by a code conflict that prevented the system from properly identifying the list view when users tried to customize columns. The fix ensures that custom styling can be applied without breaking the column customization functionality.
Original PR description
Since https://github.com/odoo/odoo/pull/120915 Steps: - Install `web_studio` and `hr_expense` - Open Expense/list view - click on optional column - Traceback The error occurs because the dropdown…
Since https://github.com/odoo/odoo/pull/120915
Steps:
- Install `web_studio` and `hr_expense`
- Open Expense/list view
- click on optional column
- Traceback
The error occurs because the dropdown needs the id of the view list in order to "hook" onto it. This unique id is added via a `t-att-class` here
https://github.com/odoo/odoo/blob/f8ac22e2ad0a8157466b9adeb3dd2746f1f011d9/addons/web/static/src/views/list/list_renderer.xml#L1-L7
and is used by the dropdown here
https://github.com/odoo/odoo/blob/f8ac22e2ad0a8157466b9adeb3dd2746f1f011d9/addons/web/static/src/views/list/list_renderer.xml#L45-L50
The problem here is that the hr_expense module inherits from `web.ListRenderer` to add some classes to `o_list_renderer` with this
```xml
<xpath expr="//div[hasclass('o_list_renderer')]" position="attributes">
<attribute name="t-att-class">'hr_expense h-auto o_forbidden_tooltip_parent'</attribute>
</xpath>
```
but by doing so, the t-att-class of `hr_expense.ListRenderer` overwrites that of `web.ListRenderer`.
One solution was to do as the documents application does
https://github.com/odoo/enterprise/blob/saas-16.3/documents/static/src/views/list/documents_list_renderer.xml#L5
This does not override the `t-att-class`
opw-3858726
Forward-Port-Of: odoo/odoo#161622Fixed a bug where loyalty program discounts were being applied based on total cart amount instead of only counting products that matched the discount's product requirements. Now, when you set a minimum purchase amount for a specific product in a loyalty discount, the system will only count purchases of that product toward meeting the minimum threshold, not the entire cart total.
Original PR description
Product domains were not considered when computing the min amount to reach to get a discount. For example, if you created a discount with a minimum amount of 100 for product "X", the discount would have been applied, even if the amount for "X" was less than 100, as long as the total amount of the SO was at least 100. After this fix, only products that match the domain will be considered when computing the amount that should be compared to the discount's min amount. opw-3626345 Forward-Port-Of: odoo/odoo#161927 Forward-Port-Of: odoo/odoo#155085
This fix resolves an issue where importing XML invoices in a multi-company environment would fail when trying to assign a partner from a different company. The system now correctly filters partners by the invoice's company during import, preventing incompatibility errors and allowing seamless cross-company invoice processing.
Original PR description
Bug: 1. Have at least 2 companies ("A" and "B") 2. Export an xml (Bis 3 for instance) for an invoice with customer "Azure Interior" 3. Set a company on "Azure Interior" (say: A) 4. Import the xml in…
Bug:
1. Have at least 2 companies ("A" and "B")
2. Export an xml (Bis 3 for instance) for an invoice with customer "Azure Interior"
3. Set a company on "Azure Interior" (say: A)
4. Import the xml in multicompany mode, with current company = B The partner "Azure Interior" should be retrieved, but when writing it on the invoice, it will throw a UserError "odoo.exceptions.UserError: Incompatible companies on records: 'Draft Invoice (* 63) (INV/2024/00006)' belongs to company 'B' and 'Partner' (partner_id: 'Azure Interior') belongs to another company."
Cause:
We try to write a partner on an invoice belonging to another company. It only occors when we have several companies selected because there is the global rule `base.res_partner_rule` that will add `('company_id', 'in', company_ids + [False])` to any search domain on the partner (`company_ids` is replaced by `env.companies.ids`, see `_eval_context`).
Fix:
Ensure any search domain contains `env.company.id`, or better: use the `company_id` of the move being created (but both should a priori be equivalent).
opw-3829223
Forward-Port-Of: odoo/odoo#161272
Forward-Port-Of: odoo/odoo#160147This fix corrects how analytic distributions are calculated when transferring accounts. Previously, the system would incorrectly use only the last line's distribution, creating inaccurate analytic balances. Now it properly calculates a proportional distribution across all transferred lines, ensuring accurate financial tracking and reporting.
Original PR description
To reproduce: - Create 2 lines with the same balance but only one has an analytic_distribution (of 100% on an analytic account). - Create a transfer of accounts for these => The counterpart has a distribution of 100% or no distribution. Indeed, we simply put the distribution of the last line. It makes no sense: analytic "balance" is generated and does not reflect the transfer move. We should make a prorata of the distributions of the lines to transfer. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160965