Tuesday, April 16, 2024
21 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-3822740Payment 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 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)
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 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
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#161877Fixed 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 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