Wednesday, April 17, 2024
32 changes · saas-17.2
Resolved issues and error corrections
This update prevents receipt print requests sent through IoT hardware from returning the same status response used for standard reports. This helps keep receipt printing flows working correctly and avoids issues where the system cannot retrieve the print identifier.
Original PR description
From this commit 7a593d6cc5c6bde8fe197dc2c7775d10111fa7c7 when we send a receipt to the iot it is impossible to get the print_id In this commit we return the status of the printing only if it is a default Printing request, not a receipt request 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
Miscellaneous changes
Versions -------- - saas-16.3+ Steps ----- 1. Set timezone of User and browser to America/Los_Angeles; 2. go to Time Off; 3. click on calendar to create a new leave. Issue ----- Date defaults to the day before the selected date. Cause ----- Commit 0a0c6917b5e21e829e14ad271de6e2117e4a7126 added a TZ conversion in JS to add default start & end times for leaves. The issue is that it assumes the context values are always datetime strings, therefore always using `deserializeDateTim
Original PR description
Versions -------- - saas-16.3+ Steps ----- 1. Set timezone of User and browser to America/Los_Angeles; 2. go to Time Off; 3. click on calendar to create a new leave. Issue ----- Date defaults to the…
Versions
--------
- saas-16.3+
Steps
-----
1. Set timezone of User and browser to America/Los_Angeles;
2. go to Time Off;
3. click on calendar to create a new leave.
Issue
-----
Date defaults to the day before the selected date.
Cause
-----
Commit 0a0c6917b5e21e829e14ad271de6e2117e4a7126 added a TZ conversion in JS to add default start & end times for leaves. The issue is that it assumes the context values are always datetime strings, therefore always using `deserializeDateTime`, which does a timezone conversion from UTC to local time, which is incorrect when the context values are date strings.
For a UTC-7 zone like America/Los_Angeles, it deserializes a date string like `'2024-01-01'` to `'2023-12-12 17:00:00'` (7 hours before midnight). It then sets the start hour to 7, and serializes it back to UTC, adding 7 hours, resulting in `'2023-12-12 14:00:00'`. Instead, Jan 1, 7 AM in America/Los_Angeles should convert to `'2024-01-01 14:00:00'` UTC.
Solution
--------
Use `deserializeDate` instead of `deserializeDateTime` when the `default_date_{from,to}` in the context is a date rather than a datetime. This way, `'2024-01-01'` gets deserialized into `'2024-01-01 00:00:00'` local time. When this value gets used for the default hours, `'2024-01-01 07:00:00'` local time will get serialized to `'2024-01-01 14:00:00'` UTC as expected.
opw-3757712
Forward-Port-Of: odoo/odoo#161838Forward-Port-Of: odoo/odoo#162050
Original PR description
Forward-Port-Of: odoo/odoo#162050
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
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-3736068
Forward-Port-Of: odoo/odoo#155832This 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#161905 Forward-Port-Of: odoo/odoo#160929
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#161905 Forward-Port-Of: odoo/odoo#160929
Steps to reproduce the issue: ---------------------------- 1. Enable dark mode 2. Go to Project app 3. Create a new project 4. Click on `See examples` in the kanban 5. Select an example. Actual Behavior: --------------- The name of the selected example is in black instead of white. Expected Behavior: ----------------- The name of the selected example should be in white. Solution: -------- Update the font color of the selected example name to white for better contrast in dar
Original PR description
Steps to reproduce the issue: ---------------------------- 1. Enable dark mode 2. Go to Project app 3. Create a new project 4. Click on `See examples` in the kanban 5. Select an example. Actual Behavior: --------------- The name of the selected example is in black instead of white. Expected Behavior: ----------------- The name of the selected example should be in white. Solution: -------- Update the font color of the selected example name to white for better contrast in dark mode. task-3602610 Forward-Port-Of: odoo/odoo#146815
Issue ----- The cache is not updated properly when the configuration of a currency changes. This leads to reading stale values in other places. For instance, changing currency symbol position isn't reflected in invoice tree views unless after a server restart. Steps ----- - Open Accounting -> Configuration -> Currencies. - Pick the active currency, say USD. - Change 'Currency Symbol Position' to a different value. - Go to Accounting -> Customers -> Invoices. The displayed amo
Original PR description
Issue ----- The cache is not updated properly when the configuration of a currency changes. This leads to reading stale values in other places. For instance, changing currency symbol position isn't reflected in invoice tree views unless after a server restart. Steps ----- - Open Accounting -> Configuration -> Currencies. - Pick the active currency, say USD. - Change 'Currency Symbol Position' to a different value. - Go to Accounting -> Customers -> Invoices. The displayed amounts don't reflect the change. Cause ----- Cache refresh was misplaced after a premature return, so the cache wasn't refreshed when 'digits', 'position' or 'symbol' fields of `res.currency` are written, although that was the intent. opw-3849155 Forward-Port-Of: odoo/odoo#161036
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'
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#162019
Forward-Port-Of: odoo/odoo#160147Steps 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 Forward-Port-Of: odoo/odoo#162047
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 Forward-Port-Of: odoo/odoo#162047
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 Forward
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 Forward-Port-Of: odoo/odoo#161561
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 Forward-Port-Of: odoo/odoo#162036
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 Forward-Port-Of: odoo/odoo#162036
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 donationAmo
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 Forward-Port-Of: odoo/odoo#161431
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 signe
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#161982 Forward-Port-Of: odoo/odoo#160965
Steps to reproduce : 1. click on edit website. 2. click on THEME tab from snippet options. 3. scroll down to input fields. 4. the border width has options for small and large size, which serves no purpose and were displayed empty. Purpose: This PR aims to remove the changes made on [[1]](https://github.com/odoo-dev/odoo/commit/6c0d2da07d2df2a27155678f58a6ffc79351e543) which added 2 sub-levels options for Border Width for Input Field which served no purpose. After this PR : Th
Original PR description
Steps to reproduce : 1. click on edit website. 2. click on THEME tab from snippet options. 3. scroll down to input fields. 4. the border width has options for small and large size, which serves no purpose and were displayed empty. Purpose: This PR aims to remove the changes made on [[1]](https://github.com/odoo-dev/odoo/commit/6c0d2da07d2df2a27155678f58a6ffc79351e543) which added 2 sub-levels options for Border Width for Input Field which served no purpose. After this PR : The Border Width option will not have sub options small and large. task-3771146 Forward-Port-Of: odoo/odoo#157374
This is a followup on [1]. In Chrome the event's currentTarget is cleared after events such as "scroll" are handled. For asynchronously called methods to be able to access it, the current value of currentTarget needs to be kept. To help developers that might stumble on this issue when using `throttleForAnimation`, this commit emphasizes the fact that usage of that function is not limited to event handlers, and it adds a test case that illustrates a solution for tracking the lost scrol
Original PR description
This is a followup on [1]. In Chrome the event's currentTarget is cleared after events such as "scroll" are handled. For asynchronously called methods to be able to access it, the current value of currentTarget needs to be kept. To help developers that might stumble on this issue when using `throttleForAnimation`, this commit emphasizes the fact that usage of that function is not limited to event handlers, and it adds a test case that illustrates a solution for tracking the lost scroll event target. No scenario was identified in 15.0, but this could be used as an alternative solution for [1]. [1]: https://github.com/odoo/odoo/commit/0ba601d2ef5c4e2f846818e78dcd23966d6f563d task-3449843 Forward-Port-Of: odoo/odoo#160969 Forward-Port-Of: odoo/odoo#131259
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 co
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#162105 Forward-Port-Of: odoo/odoo#161893
Backporting: https://github.com/odoo/odoo/commit/1e24b151c6ad0023769b5a561690cb62bcda1d8a When importing a UBL file, Odoo expects the UBL specific namespaces to be in the root element of the file. This is not always the case as these namespaces could exist in every element in the file. When a file is formatted this way, Odoo cannot extract the necessary data from it because it is missing the necessary namespaces. To cover this case we use the lxml.etree.Element.find function instead, and pass
Original PR description
Backporting: https://github.com/odoo/odoo/commit/1e24b151c6ad0023769b5a561690cb62bcda1d8a When importing a UBL file, Odoo expects the UBL specific namespaces to be in the root element of the file. This is not always the case as these namespaces could exist in every element in the file. When a file is formatted this way, Odoo cannot extract the necessary data from it because it is missing the necessary namespaces. To cover this case we use the lxml.etree.Element.find function instead, and pass in the UBL specific namespaces to successfully extract the data. task-3657563 opw-3839398 Forward-Port-Of: odoo/odoo#161857 Forward-Port-Of: odoo/odoo#161034
Some states (e.g. Rio Grande do Sul) require the name attribute to be set, others (e.g. Paraná) do not and will take the businessName. Before this, submitting an e-invoice for Rio Grando do Sul results in "Rejeicao: NF-e sem o nome do destinatario" (code: 724). After this, submitting the invoice succeeds. opw-3793773 Forward-Port-Of: odoo/enterprise#60887
Original PR description
Some states (e.g. Rio Grande do Sul) require the name attribute to be set, others (e.g. Paraná) do not and will take the businessName. Before this, submitting an e-invoice for Rio Grando do Sul results in "Rejeicao: NF-e sem o nome do destinatario" (code: 724). After this, submitting the invoice succeeds. opw-3793773 Forward-Port-Of: odoo/enterprise#60887
When activating the groupby_prefix parameter for the Partner Ledger, a Traceback can happen if clicking on Unfold All and some of the partners are archived. That's because the search on res.partner in `_custom_unfold_all_batch_data_generator` injects the active ir.rule whereas the search in `_query_partners` does not. To fix that, pass `active_test=False` to the context. To reproduce: - Install `account_reports` and `contacts` with demo data - Archive Azure Interior - Set the paramete
Original PR description
When activating the groupby_prefix parameter for the Partner Ledger, a Traceback can happen if clicking on Unfold All and some of the partners are archived. That's because the search on res.partner in `_custom_unfold_all_batch_data_generator` injects the active ir.rule whereas the search in `_query_partners` does not. To fix that, pass `active_test=False` to the context. To reproduce: - Install `account_reports` and `contacts` with demo data - Archive Azure Interior - Set the parameter `account_reports.partner_ledger. groupby_prefix_groups_threshold` to 2 - Go to Partner Ledger - Click on Unfold All - A Traceback is raised Also changes the search domain operator from `ilike` to `=ilike`. Ticket link: [odoo/task#3703069](https://www.odoo.com/web#model=project.task&id=3703069) opw-3703069 Forward-Port-Of: odoo/enterprise#57727
Previously, it was easy to bypass the maximum_amount field on payment.provider by going to a subscription and clicking "Set Payment Method". The subscription would then be charged with the token, regardless of the maximum_amount set on the payment.provider. This filters out ineligible acquirers through _get_compatible_providers() so it's not possible to use them for new payment methods. The existing override wasn't working because sale_order_id was a string and sale.order('1').exists() alway
Original PR description
Previously, it was easy to bypass the maximum_amount field on payment.provider by going to a subscription and clicking "Set Payment Method". The subscription would then be charged with the token,…
Previously, it was easy to bypass the maximum_amount field on payment.provider by going to a subscription and clicking "Set Payment Method". The subscription would then be charged with the token, regardless of the maximum_amount set on the payment.provider.
This filters out ineligible acquirers through
_get_compatible_providers() so it's not possible to use them for new payment methods. The existing override wasn't working because sale_order_id was a string and sale.order('1').exists() always returns False. Casting sale_order_id to a string was added in a small /my/payment_method route override.
Filtering out already existing payment methods is harder because the sale order isn't available in _get_available_tokens(). Instead we raise a UserError when a user assigns an ineligible payment method. This is handled well in the frontend.
This focuses only on customer-facing flows. The maximum_amount field isn't checked either on e.g. account.payment but that's only accessible to internal users. Other customer-facing flows aren't affected because typically _get_available_tokens() is called with eligible payment providers as its first parameter.
Attempted alternative approaches:
- odoo/odoo#161021, odoo/enterprise#60294
- odoo/enterprise#60382
opw-3858340
Forward-Port-Of: odoo/enterprise#60482Currently, iot module uses `get_resource_path` to check whether a Worldline libeasyctep.so library is present on the IoT Box. It is currently provoking a deprecation warning in logs: ``` 2024-04-16 09:34:02,574 2873 WARNING ? py.warnings: /home/pi/odoo/odoo/modules/module.py:167: DeprecationWarning: Since 17.0: use tools.misc.file_path instead of get_resource_path(hw_driver> File "/usr/lib/python3.11/threading.py", line 995, in _bootstrap self._bootstrap_inner() File "/usr/lib/
Original PR description
Currently, iot module uses `get_resource_path` to check whether a Worldline libeasyctep.so library is present on the IoT Box. It is currently provoking a deprecation warning in logs: ``` 2024-04-16…
Currently, iot module uses `get_resource_path` to check whether a Worldline libeasyctep.so library is present on the IoT Box.
It is currently provoking a deprecation warning in logs:
```
2024-04-16 09:34:02,574 2873 WARNING ? py.warnings: /home/pi/odoo/odoo/modules/module.py:167: DeprecationWarning: Since 17.0: use tools.misc.file_path instead of get_resource_path(hw_driver>
File "/usr/lib/python3.11/threading.py", line 995, in _bootstrap
self._bootstrap_inner()
File "/usr/lib/python3.11/threading.py", line 1038, in _bootstrap_inner
self.run()
File "/home/pi/odoo/addons/hw_drivers/main.py", line 106, in run
helpers.load_iot_handlers()
File "/home/pi/odoo/addons/hw_drivers/tools/helpers.py", line 400, in load_iot_handlers
spec.loader.exec_module(module)
File "/home/pi/odoo/addons/hw_drivers/iot_handlers/interfaces/CTEPInterface_L.py", line 15, in <module>
if not get_resource_path("hw_drivers", "iot_handlers", "lib", "ctep", "libeasyctep.so"):
File "/home/pi/odoo/odoo/modules/module.py", line 167, in get_resource_path
warnings.warn(
```
Since `get_resource_path` is deprecated as of v17.0, this PR replaces it by `file_path` to remain up to date.
Apart from replacing the deprecated `get_resource_path`, this PR also replaces `subprocess.check_call` by the `subprocess.run` in the corresponding code as suggested by subprocess documentation starting from Python v3.5
Finally, it prettifies the modified lines of code a little by changing a variable name and modifying the logger message in case of an error to make it more specific
task-3872853
Forward-Port-Of: odoo/enterprise#60859For some reason, when all the modules are loaded, the step - click on action - is not stepped on. This is probably because it is executed before the page is even loaded. That's why we add the check. Forward-Port-Of: odoo/enterprise#60817
Original PR description
For some reason, when all the modules are loaded, the step - click on action - is not stepped on. This is probably because it is executed before the page is even loaded. That's why we add the check. Forward-Port-Of: odoo/enterprise#60817
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 Forward-Port-Of: odoo/enterprise#59449
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 Forward-Port-Of: odoo/enterprise#59449
- 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. , 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#60841 Forward-Port-Of: odoo/enterprise#60629
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 com
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#60816 Forward-Port-Of: odoo/enterprise#60506
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 Forward-Port-Of: odoo/enterprise#60562
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 Forward-Port-Of: odoo/enterprise#60562
Ease the audit of a General Ledger, especially the tax lines by having the bank transaction description/payment reference displayed next to the tax applied to it. task id: 3861381 Forward-Port-Of: odoo/enterprise#60472
Original PR description
Ease the audit of a General Ledger, especially the tax lines by having the bank transaction description/payment reference displayed next to the tax applied to it. task id: 3861381 Forward-Port-Of: odoo/enterprise#60472
…ressbar Have a kanban view that: - is grouped by a granular date field "date:month" - has a progressbar - won't display any records (the domain yields no record) Before this commit, there was a crash, because the field name was wrongly parsed. After this commit, there is no crash when we open that kanban view, even in the ml editor opw-3853604 Forward-Port-Of: odoo/enterprise#60428
Original PR description
…ressbar Have a kanban view that: - is grouped by a granular date field "date:month" - has a progressbar - won't display any records (the domain yields no record) Before this commit, there was a crash, because the field name was wrongly parsed. After this commit, there is no crash when we open that kanban view, even in the ml editor opw-3853604 Forward-Port-Of: odoo/enterprise#60428
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 Forward-Port-Of: odoo/enterprise#59992
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 Forward-Port-Of: odoo/enterprise#59992
…or res.users Open the base action for res.users (Settings => Users) Unfold the Existing fields list, and search for a field reprensenting an access rights category. Before this commit, adding such field crashed because some meta data were missing in the fields_get. Since those fields are dynamic and may change with any changes in groups' hierarchy, it doesn't really make sense to make them available to add on a view. Before this commit, those fields are not proposed any more. opw
Original PR description
…or res.users Open the base action for res.users (Settings => Users) Unfold the Existing fields list, and search for a field reprensenting an access rights category. Before this commit, adding such field crashed because some meta data were missing in the fields_get. Since those fields are dynamic and may change with any changes in groups' hierarchy, it doesn't really make sense to make them available to add on a view. Before this commit, those fields are not proposed any more. opw-3842879 Forward-Port-Of: odoo/enterprise#60719 Forward-Port-Of: odoo/enterprise#60321
Have some rules: 1. with domain, exclusive, order: 1 2. no domain, exclusive, order: 1 3: no domain, exclusive, order: 2 Have a record that doesn't satisfy rule#1's domain. Before this commit, no notification is sent when validating rules, but it should send one for rule#3 After this commit, a notification is sent for rule#3 opw-3815732 Forward-Port-Of: odoo/enterprise#60257
Original PR description
Have some rules: 1. with domain, exclusive, order: 1 2. no domain, exclusive, order: 1 3: no domain, exclusive, order: 2 Have a record that doesn't satisfy rule#1's domain. Before this commit, no notification is sent when validating rules, but it should send one for rule#3 After this commit, a notification is sent for rule#3 opw-3815732 Forward-Port-Of: odoo/enterprise#60257
This commit adds slight improvement to the design of remote work by adding margin to "Set Location" button. task-3693392 Forward-Port-Of: odoo/odoo#157502
Original PR description
This commit adds slight improvement to the design of remote work by adding margin to "Set Location" button. task-3693392 Forward-Port-Of: odoo/odoo#157502