Tuesday, April 16, 2024
33 changes · 17.0
Resolved issues and error corrections
Fixes an issue where validating a receipt that included both subcontracted and regular products could incorrectly trigger a backorder warning after recording subcontracting components. Businesses can now complete the receipt as expected when the required quantities have been processed, reducing unnecessary workflow interruptions.
Original PR description
### Steps to reproduce: - Go to the settings and activate subcontracting - Create a storable product with Manufacture route and a BOM of type subcontracting - Create and confirm a PO for your…
### Steps to reproduce: - Go to the settings and activate subcontracting - Create a storable product with Manufacture route and a BOM of type subcontracting - Create and confirm a PO for your subcontractor with two lines: - a line with your subcontracted product - a line with any other storable product - Go on the associated receipt and set only one of the 2 lines as picked - Record components > add the desired quantity and record Production - Try to validate the transfer ### Expected behavior: Since the quantity is set on both lines, the transfer should be validated and both lines should be picked. ### Current behavior: A backorder wizzard appears and notifies you that you have processed less products than the initial demand. ### Cause of the issue: The picked field of the `stock.move` model is computed depending on the the picked state of its stock.move.line's: https://github.com/odoo/odoo/blob/1648ee1abff1ae12b3933baa85a2e048fa2eb557/addons/stock/models/stock_move.py#L206-L210 As such, recording the components for your subcontracted product will set the picked field of the associated stock move to True during the call of the `_update_finished_move` method: https://github.com/odoo/odoo/blob/1648ee1abff1ae12b3933baa85a2e048fa2eb557/addons/mrp_subcontracting/models/mrp_production.py#L72 https://github.com/odoo/odoo/blob/1648ee1abff1ae12b3933baa85a2e048fa2eb557/addons/mrp_subcontracting/models/mrp_production.py#L119-L121 Hence, since at least one of the stock move linked to our picking is picked, the other stock moves will not be set to picked = True here: https://github.com/odoo/odoo/blob/1648ee1abff1ae12b3933baa85a2e048fa2eb557/addons/stock/models/stock_picking.py#L1181-L1189 and the backorder process will be launched. ### Fix: Since the picked field of the stock move line is used in the call of the `_update_finished_move`: https://github.com/odoo/odoo/blob/1648ee1abff1ae12b3933baa85a2e048fa2eb557/addons/mrp_subcontracting/models/mrp_production.py#L144 we need to reset the picked status of the stock move after this call. However, since the `subcontracting_record_component` method is used in other flows for wich it is desirable to create a back order for the other stock moves, we can not reset the picked status of these moves in this method. As such, we decided to introduce a new method that will be called only in our flow. Note that the picked status of the related stock move lines will automatically be updated via the inverse compute method: https://github.com/odoo/odoo/blob/1648ee1abff1ae12b3933baa85a2e048fa2eb557/addons/stock/models/stock_move.py#L212-L214 #### Note: The picked field did not exist prior to 17.0. opw-3847825 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
This update corrects an internal logic issue in how credit limits are calculated for customer accounts. The fix ensures that company information is properly handled during the calculation process, improving the accuracy and reliability of credit limit determinations.
Original PR description
While in practice you would never get this inverse called with more than one record at a time, it is still wrong to get the company of self in the loop. Fixing it to keep good conscience :) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161815
The Greek VAT number format has been corrected to use the proper EL prefix (EL123456783) instead of the incorrect GR prefix. This ensures that Greek company VAT numbers are validated correctly in the system, preventing validation errors for Greek businesses.
Original PR description
According to https://www.easytax.co/en/countries/greece the vat number format for Greece is EL123456783 instead of GR12345670. We also delete the line for country code `el` from `_ref_vat` dict as we use `gr` for Greece. opw-3845662 Forward-Port-Of: odoo/odoo#161278
This update fixes a bug in the accounting system that was causing errors when processing custom taxes. The system now correctly handles tax mapping by focusing only on standard taxes from the core accounting module, preventing crashes when custom taxes don't follow the standard naming format. This resolves upgrade issues for affected customers.
Original PR description
Rewrite the mapping from xmlid to tax to only take into account standard taxes from the 'account' module
Related to blocking upgrade request [upg-1494099](https://upgrade.odoo.com/web#id=1494099&model=upgrade.request)
If there is a custom tax created by the user with a external id that doesn't contain '_', the mapping fails.
Traceback:
```
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 280, in <dictcomp>
xml_id.split('.')[1].split('_', maxsplit=1)[1]: self.env['account.tax'].browse(record)
IndexError: list index out of range
```
Only standard taxes (from `account` module) should be taken into account.
Forward-Port-Of: odoo/odoo#161877This update removes a duplicate styling class that was appearing twice in the Record Selector component, which could cause inconsistent styling behavior. By cleaning up this duplication, the component now applies styles more predictably and reliably, improving the overall user interface consistency.
Original PR description
This commit removes the unnecessary duplicate of the 'o-input' class being present in the template of the (Multi)RecordSelector components. As the RecordAutocomplete component uses the Autocomplete component, which already set this classname on its <input> node, the class was present twice in the DOM. This could affect the style when trying to write a rule on .o_input since both elements would get the style. Now, only the input keep the class, which makes things easier and more predictable.
Fixed a bug where the powerbox menu (used in the Notes app) would continuously grow in size when navigating with arrow keys in right-to-left languages like Arabic. The fix ensures the powerbox displays at its correct size immediately by properly calculating its width before positioning, improving the user experience when using the editor in RTL languages.
Original PR description
Issue: ====== The powerbox keep increasing in size when you input. Steps to reproduce the issue: ============================= - Install arabic - Go to notes - write `/`, you can see the powerbox is…
Issue: ====== The powerbox keep increasing in size when you input. Steps to reproduce the issue: ============================= - Install arabic - Go to notes - write `/`, you can see the powerbox is a bit smal - use `down/up`arrows to navigate in the powerbox. - The powerbox width increase until finally gets to it's intended position. Origin of the issue: ==================== Since we are providing that `marginRigh` should be equals to `20` in `getRangePosition` we will move the powerbox to the left a bit and then with the style property `max-width=100%` it will increase in size because the current size is a bit small for it. So at every key pressed it will increase by 20px until it gets to a point where everything is set and the `marginRight=20` is finally visible. Soltuion: ========= We set min-width as max-content so we can position correctly the powerbox knowing it's final width. task-3721794 Forward-Port-Of: odoo/odoo#161089 Forward-Port-Of: odoo/odoo#157668
This fix prevents database constraint records from being accidentally deleted when modules are loaded. The system now properly preserves existing constraint data that was previously being removed due to a technical oversight in how constraints are tracked during the module loading process.
Original PR description
When we load a module and the SQL constraints exist both in the table and in `ir_model_constraint` we need to ensure the xmlid is loaded. Otherwise the record in `ir_model_constraint` is removed. Since 4c9968397b0714bc90a9c94c4673bd3148db4010 we skip returning existing non-updated constraint records in `_reflect_constraint`. This leads to them being removed by the ORM. At the end of the load the ORM sees the record in `ir_model_data` but not in the xmlid pool, thus it removes it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161893
This update corrects a bug where column visibility settings were being incorrectly overwritten in the language management interface tree view. The fix ensures that column visibility preferences are properly preserved and displayed as intended, improving the user experience when managing language configurations.
This fix resolves an error that occurred when customers selected a Mondial Relay pickup location during checkout and then reloaded the page. The system was incorrectly trying to validate mandatory fields (like phone number) on Mondial Relay addresses, which cannot be edited. The fix removes this validation check for Mondial Relay partners, allowing customers to complete their checkout process without errors.
Original PR description
Steps to reproduce: 1) Set up mondial relay and publish it 2) Go to /shop, add a product and checkout 3) Choose a pickup location of mondial relay 4) Reload the page 5) Observe an error 'You cannot edit the address of a Point Relais' Reason: a partner was created without mandatory field 'phone` for the shipping address Solution: do not check mandatory fields for mondial relay partners as it is not allowed to edit them
A performance test for the website blog module was causing random failures and wasn't providing meaningful results. This update removes the problematic test to improve system reliability and reduce false test failures.
Original PR description
Since [this commit], the `test_10_perf_sql_blog_standard_data` test failed randomly. As testing sql perf for website without cache doesn't really make sense (as explained in [this other commit]) we can can just remove the test without cache. [this commit]: https://github.com/odoo/odoo/commit/88b016fdc407e318c43c96df9b582853512f04fa [this other commit]: https://github.com/odoo/odoo/commit/dad8dca0da23143eb2f28debde5139e907368a2e runbot-55755