Tuesday, February 13, 2024
55 changes · saas-17.1
Resolved issues and error corrections
Messages whose original author contact was deleted now remain visible without errors. The message shows a default avatar and uses the sender email as the author name, keeping chatter histories readable for users.
Original PR description
Description of the issue/feature this PR addresses: Prerequisite: - User A (admin) - User B (random internal) Steps: - Login as B - Find a chatter and send a log note or a message - Logout - Login with A - Delete user B and the contact related - Open the same chatter than above Current behavior before PR: - Multiple traceback due to "no author" - No avatar Desired behavior after PR is merged: - No traceback - Message avatar is the default one / the placeholder - Message author name is the email_from field opw-3743727 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could occur when showing sample document data if a generated value triggered an unintended thumbnail update. The change makes sample values safer for selection fields, improving reliability when users preview or test the Documents app.
Original PR description
Bug === When we show the sample data of documents, it will choose a random value for the selection field. But document use a special option to make the browser generate the thumbnail of PDFs and then save it on the record. So, without this rule, it will try to update the record if "client_generated" has been chosen. Task-3697924
This update makes an internal quality check run consistently by processing files in a stable order. It helps avoid random failures during development and release validation, reducing noise for teams without changing customer-facing behavior.
Original PR description
pylint sql-injection check may fail because of random checking paths' order this commit fixes the issue by sorting these paths this fix is also a backport commit from https://github.com/odoo/odoo/pull/142814 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
Opening the Documents app with sample data could sometimes fail when a randomly chosen thumbnail option tried to update a sample record. This fix prevents that incorrect option from being used, so sample documents load reliably for users evaluating or demonstrating the app.
Original PR description
Bug === When we show the sample data of documents, it will choose a random value for the selection field. But document use a special option to make the browser generate the thumbnail of PDFs and then save it on the record. So, without this rule, it will try to update the record if "client_generated" has been chosen. Task-3697924 See odoo/odoo/pull/152490
Currently, a log error is occurring from [1] and [2] due to adding two msgids instead of one there in the 'es_419.po' file. This is because the recently refactored code https://github.com/odoo/enterprise/commit/c2a5c5950cf702c6ed77d8b94c7dfece3f127dc8 updated translations but added an extra msgid at [1] and [2]. Error ``` KeyError: ('mi', 'mi') File "polib.py", line 1491, in process (action, state) = self.transitions[(symbol, self.current_state)] OSError: Syntax error in po fil
Original PR description
Currently, a log error is occurring from [1] and [2] due to adding two msgids instead of one there in the 'es_419.po' file. This is because the recently refactored code…
Currently, a log error is occurring from [1] and [2] due to adding two msgids instead of one
there in the 'es_419.po' file. This is because the recently refactored code https://github.com/odoo/enterprise/commit/c2a5c5950cf702c6ed77d8b94c7dfece3f127dc8
updated translations but added an extra msgid at [1] and [2].
Error
```
KeyError: ('mi', 'mi')
File "polib.py", line 1491, in process
(action, state) = self.transitions[(symbol, self.current_state)]
OSError: Syntax error in po file (line 281)
File "odoo/tools/translate.py", line 1660, in _get_code_translations
p = CodeTranslations._read_code_translations_file(fileobj, filter_func)
File "odoo/tools/translate.py", line 1647, in _read_code_translations_file
reader = TranslationFileReader(fileobj, fileformat='po')
File "odoo/tools/translate.py", line 636, in TranslationFileReader
return PoFileReader(source)
File "odoo/tools/translate.py", line 691, in __init__
self.pofile = polib.pofile(source.read().decode())
File "polib.py", line 130, in pofile
return _pofile_or_mofile(pofile, 'pofile', **kwargs)
File "polib.py", line 78, in _pofile_or_mofile
instance = parser.parse()
File "polib.py", line 1352, in parse
self.process(keywords[tokens[0]])
File "polib.py", line 1495, in process
raise IOError('Syntax error in po file (line %s)' %
```
[1]-https://github.com/odoo/enterprise/blob/8e8e5b2f01c75f0131d8248997fa4059777e3fa1/l10n_ar_reports/i18n/es_419.po#L280-L281 [2]-https://github.com/odoo/enterprise/blob/8e8e5b2f01c75f0131d8248997fa4059777e3fa1/l10n_ar_reports/i18n/es_419.po#L459-L460
sentry-4963679418Miscellaneous changes
Steps to reproduce: -Create a SO and sell a prepaid service in days -Set the timesheeting to days/half-days -Add a timesheet line on the task of the SO -Go to database/my/timesheets and look for the timesheets of the SO -> The days ordered are wrong Before PR: If you confirm the SO with the timesheeted SOL's uom as days and your timesheeting is made in days, the view will convert the amount of days as if it were hours, showing wrong values After PR: Made the report more robust
Original PR description
Steps to reproduce: -Create a SO and sell a prepaid service in days -Set the timesheeting to days/half-days -Add a timesheet line on the task of the SO -Go to database/my/timesheets and look for the timesheets of the SO -> The days ordered are wrong Before PR: If you confirm the SO with the timesheeted SOL's uom as days and your timesheeting is made in days, the view will convert the amount of days as if it were hours, showing wrong values After PR: Made the report more robust, now converting whatever unit the SOL has to either hours or days depending on the timesheet setting opw-3643988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153747 Forward-Port-Of: odoo/odoo#147944
Issue: - When a Helpdesk ticket is associated with a partner, this association is not being correctly linked in the Timesheet module. As a result, when attempting to group Timesheet entries by partner, the grouping is inaccurate. - The issue is caused by the _compute_partner_id not being triggered due to the partner_id being set in the _timesheet_preprocess method. Steps To Reproduce: - Go to Helpdesk - Click on any project with the timesheet option enabled. - Click on new - Add title,
Original PR description
Issue: - When a Helpdesk ticket is associated with a partner, this association is not being correctly linked in the Timesheet module. As a result, when attempting to group Timesheet entries by partner, the grouping is inaccurate. - The issue is caused by the _compute_partner_id not being triggered due to the partner_id being set in the _timesheet_preprocess method. Steps To Reproduce: - Go to Helpdesk - Click on any project with the timesheet option enabled. - Click on new - Add title, customer and timesheet hours - Go to Timesheet - Group by 'partner'> the customer is not there Solution: - remove the lines where partner_id is set in '_timesheet_preprocess'. - Test link to this PR: https://github.com/odoo/enterprise/pull/54373 opw-3667921 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153740 Forward-Port-Of: odoo/odoo#153026
## Description Domains of the form ```python [('stored_Many2X.id', '=/!=/in/not in', list_of_ids)] ``` will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table. There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly
Original PR description
## Description
Domains of the form
```python
[('stored_Many2X.id', '=/!=/in/not in', list_of_ids)]
```
will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table.
There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly referencing the `field` from the `model`. So in some cases using an explicit `.id` would be a wanted, if the intention was to apply the `ir.rule`.
## Fix
Remove the `.id` from left leafs of domains that if the field is stored, and the `comodel` doesn't have `ir.rule` associated with it, or the `ir.rule` application is redundant/not needed.
task-3735923
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#153460…arshal None unless allow_none is enabled Description of the issue/feature this PR addresses: When uses External API to fetch an invoice, if this invoice it's paid and the 'partner' hasn't 'company' return None instead False Current behavior before PR: TypeError: cannot marshal None unless allow_none is enabled Desired behavior after PR is merged: Should return an object with invoice_payments_widget as attribute. --- I confirm I have signed the CLA and read the PR guideline
Original PR description
…arshal None unless allow_none is enabled Description of the issue/feature this PR addresses: When uses External API to fetch an invoice, if this invoice it's paid and the 'partner' hasn't 'company' return None instead False Current behavior before PR: TypeError: cannot marshal None unless allow_none is enabled Desired behavior after PR is merged: Should return an object with invoice_payments_widget as attribute. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153362
Versions -------- - 17.0 - 17.1 - master Steps ----- 1. Go to Settings / Manage Languages; 2. select your current language; 3. set First Day of Week to something other than Sunday; 4. go to Time Off app. Issue ----- Weeks in year overview still start on a Sunday. Cause ----- Commit 52dae7a2f00c41222cf4518617d050efa8d34359 hardcoded `firstDay` to Sunday for the `hr_holidays` module. This was a workaround to some issues with `fullcalendar`'s week number calculations. Solut
Original PR description
Versions -------- - 17.0 - 17.1 - master Steps ----- 1. Go to Settings / Manage Languages; 2. select your current language; 3. set First Day of Week to something other than Sunday; 4. go to Time Off…
Versions -------- - 17.0 - 17.1 - master Steps ----- 1. Go to Settings / Manage Languages; 2. select your current language; 3. set First Day of Week to something other than Sunday; 4. go to Time Off app. Issue ----- Weeks in year overview still start on a Sunday. Cause ----- Commit 52dae7a2f00c41222cf4518617d050efa8d34359 hardcoded `firstDay` to Sunday for the `hr_holidays` module. This was a workaround to some issues with `fullcalendar`'s week number calculations. Solution -------- Remove the hardcoded `firstDay`, and add a custom week numbering function to be used on week, month, and year calendar views for consistent numbering that allows for different first days of the week. The function returns the ISO week number of the Monday nearest to the configured first day of the week, i.e. the following Monday when first day is set to Friday, Saturday or Sunday, the previous Monday if first day is set to Tuesday, Wednesday or Thursday. There were 3 main considerations for deciding a week numbering method: 1. no exisiting setting for users to decide on a method; 2. the ability to pick a first day of the week independent of locale; 3. the version of `luxon` used being unable to factor in locale. Addendum -------- This commit doesn't fix the issue with group-by week numbering in list view. These stem from `babel`'s inconsistent locale defaults and inability to take user-configured first day of the week into account. opw-3668175 Forward-Port-Of: odoo/odoo#148623
Since fd2fb212c50952ca5a8e162ba5d82ce433cd5989, the sepa provider (enterprise module) behaves as a custom provider but despite some adaptations, the removal of providers on module uninstall was not properly adapted. The uninstall of the sepa provider failed as its inline template was not unlinked from the provider before the template deletion. This commit makes sure that custom providers are correctly considered in the uninstall util supposed to restore a provider to its state before th
Original PR description
Since fd2fb212c50952ca5a8e162ba5d82ce433cd5989, the sepa provider (enterprise module) behaves as a custom provider but despite some adaptations, the removal of providers on module uninstall was not properly adapted. The uninstall of the sepa provider failed as its inline template was not unlinked from the provider before the template deletion. This commit makes sure that custom providers are correctly considered in the uninstall util supposed to restore a provider to its state before the installation of its module. opw-3734697 opw-3721846 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153690
Specification: This commit targets the scenario when an image is in the selection and the toolbar displays an AI option, which makes no sense as the generated response will replace the image. Desired behavior after PR is merged: The toolbar has been updated to show the AI option only for text-based scenario task-3733320 Forward-Port-Of: odoo/odoo#153190
Original PR description
Specification: This commit targets the scenario when an image is in the selection and the toolbar displays an AI option, which makes no sense as the generated response will replace the image. Desired behavior after PR is merged: The toolbar has been updated to show the AI option only for text-based scenario task-3733320 Forward-Port-Of: odoo/odoo#153190
This commit's purpose is to fix the re apparition of personnal stage on the todo app when personnal stages are deleted one after the other. Step to reproduce: -login as Marc demo -open todo -delete any personnal stage without any todo in it -delete any personnal stage with at least one todo in it The personnal stage deleted first is now present again in the kanban view. Note that it is only a frontend bug. The record has been correctly removed from the db, and any action with it will tr
Original PR description
This commit's purpose is to fix the re apparition of personnal stage on the todo app when personnal stages are deleted one after the other. Step to reproduce: -login as Marc demo -open todo -delete…
This commit's purpose is to fix the re apparition of personnal stage on the todo app when personnal stages are deleted one after the other. Step to reproduce: -login as Marc demo -open todo -delete any personnal stage without any todo in it -delete any personnal stage with at least one todo in it The personnal stage deleted first is now present again in the kanban view. Note that it is only a frontend bug. The record has been correctly removed from the db, and any action with it will trigger a cache miss exception and reloading the view completly will removed those ghost stages definitly. Source of the problem: The problem is that the deletion is only reloading the view completly when a record with child data is removed. More precisly, the _deleteGroup function of the dynamic list triggers an rpc call to update the config of the component only when a record with child data is deleted, and that data need to be switched to another record, while when it is an empty record, the record is simply removed from the group field of the list. The issue is that there is thus a mismatch between the group in the list.config.groups and the list.group. And when the config is updated, only the list.config.groups is used to update the config, meaning it potentially still contains element that were already deleted. Solution: Doing a check up on the list.group to ensure that any deleted element is also removed from the config when an update is triggered. Note: I dont why Mitchel admin did not trigger the bug. Code wise, it should happends no matter the access right of the connectedd user. Version affected: master task - 3553101 https://www.odoo.com/web#id=3553101&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=form 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 Forward-Port-Of: odoo/odoo#142536
Issue: ------ Since this commit[^1], a user who is not in the `Administration/Access Rights` group cannot modify certain fields available to him on his user profile (`livechat_username` and `livechat_lang_ids`). Solution: --------- As it is possible for a user to write to these fields, it is necessary to put them in `SELF_READABLE_FIELDS` in order to obtain sudo rights when writing if the environment user corresponds to the user to whom we want to write the new values. opw-3717266 [
Original PR description
Issue: ------ Since this commit[^1], a user who is not in the `Administration/Access Rights` group cannot modify certain fields available to him on his user profile (`livechat_username` and `livechat_lang_ids`). Solution: --------- As it is possible for a user to write to these fields, it is necessary to put them in `SELF_READABLE_FIELDS` in order to obtain sudo rights when writing if the environment user corresponds to the user to whom we want to write the new values. opw-3717266 [^1]: 78f6b83b348326ac0848692ca228a4650057f95c Forward-Port-Of: odoo/odoo#152425
Before this commit, an Outlook event without an organizer would fail to sync with Odoo. This commit fixes this issue by allowing events without an organizer to be synced from Outlook to Odoo. opw-3701839 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153495
Original PR description
Before this commit, an Outlook event without an organizer would fail to sync with Odoo. This commit fixes this issue by allowing events without an organizer to be synced from Outlook to Odoo. opw-3701839 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153495
Add method '_get_discount_product' to allow to override the product used by the sale_order_discount wizard. Forward-Port-Of: odoo/odoo#153652
Original PR description
Add method '_get_discount_product' to allow to override the product used by the sale_order_discount wizard. Forward-Port-Of: odoo/odoo#153652
Rules always have a pricelist, so we can avoid an useless database query when we are computing the prices without any pricelist. Also makes sure that the modified context used for the pricelist items search is not propagated by enforcing the same context in the returned rules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153624
Original PR description
Rules always have a pricelist, so we can avoid an useless database query when we are computing the prices without any pricelist. Also makes sure that the modified context used for the pricelist items search is not propagated by enforcing the same context in the returned rules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153624
Before this commit, the project task list view computed the list of selected records once for each cell, when rendering the list. As a consequence, this slowed down a lot the rendering on large tables (~1s for 80 records). With this commit, we compute the selection only once to render the whole table. 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 guidel
Original PR description
Before this commit, the project task list view computed the list of selected records once for each cell, when rendering the list. As a consequence, this slowed down a lot the rendering on large tables (~1s for 80 records). With this commit, we compute the selection only once to render the whole table. 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 Forward-Port-Of: odoo/odoo#153611
While fixing a non deterministic test failing on nightly l10n builds, slight incoherences between sale & website_sale tax computation have been noticed in the computation of the contextual price (used in some snippets). This commit fixes the test, making sure it doesn't fail on l10n builds, but also uses the same tax util in website_sale than in sale, to make sure the displayed amounts are coherent (and supposedly correct). runbot error: 52831 (& a bunch of others) --- I confirm I h
Original PR description
While fixing a non deterministic test failing on nightly l10n builds, slight incoherences between sale & website_sale tax computation have been noticed in the computation of the contextual price (used in some snippets). This commit fixes the test, making sure it doesn't fail on l10n builds, but also uses the same tax util in website_sale than in sale, to make sure the displayed amounts are coherent (and supposedly correct). runbot error: 52831 (& a bunch of others) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153299 Forward-Port-Of: odoo/odoo#152832
Since the introduction of the Embed Code snippet with [1], in case some content was created dynamically through a `<script>` tag, it would be duplicated upon editing the snippet again after it had been displayed a 1st time. This is because each time you open the snippet's ace editor, the current state of the snippet (including dynamically created elements) is saved in the view. This commit removes the `<script>`s inside embed code snippets from the view in edit mode, and then saves them
Original PR description
Since the introduction of the Embed Code snippet with [1], in case some content was created dynamically through a `<script>` tag, it would be duplicated upon editing the snippet again after it had…
Since the introduction of the Embed Code snippet with [1], in case some
content was created dynamically through a `<script>` tag, it would be
duplicated upon editing the snippet again after it had been displayed a
1st time. This is because each time you open the snippet's ace editor,
the current state of the snippet (including dynamically created
elements) is saved in the view.
This commit removes the `<script>`s inside embed code snippets from the
view in edit mode, and then saves them on the server upon save.
We also take the opportunity to add a message in edit mode if the
snippet doesn't display anything (e.g. if it only contains a script tag,
or an empty element), so that it is easily focusable to edit its
content.
Finally, we add a message upon editing an embed code snippet to inform
the user that they should not use it unless they know what they're doing
as well as tell them they may inject code in the `<head>` or `<body>`
elements through the Theme panel.
Note: this fix is only valid for code injected inside the embed code
snippet. For code injected outside of the snippet, we have no way of
controlling / sanitizing the DOM after the fact.
Steps to reproduce:
1. Drag and drop an Embed Code Snippet
2. Copy the following code:
```
<script>
document.addEventListener('DOMContentLoaded', function () {
const alertEl = document.createElement('div');
alertEl.classList.add('alert', 'alert-primary');
alertEl.textContent = "Hello";
document.getElementById('some-stuff').appendChild(alertEl);
});
</script>
<div id="some-stuff"></div>
```
3. Save and exit the editor. The injected div should appear.
4. Go back to the editor, click to edit the snippet and either save or
discard.
5. Exit the editor
=> The div is duplicated.
[1]: https://github.com/odoo/odoo/commit/2cc481d1a62202ade4c1ca8f846c962f9f2cc34d
opw-3513760
Forward-Port-Of: odoo/odoo#152502
Forward-Port-Of: odoo/odoo#142130This PR fixes an unconsistent forestack icon within the `sale_stock` module. Prior to this PR, the forecast icon was using a `text-primary` class, making it unconsistent regarding the other forecast icons. We also add a missing `cursor-pointer` class to fix the improve the hover state and the visual feedback of the link. task-3582145 Forward-Port-Of: odoo/odoo#153618 Forward-Port-Of: odoo/odoo#140959
Original PR description
This PR fixes an unconsistent forestack icon within the `sale_stock` module. Prior to this PR, the forecast icon was using a `text-primary` class, making it unconsistent regarding the other forecast icons. We also add a missing `cursor-pointer` class to fix the improve the hover state and the visual feedback of the link. task-3582145 Forward-Port-Of: odoo/odoo#153618 Forward-Port-Of: odoo/odoo#140959
In tax report, ve38 line should display the tax excluded amount, not the tax amount. Task link: https://www.odoo.com/web#model=project.task&id=3609402 opw-3609402 Forward-Port-Of: odoo/odoo#153558 Forward-Port-Of: odoo/odoo#145570
Original PR description
In tax report, ve38 line should display the tax excluded amount, not the tax amount. Task link: https://www.odoo.com/web#model=project.task&id=3609402 opw-3609402 Forward-Port-Of: odoo/odoo#153558 Forward-Port-Of: odoo/odoo#145570
Product template "property_account_expense_id" and "property_account_creditor_price_difference" fields must stay editable in cases even if not "can be puchased". Since it being readonly is trivial, better leave it writeable instead of implementing cross module readonly logic. Task: 3695677 Forward-Port-Of: odoo/odoo#150601
Original PR description
Product template "property_account_expense_id" and "property_account_creditor_price_difference" fields must stay editable in cases even if not "can be puchased". Since it being readonly is trivial, better leave it writeable instead of implementing cross module readonly logic. Task: 3695677 Forward-Port-Of: odoo/odoo#150601
Issue: When the notification webhook is enabled for Adyen, sometimes the response back causes an SQL concurrent update. Odoo then creates a retry towards Adyen, charging the customer card several times. Both the notification webhook and the payment controller are hit, and try updatingthe same row simultaneously, which causes this behavior. Steps to reproduce: This bug is not reproducible due to a connection issue for the Adyen test account. However, if the payment request would implement id
Original PR description
Issue: When the notification webhook is enabled for Adyen, sometimes the response back causes an SQL concurrent update. Odoo then creates a retry towards Adyen, charging the customer card several…
Issue: When the notification webhook is enabled for Adyen, sometimes the response back causes an SQL concurrent update. Odoo then creates a retry towards Adyen, charging the customer card several times. Both the notification webhook and the payment controller are hit, and try updatingthe same row simultaneously, which causes this behavior. Steps to reproduce: This bug is not reproducible due to a connection issue for the Adyen test account. However, if the payment request would implement idempotency we could prevent billing the customer on the same request if the request reaches this collision and is retried multiple times. Description A first payment request is sent to Adyen. The card is charged and Adyen answers that all went as expected. We try to process the payment, but a concurrent access error occurs. A retry is done. A payment request is sent again to Adyen, The card is charged AGAIN and Adyen answers that all went as expected. We try to process the payment, but a concurrent access error occurs. For each retry, the request is sent and the card is charged. If the first retry succeeds, then Odoo can finish the process. There will be only 1 payment transaction on Odoo's side (others have been rollbacked) but there will be 3 on Adyen's side and the card will be charged 3 times. This PR fixes this behaviour by adding the idempotency key to the headers with the hash of the transaction reference and the database UUID, we prevent duplicate payments to happen. OPW-3584300 Forward-Port-Of: odoo/odoo#153734 Forward-Port-Of: odoo/odoo#150102
In previous versions the max size of a domain was bounded by psycopg memory limits. With the new SQL formatting mechanism the limit is bound by the maximum recursion limit in Python side. The purpose of this patch is to restore previous behavior. In 16.0: ``` >>> def make_dom(N): ... return [*('|' for x in range(N-1)), *(('login', '=', 'admin') for x in range(N))] ... >>> u.search(make_dom(9984)) res.users(2,) >>> u.search(make_dom(9985)) Traceback (most recent call last): File
Original PR description
In previous versions the max size of a domain was bounded by psycopg memory limits. With the new SQL formatting mechanism the limit is bound by the maximum recursion limit in Python side. The purpose…
In previous versions the max size of a domain was bounded by psycopg memory limits. With the new SQL formatting mechanism the limit is bound by the maximum recursion limit in Python side. The purpose of this patch is to restore previous behavior.
In 16.0:
```
>>> def make_dom(N):
... return [*('|' for x in range(N-1)), *(('login', '=', 'admin') for x in range(N))]
...
>>> u.search(make_dom(9984))
res.users(2,)
>>> u.search(make_dom(9985))
Traceback (most recent call last):
File "<input>", line 1, in <module>
u.search(make_dom(9985))
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 1520, in search
return res if count else self.browse(res)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5140, in browse
if not ids:
File "/home/odoo/src/odoo/16.0/odoo/tools/query.py", line 217, in __bool__
return bool(self._result)
File "/home/odoo/src/odoo/16.0/odoo/tools/func.py", line 28, in __get__
value = self.fget(obj)
File "/home/odoo/src/odoo/16.0/odoo/tools/query.py", line 210, in _result
self._cr.execute(query_str, params)
File "/home/odoo/src/odoo/16.0/odoo/sql_db.py", line 321, in execute
res = self._obj.execute(query, params)
psycopg2.errors.SyntaxError: memory exhausted at or near ""login""
LINE 1: ...((("res_users"."login" = 'admin') OR ("res_users"."login" = ...
```
in 17.0 without this patch
```
>>> u.search(make_dom(1480))
res.users(2,)
>>> u.search(make_dom(1481))
<shortened output ...>
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 85, in code
child = stack[-1].send(child)
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 86, in <genexpr>
if isinstance(child, SQL):
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 85, in code
child = stack[-1].send(child)
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 86, in <genexpr>
if isinstance(child, SQL):
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 85, in code
child = stack[-1].send(child)
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 86, in <genexpr>
if isinstance(child, SQL):
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 85, in code
child = stack[-1].send(child)
RecursionError: maximum recursion depth exceeded
```
This issue was observed in upgrades in multiple instances. Example: MRP produces an OR domain with 2K terms for warehouse sub-locations that fail.
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
Forward-Port-Of: odoo/odoo#153394Issue: - When checking future accruals in the Time Off dashboard, the Balance view doesn't update correctly. For example, with an accrual plan of 1h per month starting on 30/11/23, the balance in December should show 2h but incorrectly shows only 1.12h. - This happens because the '_get_future_leaves_on' method always returns values in days, ignoring the 'type_request_unit' of the allocation. Steps to Reproduce: - In the time-off app set an accrual plan: 1h per month, accrued on the fir
Original PR description
Issue: - When checking future accruals in the Time Off dashboard, the Balance view doesn't update correctly. For example, with an accrual plan of 1h per month starting on 30/11/23, the balance in December should show 2h but incorrectly shows only 1.12h. - This happens because the '_get_future_leaves_on' method always returns values in days, ignoring the 'type_request_unit' of the allocation. Steps to Reproduce: - In the time-off app set an accrual plan: 1h per month, accrued on the first day of the month. - add a new allocation to Mitchell Admin with that plan - Notice that In the dashboard the balance is 1h - Change the date to next month, new amount is 1.12h, in stead of 2 Solution: - Added a check to correctly calculate future accruals in hours when type_request_unit is 'hour', ensuring accurate hour-based balances. opw-3685077 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152870
Forward-Port-Of: odoo/odoo#153654
Original PR description
Forward-Port-Of: odoo/odoo#153654
## Description Domains of the form ```python [('stored_Many2X.id', '=/!=/in/not in', list_of_ids)] ``` will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table. There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly
Original PR description
## Description
Domains of the form
```python
[('stored_Many2X.id', '=/!=/in/not in', list_of_ids)]
```
will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table.
There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly referencing the `field` from the `model`. So in some cases using an explicit `.id` would be a wanted, if the intention was to apply the `ir.rule`.
## Fix
Remove the `.id` from left leafs of domains that if the field is stored, and the `comodel` doesn't have `ir.rule` associated with it, or the `ir.rule` application is redundant/not needed. `.id`
task-3735923
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#153475This PR fixes 2 issues with discuss navigation: 1. Broken backwards navigation when going back and forth from the live chat session history. 2. Broken backwards navigation when trying to access the same thread than the current one. Steps to reproduce 1: - Open the command palette - Go to the live chat session history view - Click on one of your channels - History back => leads to the session history view - History forward => leads to discuss - History back => stays on discuss, his
Original PR description
This PR fixes 2 issues with discuss navigation: 1. Broken backwards navigation when going back and forth from the live chat session history. 2. Broken backwards navigation when trying to access the…
This PR fixes 2 issues with discuss navigation: 1. Broken backwards navigation when going back and forth from the live chat session history. 2. Broken backwards navigation when trying to access the same thread than the current one. Steps to reproduce 1: - Open the command palette - Go to the live chat session history view - Click on one of your channels - History back => leads to the session history view - History forward => leads to discuss - History back => stays on discuss, history is broken This occurs because the active id is not passed in the action context when navigating backwards which leads to the URL being pushed again in history (URL without active id is different). The active id should be put in the context when available. Steps to reproduce 2: - Go to discuss - Click on the active thread - History back => stuck on discuss, cannot navigate backwards anymore. We should not push in history when accessing the same thread than the current one. task-3422516 Forward-Port-Of: odoo/odoo#153094 Forward-Port-Of: odoo/odoo#152423
Pivot/list monetary fields needs the company currency to display the value in the said currency format. Until now, a RPC was made to fetch the currency. However, since odoo/o-spreadsheet@8710839 and odoo/enterprise@8c0a785 the currency format is already in the model config. There's no need for the RPC. This saves one network request and one full spreadsheet evaluation (which would have occured after the request is done) Note: This optimization currently doesn't work for dashboards.
Original PR description
Pivot/list monetary fields needs the company currency to display the value in the said currency format. Until now, a RPC was made to fetch the currency. However, since odoo/o-spreadsheet@8710839 and odoo/enterprise@8c0a785 the currency format is already in the model config. There's no need for the RPC. This saves one network request and one full spreadsheet evaluation (which would have occured after the request is done) Note: This optimization currently doesn't work for dashboards. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151725
## Description Domains of the form ```python [('stored_Many2X.id', '=/!=/in/not in', list_of_ids)] ``` will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table. There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly
Original PR description
## Description
Domains of the form
```python
[('stored_Many2X.id', '=/!=/in/not in', list_of_ids)]
```
will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table.
There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly referencing the `field` from the `model`. So in some cases using an explicit `.id` would be a wanted, if the intention was to apply the `ir.rule`.
## Fix
Remove the `.id` from left leafs of domains that if the field is stored, and the `comodel` doesn't have `ir.rule` associated with it, or the `ir.rule` application is redundant/not needed.
task-3735923
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#153450### Steps to reproduce - Create a child company. - In the child company, create a new sales journal. - Create and confirm an invoice using this new journal. - Attempt to create a credit note from that invoice. In this scenario, you would encounter an error. ### Cause The `AccountMoveReversal` wizard is currently setting its company to the root company of the moves, which in this case is the parent company. However, its journal is set to the one created in the child company. This m
Original PR description
### Steps to reproduce - Create a child company. - In the child company, create a new sales journal. - Create and confirm an invoice using this new journal. - Attempt to create a credit note from…
### Steps to reproduce - Create a child company. - In the child company, create a new sales journal. - Create and confirm an invoice using this new journal. - Attempt to create a credit note from that invoice. In this scenario, you would encounter an error. ### Cause The `AccountMoveReversal` wizard is currently setting its company to the root company of the moves, which in this case is the parent company. However, its journal is set to the one created in the child company. This mismatch causes an error due to company inconsistency. ### Fix The `company_id` of `AccountMoveReversal` will now be assigned to the company of the moves, rather than the root company. To ensure this works correctly, we also added a check to guarantee that all moves being reversed are from the same company. ### Note This fix also resolves an issue where a traceback occurred if two invoices were created (one in the child company and another in the parent company) and an attempt was made to reverse both simultaneously. opw-3640719 Forward-Port-Of: odoo/odoo#147891
How to reproduce the error: 1. Go to Contacts. 2. Select any contact. 3. Edit the contact and modify the country (without saving). 4. The pricelist field becomes empty. Explanation: The code was incorrectly using "p.id" instead of "p._origin.id" to get the contact ID. This resulted in a non-existent key being retrieved and caused the loss of the price list in the contact when changing the country. The fix adjusts the code to correctly use "p._origin.id", ensuring corr
Original PR description
How to reproduce the error:
1. Go to Contacts.
2. Select any contact.
3. Edit the contact and modify the country (without saving).
4. The pricelist field becomes empty.
Explanation:
The code was incorrectly using "p.id" instead of "p._origin.id" to get the contact ID. This resulted in a non-existent key being retrieved and caused the loss of the price list in the contact when changing the country. The fix adjusts the code to correctly use "p._origin.id", ensuring correct retrieval of the ID and avoiding unwanted changes to the price list.
Example of data obtained by debugging:
- Edited user: Deco Addict
- Data obtained in "res": res {53: product.pricelist(1,)}
- Data retrieved in "p.id": (p.id) > NewId_53
- Data retrieved at "p._origin.id": (p._origin.id) > 53
This commit makes sure the expected pricelist is displayed.
TT47536
Forward-Port-Of: odoo/odoo#152949
Forward-Port-Of: odoo/odoo#152690The commit odoo/odoo@a72007508a985d95 fixed the dialog for the import of a module, but broke the (shared) view for the dialog of the installation of an industry. This commit fixes both dialog views. Before the commit:  After the commit:  And the import dialog remains as it was:  view for the dialog of the installation of an industry. This commit fixes both dialog views. Before the commit:  After the commit:  And the import dialog remains as it was:  Forward-Port-Of: odoo/odoo#153013
terms were changed in pull [147944](https://github.com/odoo/odoo/pull/147944) but not updated in 15.0 and 15.2 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153590
Original PR description
terms were changed in pull [147944](https://github.com/odoo/odoo/pull/147944) but not updated in 15.0 and 15.2 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153590
The goal of this commit is to impove the comment in the `loadImageInfo` method. Forward-Port-Of: odoo/odoo#153554 Forward-Port-Of: odoo/odoo#153438
Original PR description
The goal of this commit is to impove the comment in the `loadImageInfo` method. Forward-Port-Of: odoo/odoo#153554 Forward-Port-Of: odoo/odoo#153438
Since 16.3 ticket_id and ticket_ref don't have the same value, so it won't make sense to show public user ticket_id when they submit tickets anymore. 1) Value will be wrong if ticket_ref sequence has changed 2) They can not access tickets from the portal anyway since they are not portal users. opw-3708995 Forward-Port-Of: odoo/enterprise#56041
Original PR description
Since 16.3 ticket_id and ticket_ref don't have the same value, so it won't make sense to show public user ticket_id when they submit tickets anymore. 1) Value will be wrong if ticket_ref sequence has changed 2) They can not access tickets from the portal anyway since they are not portal users. opw-3708995 Forward-Port-Of: odoo/enterprise#56041
Issue: - When a Helpdesk ticket is associated with a partner, this association is not being correctly linked in the Timesheet module. As a result, when attempting to group Timesheet entries by partner, the grouping is inaccurate. - The issue is caused by the '_compute_partner_id' not being triggered due to the 'partner_id' being set in the '_timesheet_preprocess' method. Steps To Reproduce: - Go to Helpdesk - Click on any project with the timesheet option enabled. - Click on new
Original PR description
Issue: - When a Helpdesk ticket is associated with a partner, this association is not being correctly linked in the Timesheet module. As a result, when attempting to group Timesheet entries by partner, the grouping is inaccurate. - The issue is caused by the '_compute_partner_id' not being triggered due to the 'partner_id' being set in the '_timesheet_preprocess' method. Steps To Reproduce: - Go to Helpdesk - Click on any project with the timesheet option enabled. - Click on new - Add title, customer and timesheet hours - Go to Timesheet - Group by 'partner'> the customer is not there Solution: - remove the lines where partner_id is set in '_timesheet_preprocess'. - This test is linked to this PR https://github.com/odoo/odoo/pull/153026 opw-3667921 Forward-Port-Of: odoo/enterprise#56446 Forward-Port-Of: odoo/enterprise#54373
Before this commit, and because of [1], the full action context was used to create or write any oject that edit_view would use. This caused two types of issues: - Checking the view integrity (_check_xml) sometimes crashed because the context keys (for modifiers) were present and return something else than a Boolean - creating objects with "default_" keys in the context ultimately failed, at best with a crash, at worst it ended up creating object with the wrong data. After this commit, we
Original PR description
Before this commit, and because of [1], the full action context was used to create or write any oject that edit_view would use. This caused two types of issues: - Checking the view integrity (_check_xml) sometimes crashed because the context keys (for modifiers) were present and return something else than a Boolean - creating objects with "default_" keys in the context ultimately failed, at best with a crash, at worst it ended up creating object with the wrong data. After this commit, we still retrieve stuff (the view, in particular) with the full context to have symmetry with the original get_view of Studio, but we write and create things with a cleaned context. opw-3718769 opw-3719815 opw-3703559 opw-3702620 opw-3702360 opw-3698111 opw-3698108 opw-3702084 [1]: https://github.com/odoo/enterprise/pull/54552/ Forward-Port-Of: odoo/enterprise#56466 Forward-Port-Of: odoo/enterprise#56372
Steps: - Open Field service - Go to planning menu - Set menu planning by user - Create task from user line Issue: - In the assignee field user does not set by default. Cause: - Calling `default_get` super method before finding fsm project in `industry_fsm` module sets a current user to task because default_get method treat that task a private task and because of that current user is default assigned in most of fsm action. Fix: - Find fsm project and set it in context before calli
Original PR description
Steps: - Open Field service - Go to planning menu - Set menu planning by user - Create task from user line Issue: - In the assignee field user does not set by default. Cause: - Calling `default_get` super method before finding fsm project in `industry_fsm` module sets a current user to task because default_get method treat that task a private task and because of that current user is default assigned in most of fsm action. Fix: - Find fsm project and set it in context before calling super method so current user does not get assigned for fsm project's tasks. task-3502839 Forward-Port-Of: odoo/enterprise#56396 Forward-Port-Of: odoo/enterprise#48051
This commit fixes the notebook compiler of the form editor. Since some views define invisible fields directly inside a notebook, the compiler was wrong when trying to match the xpath of a notebook tab with the corresponding node from the compiled Notebook component. This created issues, such as incorrect or null xpaths, preventing to edit some tabs and pages, or crashing when adding an element. opw-3672498 Forward-Port-Of: odoo/enterprise#56257 Forward-Port-Of: odoo/enterprise#56057
Original PR description
This commit fixes the notebook compiler of the form editor. Since some views define invisible fields directly inside a notebook, the compiler was wrong when trying to match the xpath of a notebook tab with the corresponding node from the compiled Notebook component. This created issues, such as incorrect or null xpaths, preventing to edit some tabs and pages, or crashing when adding an element. opw-3672498 Forward-Port-Of: odoo/enterprise#56257 Forward-Port-Of: odoo/enterprise#56057
Steps to reproduce: --- 1. Go to Website 2. Click on Edit 3. Place an 'Image - text' block 4. Place an 'Online Appointment' block 5. Select the text on the button 6. In the edit menu, click on edit link 7. Change the link to /website/info 8. Click on save 9. Click on the button 10. Error pops up before redirection 11. Traceback in the console Cause of the issue: --- When editing the text on the button to have a different link, it puts a link tag in the button. When clicking th
Original PR description
Steps to reproduce: --- 1. Go to Website 2. Click on Edit 3. Place an 'Image - text' block 4. Place an 'Online Appointment' block 5. Select the text on the button 6. In the edit menu, click on edit link 7. Change the link to /website/info 8. Click on save 9. Click on the button 10. Error pops up before redirection 11. Traceback in the console Cause of the issue: --- When editing the text on the button to have a different link, it puts a link tag in the button. When clicking the link inside the button, the target is not the same as if it was the button. opw-3610062 Forward-Port-Of: odoo/enterprise#53147
The test classes should not be standard: it makes the test run in l10n builds, while we only expect them to be tested on external builds. So, we can have issues with the server from the government not responding which causes errors on l10n builds It also causes issues in 16.4+ where the request is not accepted. Linked to runbot error 23358, 57019 Forward-Port-Of: odoo/enterprise#56274
Original PR description
The test classes should not be standard: it makes the test run in l10n builds, while we only expect them to be tested on external builds. So, we can have issues with the server from the government not responding which causes errors on l10n builds It also causes issues in 16.4+ where the request is not accepted. Linked to runbot error 23358, 57019 Forward-Port-Of: odoo/enterprise#56274
Create a monetary on a model. In studio, remove the currency_field for that field. Note that the currency field would have been create automatically since commit [1] Try to export the studio customization module. Before this commit, there was crash, because the code that retrieves the currency_field was somewhat erroneous and a recordset of ir.model.fields was joined to a recordset of ir.model. After this commit, there is no crash and we export the value for the currency_field of the mo
Original PR description
Create a monetary on a model. In studio, remove the currency_field for that field. Note that the currency field would have been create automatically since commit [1] Try to export the studio customization module. Before this commit, there was crash, because the code that retrieves the currency_field was somewhat erroneous and a recordset of ir.model.fields was joined to a recordset of ir.model. After this commit, there is no crash and we export the value for the currency_field of the monetary opw-3677016 Forward-Port-Of: odoo/enterprise#56408
- Better handling of errors in case of undistributed negative lines. - Prevent sending of empty invoice/order/global invoice CFDI - Better mapping of negative lines on positive ones. - Allow adding credit note with invoices inside a global invoice. - Allow auto refund of the global invoice when asking an invoice for a refunded order Forward-Port-Of: odoo/enterprise#55064
Original PR description
- Better handling of errors in case of undistributed negative lines. - Prevent sending of empty invoice/order/global invoice CFDI - Better mapping of negative lines on positive ones. - Allow adding credit note with invoices inside a global invoice. - Allow auto refund of the global invoice when asking an invoice for a refunded order Forward-Port-Of: odoo/enterprise#55064
## Description Domains of the form ```python [('stored_Many2X.id', '=/!=/in/not in', list_of_ids)] ``` will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table. There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly
Original PR description
## Description
Domains of the form
```python
[('stored_Many2X.id', '=/!=/in/not in', list_of_ids)]
```
will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table.
There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly referencing the `field` from the `model`. So in some cases using an explicit `.id` would be a wanted, if the intention was to apply the `ir.rule`.
But in the context of domain in `ir.rule` themselves, the previous concern isn't of application, as `ir.rule` are generated in a `sudo` context, therefor no `ir.rule` are applied.
## Fix
Remove the `.id` from left leafs of domains from `ir.rule`
task-3735923
Forward-Port-Of: odoo/enterprise#56263Most (if not all) dashboards have monetary amounts. They are formatted with the main company currency format. Before this commit, a RPC was made to fetch the company currency. With this commit, the dashboard is loaded with the currency. It saves one network request and a full spreadsheet evaluation (which would have occured after the request is done) Task: 3709466 Forward-Port-Of: odoo/enterprise#55415
Original PR description
Most (if not all) dashboards have monetary amounts. They are formatted with the main company currency format. Before this commit, a RPC was made to fetch the company currency. With this commit, the dashboard is loaded with the currency. It saves one network request and a full spreadsheet evaluation (which would have occured after the request is done) Task: 3709466 Forward-Port-Of: odoo/enterprise#55415
Purpose: -------- This commit adds some tests for the room application which currently has almost none. It also fixes some issues that were pointed out by writing these tests: - Fix reactivity of the booking form view: when a notification of a booking update was received during the edition of a booking, its duration was changed in the sidebar but not in this form view. - Fix luxon locale desync: since the redesign of the frontend view, the locale used when loading the existing bookings wa
Original PR description
Purpose: -------- This commit adds some tests for the room application which currently has almost none. It also fixes some issues that were pointed out by writing these tests: - Fix reactivity of the…
Purpose: -------- This commit adds some tests for the room application which currently has almost none. It also fixes some issues that were pointed out by writing these tests: - Fix reactivity of the booking form view: when a notification of a booking update was received during the edition of a booking, its duration was changed in the sidebar but not in this form view. - Fix luxon locale desync: since the redesign of the frontend view, the locale used when loading the existing bookings was not the same as the one used after it. - Fix current week in the form view: the week was not updated when clicking on a booking in the sidebar while already in the form view. - Fix remaining time flicker: when a booking ended, the remaining time could be minus 1 second for a split second. - Fix remaining time reactivity: when a booking started immediately after that another one ended, the remaining time shown was not updated at the same time than the sidebar and current booking title. Task-3609006 Forward-Port-Of: odoo/enterprise#51351
`_build_query` is a rat's nest of randomly sprinkled `SQL`, which seems to end in the sql injection checker getting confused and non-deterministic. Do some cleaning to try and make it more understandable for the linter. Forward-Port-Of: odoo/enterprise#56367
Original PR description
`_build_query` is a rat's nest of randomly sprinkled `SQL`, which seems to end in the sql injection checker getting confused and non-deterministic. Do some cleaning to try and make it more understandable for the linter. Forward-Port-Of: odoo/enterprise#56367
Sometimes, when handling export of VAT Book (libros) by getting all the lines from the tax report, some of the line might not be ordered as expected. If a tax/surcharge line appear in the list before the base line, this will result in a KeyError when trying to access sheet_line_vals of the id because they have not been created yet. This commit aims to fix that, and also refactor this part of the code to be more clear, clean, & error-proof in the future. An handler for error in the common erro
Original PR description
Sometimes, when handling export of VAT Book (libros) by getting all the lines from the tax report, some of the line might not be ordered as expected. If a tax/surcharge line appear in the list before the base line, this will result in a KeyError when trying to access sheet_line_vals of the id because they have not been created yet. This commit aims to fix that, and also refactor this part of the code to be more clear, clean, & error-proof in the future. An handler for error in the common error place (KeyError) is also written for similar problems we might encounter in the future. task-id: 3703023 Forward-Port-Of: odoo/enterprise#55249
Have a company partner with overdue invoices Create a followup contact for the partner Open the followup report Send followup by post (snailmail) Issue: Letter will be generated without accounting information: the table with overdue invoices will be empty This occurs because the letter will be created with the followup contact being both partner and receiver opw-3631639 Forward-Port-Of: odoo/enterprise#52614
Original PR description
Have a company partner with overdue invoices Create a followup contact for the partner Open the followup report Send followup by post (snailmail) Issue: Letter will be generated without accounting information: the table with overdue invoices will be empty This occurs because the letter will be created with the followup contact being both partner and receiver opw-3631639 Forward-Port-Of: odoo/enterprise#52614
There was an issue with the `copy` feature of the `/clipboard` command. When pasted, the content was formatted as if it was not originally `Odoo` content (and some style features were removed, like the font color). To remedy that, instead of using the `clipboard` API, the deprecated `execCommand('copy')` function is used so that the `copy` handler of the `OdooEditor` is properly triggered and the html content is properly set under the `text/odoo-editor` custom "MIME type". Remark: it
Original PR description
There was an issue with the `copy` feature of the `/clipboard` command. When
pasted, the content was formatted as if it was not originally `Odoo` content
(and some style features were removed, like the font color).
To remedy that, instead of using the `clipboard` API, the deprecated
`execCommand('copy')` function is used so that the `copy` handler of the
`OdooEditor` is properly triggered and the html content is properly set under
the `text/odoo-editor` custom "MIME type".
Remark: it is not possible use that "fake" "MIME type" to write data directly to
the clipboard because it is not officially recognized (will produce an error).
task-3700875
Forward-Port-Of: odoo/enterprise#55127When the user confirms the order and a WhatsApp message is sent using cron this error is produced. Steps to produce: - Install `whatsapp_website_sale` - keep the customer's phone number invalid (E.g. `+1 555-555-5555`) - from the website, add some products and proceed to checkout - try to pay for that order - the error will be produced as an invalid phone number Problem:- When a WhatsApp message is sent using `force_send_by_cron=True` then it must not raise any user error in between
Original PR description
When the user confirms the order and a WhatsApp message is sent using cron this error is produced. Steps to produce: - Install `whatsapp_website_sale` - keep the customer's phone number invalid (E.g.…
When the user confirms the order and a WhatsApp message is sent using cron this error is produced. Steps to produce: - Install `whatsapp_website_sale` - keep the customer's phone number invalid (E.g. `+1 555-555-5555`) - from the website, add some products and proceed to checkout - try to pay for that order - the error will be produced as an invalid phone number Problem:- When a WhatsApp message is sent using `force_send_by_cron=True` then it must not raise any user error in between regardless of a single or multiple records. But for obtaining the value `formatted_number_wa`in `_send_whatsapp_template`, `raise_exception` is `False` only in the case of multiple records and not in the case of a single record, even if the record is sent using cron. Solution:- `raise_exception` must be `False` if `batch_mode` or `force_send_by_cron` is `True`. While calculating `formatted_number_wa` using `wa_phone_validation` the `raise_exception` must be false if the message is sent using cron. Task - 3662747 Forward-Port-Of: odoo/enterprise#53495
Purpose ======= Whether the visitor was a man or a woman, the message sent contained pronoun : he. To avoid this, the new sentence will no longer have a pronoun. task: 3673432 Forward-Port-Of: odoo/enterprise#54546
Original PR description
Purpose ======= Whether the visitor was a man or a woman, the message sent contained pronoun : he. To avoid this, the new sentence will no longer have a pronoun. task: 3673432 Forward-Port-Of: odoo/enterprise#54546
Bug === Before, we needed to mention the author of the Tweet we are replying to, in order to make the Tweet looks like a reply on Twitter. It seems not needed anymore and cause double mention issue (only on the Odoo side, Twitter seems to show only one mention). Task-3686630 Forward-Port-Of: odoo/enterprise#54674
Original PR description
Bug === Before, we needed to mention the author of the Tweet we are replying to, in order to make the Tweet looks like a reply on Twitter. It seems not needed anymore and cause double mention issue (only on the Odoo side, Twitter seems to show only one mention). Task-3686630 Forward-Port-Of: odoo/enterprise#54674