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.
closesodoo/odoo#150601
Task: 3695677
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
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
closesodoo/odoo#153734
X-original-commit: cf035accd8fd633de84c86e2bf426c900c865b9f
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Mehdi Rachico (mera) <mera@odoo.com>
In b69917e[1] the cron implementation was changed to unlink old visitors in
batches of 1000 records. This was meant to deal with memory/timeout
errors when dealing with large amounts of records.
However it still searches for records with no limit, which in high
record count scenarios and based on instance resources may still
generate memory/timeout errors.
Technically it could be considered "fine" for the cron to timeout since
every batch is committed, so previously unlinked records are not rolled
back and the cron should eventually delete them all.
However there are some edge cases where memory/time out errors would not
be fine, like the cron failing during the first batch, which means no
unlink operations would be committed to the database.
Errors that are "fine" also generate noise and leave administrators
wondering which errors they should ignore and which they should not. It
also alarms non-technical customers since after all, they are seeing
a reported error.
Therefore the search limit and batch size have been added as arguments
to the cron. This is completely opt-in since they have the previous
values as their defaults. This makes it easy to customize and tune the
performance of the job accordingly if required.
[1] https://github.com/odoo/odoo/commit/b69917ec0e508f8354d831525c5c48ee79b5967a
X-original-commit: e8a4b1f6a239753f66aa827e8e0d67ca4270dba3
Part-of: odoo/odoo#153707
The onExternalClick custom hook keeps a reference to elements that may
no longer be in the DOM, this can cause entire sections of the DOM that
are no longer needed to be kept in memory, and can also retain the
associated Owl components and their data.
To solve this, we set the downTarget and upTarget to null after calling
the callback. In practice they are no longer used in the code but we are
keeping it for stable compatibility.
closesodoo/odoo#153654
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Previously, when exporting its state so that it could be restored later,
the relational model would export its config. The problem is that
because this config is a reactive object, it keeps a reference to the
components that may need to be notified by that reactive object. This
exported config was then stored on the next controller, which would be
retained by the next config, etc.
This commit fixes that by exporting a raw version of the config.
Part-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
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
closesodoo/odoo#153475
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
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.
closesodoo/odoo#153394
Signed-off-by: Raphael Collet <rco@odoo.com>
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
closesodoo/odoo#153094
X-original-commit: 029b79ad7dc28aab83289e7c3ebd4cc0dcc5d609
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
The commit odoo/odoo@a72007508a 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.
closesodoo/odoo#153013
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
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
closesodoo/odoo#152870
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
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
closesodoo/odoo#152502
X-original-commit: e6fe14dc90af6782693fd5e9dca6f18ecfe7c89a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
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]: 78f6b83b34closesodoo/odoo#152425
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
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)
closesodoo/odoo#151725
Task: 3709466
Related: odoo/enterprise#55415
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
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: see next commit for dashboards.
Part-of: odoo/odoo#151725
- create a from/to date filter with let's say "my filter"
as its title.
- in the spreadsheet, `=ODOO.FILTER.VALUE("my filter")`
=> the function doesn't return anything
closesodoo/odoo#146213
Task: 3584650
Related: odoo/enterprise#52871
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
The implementation to generate a sheet with the active filters
is (almost) duplicated for the Excel export and the sharing.
The next commit makes it more complex and in the goal of avoiding
to duplicate the changes, this commit factorizes the implementation
Task: 3584650
Part-of: odoo/odoo#146213
Issue: When purchasing tickets for an event, if the quantity of tickets
is reduced directly from the cart, payment can be processed for the
reduced number of tickets while the excess registrations remain
incorrectly open in the database.
Steps to Reproduce:
1 Install Events Online Ticketing.
2 Create or select an event with open registrations.
3 Add 3 registrations to your cart and proceed to checkout.
4 In the payment process, go to 'Review Order' and reduce the quantity
of tickets.
5 Complete the checkout and payment.
6 Upon inspecting the database for the same event, you'll notice an
inconsistency: the number of attendees is higher than it should be.
Solution:
This issue arises from the implementation of
`_compute_registration_status`, which only considers the sale order line
and marks registrations as cancelled only if the entire order line is
cancelled. This means either all 3 registrations are cancelled, or none.
The solution introduced here addresses this by checking for
registrations already marked as cancelled and incorporating them into
the cancellation logic, ensuring accurate tracking of active and
cancelled registrations.
opw-3653452
closesodoo/odoo#150463
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
Before this commit:
When the user creates new stages or groups in Kanban view and adds new tasks
with particular states and then if the user clicks on any colour in the
progressbar then the filter gets applied on all the groups or stages.
Observerd Behaviour:
The filter is applied on all the groups or stages.So, if we click on a colour
in the progressbar suppose colour Green to filter out Approved task(s) of a
particular stage then in that stage or group only the Approved task(s) would be
visible. Also the filter would get applied on all other stages or groups created
at that time. In those stages all the task with that state would be visible and
rest of them would get blurred.
Steps to produce:
- Install `Project` and add a new project in it.
- In the newly created project add some new stages or groups, each consisting
some new tasks.
- Give some states to those tasks through project state selector
(for eg: Approved, Changes Requested).
- Click on any particular colour in the `Progressbar` of any particular group or
stage.
Expected Behaviour:
When the user clicks on any colour in the progressbar then it should filter out
only those tasks which are associated with that color/state and only in that
particular group or stage.
Reason:
https://github.com/odoo/odoo/blob/579ee6d9792050955fa80346fd57ad294efcdd62/addons/web/static/src/views/kanban/progress_bar_hook.js#L114
group.serverValue results as Undefined. Because when the data is being prepared
here:
https://github.com/odoo/odoo/blob/493d5c39982de79e6fb256dd8084bf592a740f77/addons/web/static/src/model/relational_model/dynamic_group_list.js#L222-L231C11
there is no serverValue provided. So, whenever a group is getting created
here serverValue `Undefined` as value.
https://github.com/odoo/odoo/blob/493d5c39982de79e6fb256dd8084bf592a740f77/addons/web/static/src/model/relational_model/group.js#L25
Note:
- There was a need to change the function name from
`getServerValueFromGroupData` to getGroupServerValue as now now this function
calculates serverValue while the data is being created and not when the data is
already created.
- The function is exported into another file as this function defines the basis
to calculate serverValue and there is a necessity to calculate serverValue while
data is being created.
Task-3620697
closesodoo/odoo#149694
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When reading values in reactive objects, Owl's reactivity system will
return reactive versions of the sub-objects to allow tracking reads in
depth, so that changes to values in deep object hierarchies can still
cause components to render themselves if needed.
Luxon objects are immutable. Since they cannot change and values inside
them cannot change either, tracking reads within luxon objects is pure
overhead.
This commit makes luxon objects non reactifiable by setting the
Symbol.toStringTag property on the luxon classes, which is what Owl uses
internally to determine if objects can be made reactive. It will also
cause some of these objects to serialize to more specific strings
instead of just [object Object], eg [object LuxonZone].
closesodoo/odoo#153540
X-original-commit: ac58cb22cd8b275f89bf387a6cea8144ce26ee65
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Issue:
======
Some templates that contains an image have wrong width and it can't be
updated.
Steps to reproduce the issue:
=============================
- Use a view with width < 1135px
- Go to email marketing
- Create a new mailing
- Use the welcome message template
- The size of the signature is wrong and you can't update it
Origin of the issue:
====================
There is an applied style which fixed the minimum width to 100% if the
img is alone inside the parent element (has no siblings)
https://github.com/odoo/odoo/blob/749133f3170f795c9deabc6ad6f7684baa76db59/addons/mass_mailing/data/mailing_data_templates.xml#L98
Solution:
=========
Add `img-fluid` class to some `img` elements to keep the layout correct.
task-3718618
closesodoo/odoo#153508
X-original-commit: 1126a8103d56b8587b793735f08b4a5917a0d15c
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Prior to this commit, Gift cards assigned to a specific partner were
restricted for use only by that partner. This commit rectifies the
issue, enabling Gift cards to be usable by any customer as intended.
opw-3689391
closesodoo/odoo#153507
X-original-commit: 15c79c3f46bcc6787efc950bd3a9a122b298f919
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Previously, the order line quantity would inadvertently update if the
Customer list screen was opened without clicking the search bar and
typing numbers. This commit resolves the issue by disabling the event
handler while a temp screen is open. Also, it enhances usability by
focusing on the search bar upon opening the Customer list screen.
opw-3634910
closesodoo/odoo#153506
X-original-commit: d792bb4b28c16b19452b7dcf06e73459ed9b8312
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Have a grouped list view s.t. there's a group with enough records
to have a pager in the group. Go to the second page of that group.
Then, apply a filter such that there's only a single page remaining
in the group. Before this commit, no record was displayed, because
the previous offset wasn't reset to 0 it should have been. With
this commit, the offset is recursively reset, so we correctly
display the records of the first page after a reload.
closesodoo/odoo#153494
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
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
closesodoo/odoo#153450
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
The version of werkzeug installed can vary from one deployment
to another, as we recommend to use the operating system package,
and the version can therefore change according to the operating
system version.
e.g. the werkzeug version installed using
`apt install python3-werkzeug` varies between
Ubuntu 18.04, 20.04, 22.04, 23.10, ...
We want to keep under control the attributes
developers use on werkzeug.wrappers.Request,
to avoid compatibility issues from one
version to another.
Therefore, this revision aims
to subclass werkzeug.wrappers.Request to limit
the attributes which can be used.
task-3734305
Part-of: odoo/odoo#78857
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
In order to not add steps in the history when changing the slides of a
carousel, commit [1] added listeners that would deactivate the observer
when sliding and reactivate it when the slide is over, in the `slider`
public widget. These listeners are then removed at destroy.
However, the way they are removed breaks some of the carousel behaviors:
- Drop a "Carousel" snippet.
- Change any "Carousel" option (so not a "Slide" one). For example, set
the "Height" to 50% or add a conditional visibility.
- Slide the carousel (with any arrow).
=> The slide number did not update correctly.
- Remove a slide with the "-" button.
=> The slide was not removed.
It happens because, when this widget is destroyed, it removes all the
`.carousel` listeners, which means that it also removes the listeners
added at the `Carousel` options start. And since the widget is destroyed
and restarted every time an option is changed, but the "Carousel"
options are started only once at the beginning, the removed listeners
are never added back (until the next start of the options).
This commit adds an id to the events managing the sliding history, to
make them more specific, in order to only remove these ones when the
widget is destroyed.
[1]: https://github.com/odoo/odoo/commit/14bc1a9bd1ebdec3b73e268450267320b79d01cd
opw-3675019
closesodoo/odoo#153578
X-original-commit: 041935aff660ae5df1220e3d844d2a2cbcf4ee5c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
To reproduce:
- Put your fiscal year to the 30th of December (yes it's unlikely)
- Create an asset
- Compute depreciations
=> they are created for the 31th of December
It comes from the `get_fiscal_year` in `date_utils` which considers it as the case of the 28th of February
opw-3704466
closesodoo/odoo#153528
X-original-commit: cd0bb178441790e7e33c0d1c01b7ade82d4ab8c0
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
It is possible to have context keys being leaked from outside the
context manager in the following case:
* a new transaction starts with a new environment
* the code calls `_disable_recursion`
* all the existing environment are modified with the context key
* inside of the context manager, a new environment is created without
specifying a full context: we keep the previous one, which contains
the context key
* the code exits the context manager and cleans all the environment it
was aware of <-- this is the issue
* the environment that was created inside the context manager still
contains the context key, if it is used and is never cleaned.
Now, we also remove the context key of all the environments created
inside the context manager.
It is better to risk having some recursion (probably leading to
operations being done multiple times) than doing nothing at all because
the context disables some features.
closesodoo/odoo#153526
X-original-commit: 664ae6b1a4dceca2d77eca8d8a24d47c6b3949a7
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Summary:
========
1. Handle the inverse fields of `account.full.reconcile` manually
2. Batch the update of matching numbers
3. Batch the balance consistency test
4. Batch the construction of reconciliation batches
5. Precompute fields on partials
6. Avoid recomputation of same default analytic distributions
7. Cache the accounting date wrt lock date
1: Handle the inverse fields of `account.full.reconcile` manually
-----------------------------------------------------------------
In order to update the inverse fields of `reconciled_line_ids` and
`partial_reconcile_ids`, the ORM is triggering one query per full
reconcile record. In the case of a big batch payment, that is a lot of
round trips.
This also bypasses the computation for possible tracking, which is
expensive to do for 2 records at a time. That field is not tracked
anyway.
2: Batch the update of matching numbers
---------------------------------------
Basically the same as 1. without the tracking.
3: Batch the balance consistency test
-------------------------------------
Use the various context managers around `__reconcile_plan` to check for
the balance consistency only at the end in one single query. This avoids
checking it at every single intermediate write done on the lines.
Also doing it for the sync of dynamic lines. It should be useless but it
doesn't cost anything, and allows to remove the context keys in
enterprise without a cost. (they shouldn't be used explicitly, the
context managers should always be used instead)
Using these context managers also allows to remove all the `skip_`
context keys, which should not be used: using them will mean that as
soon as the journal entry is modified for any reason, some business
fields will change because of the synchronisation since the context
won't be the same anymore.
This commit therefore also makes `_sync_dynamic_line` more resilient and
avoids even more useless syncs.
4: Batch the construction of reconciliation batches
---------------------------------------------------
Introduce `_reconciled_by_number`, which is basically a `_read_group`.
In conjuction with `_filter_reconciled_by_number`, we can find all the
reconciled lines in one single query, for as many batches as needed; as
opposed to one query per batch before.
5: Precompute fields on partials
--------------------------------
Simply avoid doing one batched `INSERT INTO` followed by one `UPDATE` for
each record.
6: Avoid recomputation of same default analytic distributions
-------------------------------------------------------------
Not really linked to the reconciliation, but when a lot of lines are
using the same parameters for the default analytic distribution, it is
useless to re-compute it multiple times.
Can speed up the population of test data for instance.
7: Cache the accounting date wrt lock date
------------------------------------------
When preparing the create values for the exchange moves, computing the
date with regards to the lock date once per move is very expensive.
By creating a context dependent field, we can cache the value and avoid
doing the same operation multiple times.
Benchmark:
==========
We are testing 2 use cases:
* a lot of small matchings that are producing a full 2 by 2
* one big matching (also producing a full)
To reconcile a batch payment of 500 (identical) lines in the bank reco:
| | Queries | SQL | Other |
|--------|---------|-------|--------|
| Before | 4191 | 4.649 | 16.253 |
| After | 226 | 0.989 | 3.581 |
To reconcile one big batch of 1000 lines with the generic reco widget
(spaghetti):
| | Queries | SQL | Other |
|--------|---------|-------|-------|
| Before | 82 | 0.478 | 1.131 |
| After | 66 | 0.634 | 0.974 |
To reconcile a batch of 1000 lines *in foreign currency*
| | Queries | SQL | Other |
|--------|---------|-------|-------|
| Before | | | |
| After | 45995 | 125.0 | 146.3 |
All the times are in seconds.
We can see the the use case of the batch payment is improved a lot (the
time is expected to be linear with regards to the number of payments),
while the time for big batches is not impacted.
closesodoo/odoo#152284
Related: odoo/enterprise#55633
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Steps:
- Install project.
- Go to settings and select Custom Email Servers.
- Add alias domain.
- Then go to the project.
- Create a new project.
- The gap between the email alias and project title is too much.
Issue:
-When we create a new project the gap between the email alias and project name is too
much when only the project is installed and there are no options to display.
Cause:
-The "margin-top-4" taking much space.
Fix:
-After this commit the space between email alias and project name is decreased
by changing the space.
task-3550638
closesodoo/odoo#153277
X-original-commit: b01b2f2f4d2e31648e3c98b8991eaafc886ca542
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
A user that is not admin cannot create an mail.alias.
We can create the alias in sudo since we control the default_values and
model that are created with the new alias.
Check the _check_alias_domain_id_mc constraint in sudo because non amdin
user cannot read model ir.model.
closesodoo/odoo#153222
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Steps to reproduce:
- insert a global filter with double quotes in its name (e.g. my "special"
filter)
- reference that filter with ODOO.FILTER.VALUE (remember you have to escape
the " in the formula with a backslash \
=ODOO.FILTER.VALUE("my \"special\" filter")
=> the filter is not found
closesodoo/odoo#153337
Task: 3697855
X-original-commit: 83826d3546ff584c5ff22021370f572787d032bc
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
In this commit, the mobile/phone number is in sync with the partner
if the partner is not there then it will be generated based on the applicant
information
Task-3635976
closesodoo/odoo#150820
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Oversight in 06919a232251cbd68a28500757aef5cd2e3363a0
Need to handle `default_child_ids` and `default_tag_ids` as well.
closesodoo/odoo#153397
X-original-commit: 7d521b129c82e38afe50cd8b81cb2081c157aceb
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Before this PR, the `test_complete_chatbot_flow_ui` would sometimes fail
when checking if the user can add a reaction to a message.
There are two issues:
- This step uses the `contains` helper and specify the live chat `ShadowRoot`
as the target. However, the `contains` helper uses a mutation observer
that observes the light DOM thus, changes in the shadow root are not
correctly observed.
- The target passed to the `contains` helper is the `ChatWindow` DOM
element but this element can be unmounted in-between.
This PR fixes this issue.
fixes runbot-56670
closesodoo/odoo#153382
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit addresses an issue where, upon application to an invoice,
the Receivables, while accurate in terms of Amounts and Due Dates,
have incorrect labels.
The root cause of this problem was identified in the compute_name method
of the account.move.line model. The modifications in this commit
rectify the compute_name method to ensure that payment terms labels are
computed correctly.
task-3636484
closesodoo/odoo#153364
X-original-commit: 59c0350b55b11321ba49e1ae4124eb5828d5f665
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce
- Install Sales, Accounting and purchase apps
- Go to Settings and activate Analytic Accounting option.
- Create a product that can be expensed and that is re-invoiced at cost + add cost
- Create an SO with another product and add an analytic account (activate analytic accounting if not activated by default) + confirm
- Create a PO with the expensable product and add the analytic account in the PO lines
- Receive product + create bill
- The product is added in the SO with 0 quantity and if I change the quantity to one, the price is recomputed according to the sales price (instead of taking into account the cost).
Investigation
- The `_compute_price_unit()` method doesn't take into account if the so line has been expensed or not
opw-3671812
closesodoo/odoo#153358
X-original-commit: 059b19c59a9222b676be5246eb94d680cf6bf27b
Signed-off-by: Ali Hassan Youssef (alhy) <alhy@odoo.com>
Before this commit, users without admin access rights were unable to
generate invoices.
opw-3701291
closesodoo/odoo#153350
X-original-commit: 27ad4379364b481276a6597bb9fab9778f07fd5f
Signed-off-by: William André (wan) <wan@odoo.com>
Addresses the issue where mandates returned by Stripe were not
being saved in the database, rendering them unused. The fix
involves retrieving mandate information from the charge object
in Stripe, as the mandate data is included in the payment method
details of the charge object, rather than in the payment methods
object.
task-3594745
closesodoo/odoo#153329
X-original-commit: 1db395eb8a12058702b5e7dbd7213c65ae2ac52b
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Previously, when changing the tag of a text node within a list, it transferred
the list's attributes to the newly created tag. Ideally, this should only carry
over the attributes of paragraph-related elements and not of lists.
task-3609500
closesodoo/odoo#153328
X-original-commit: 58829be8fee0d3330427a467c62280b6d6edb147
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Commit [1] changed the code in toggleList such that variable block could not be
a block. This commit updates the name of variable block to nodeToToggle.
[1]: d314fb6a6ceb6bade38a2a6b3e0e2e3fd016b7d9
task-3609500
X-original-commit: b863fff7d8e62dc28d8e5de20dffea6896dc188a
Part-of: odoo/odoo#153328
Prior to this commit, adding more than one pricelist to the available
pricelists and attempting to create a partner from the Point of Sale
would result in an error.
opw-3703269
closesodoo/odoo#153314
X-original-commit: 462ff7c657c22c29ffc2c522afdc9fd99068d6fb
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Steps to reproduce
------------------
* create the following hierarchy of companies:
```
Company
└── Branch A
└── Branch B
```
* delete `Branch A`
From then on, whatever you do will result in a Bad Request response.
opw-3662711
closesodoo/odoo#153264
X-original-commit: da803db384ec809a9c68dd379bf3c03f00d5a731
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
So far when new employee was created from applicant he got a mail
with notification about employee creation. It's not a desired behaviour
so this change makes just a log note about it.
task-3621545
closesodoo/odoo#153227
X-original-commit: 7b1dce2ef4a47870897847fb06ba8fe3cb199109
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
jbw-odoo