Prior to this fix:
- Archived users are no more shown in the assignees
After this commit:
- All users, including archived ones will be shown in the assignees.
task-2703358
closesodoo/odoo#80783
X-original-commit: d6092e318e04619313851276865b333afd264aad
Related: odoo/enterprise#22689
Signed-off-by: Xavier <xbo@odoo.com>
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
A bug was introduced in FR localization after the implementation of
refund feature in point_of_sale module, that is, any order can now
be deleted. However, we don't want this in the localization.
This fix restores the error message that prevents the deletion of
of any order made under the FR localization. However, this time,
instead of only preventing the current order to be deleted, we
keep every order with orderlines from being deleted.
closesodoo/odoo#80773
X-original-commit: 30b48094fb59f564b923e34a3df379f8ff0610de
Signed-off-by: Masereel Pierre <pim@odoo.com>
Before this commit, there was an issue with the edition of links that
were already in the page, via the link tools.
1/ In edit mode, drag and drop the s_image_text snippet and save,
2/ Click on edit, click on the "learn more" button,
3/ From the link tools, change the style to secondary,
4/ Click on save again, the button is still styled with as primary.
[1] added a history step to the link creation via the link tools. As the
editor observer is set to unactive at the start of the link tools, the
changes made to the link with the link tools were not processed by the
EditPageMenu observer, and the block was not set as .o_dirty (the
changes were therefore not saved).
This bug was hidden by our use of bootstrap popovers. The
aria-describedby attribute, managed by bootstrap when showing/hiding a
popover, would be recorded as a change from the EditPageMenu observer,
which would set the view as dirty.
Also, changing any other element of the page would set the page as dirty
and hide the bug.
It only became visible when [2] changed the popover initialization from
'focus' to 'manual'. With that, the aria-describedby attribute was
modified inbetween the LinkTools.start and LinkTools.destroy (and was
therefore not recorded at the EditPageMenu level).
To record correctly the changes made from the link tools to the link, we
activate the editor observer when applying the changes to the DOM.
This commit also introduces some tests for the link tools.
The listener on customizable links from the wysiwyg was changed from
mousedown to click for simpler tests.
task-2680461
[1]: 6db6134f97
[2]: 161c5fc8e742294e8d85c889b4bf8d3d8cd484f5
closesodoo/odoo#80763
X-original-commit: c29fe9fa8fc8ff4a5e6f042607ef9b3070d1d339
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When editing the link label from a website page, and then changing its
url from the link tools, the label was reset to what it was before the
edition. This commit fixes it by keeping the label consistent when
changing the link options from the link tools.
task-2680461
X-original-commit: 5f5b9dfa1bdfb6c814e68e355503a8820bb8b452
Part-of: odoo/odoo#80763
It was painful to add an inline snippets, or move elements inside mega
menus. The dropdowns are now behaving as modals: if they are shown, the
user can only add or move snippets inside them, but not outside.
task-2668908
closesodoo/odoo#80757
X-original-commit: edc5c8d69fb5fc6da0b0012abc6539c21ffc421e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Performances issues have been noticed in account_fleet when computing
the move_ids of vehicles.
This change has been made in order to fix this issue.
Task id #2700407closesodoo/odoo#80755
X-original-commit: 2860051b3cbfa7bcd7df76d05b4e5770e9a4c2d0
Signed-off-by: William André (wan) <wan@odoo.com>
When a rating is posted in the chatter, the alt text for the image is displayed as a score out of 10.
However, the maximum score a rating can have is 5.
This commit changes the alt text to display a score out of 5 instead.
closesodoo/odoo#80753
X-original-commit: 42848c6c3d17de59adb85bf6622f629809cb37c4
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Purpose
=======
This is the first step of a technical cleaning of the sales
application. The final goal is to reduce the technical debt
and improve the performances / readability of the related
applications.
Some complex onchange methods containing purely business code
are defined, and called manually wherever the modifications
should be applied. This is a bad practice as there could be
a different business logic when making the same flow in the
interface or with python code.
Since #80449, it is now possible to add the precompute attribute on
stored computed fields to compute them before the insertion into the
database.
The idea is to convert this business code into compute methods to
apply it every time this is needed.
This is quite useful in our case in the sales application, as some of
the computed fields are required, and request some hacky overrides:
- in the create method, to simulate the onchange on new records, and
to update the values dictionary
- in the default_get method, to set a default value, which has to
side effect to prevent the field to be recomputed afterwards, which
could also lead to inconsistencies.
This made impossible to convert the onchange methods into compute
methods.
Now, that is possible to precompute the fields before the database
insertion, it is now possible to remove all this crappy overhead,
to benefit from the batch method definitions, and to avoid creating
fake records to simulate the values that we should have computed
before.
On the other hand, this is the occasion to write some methods
(create, ...) in batch, to remove some dead code, to simplify
the api, to reorganize the code using our coding guidelines.
Results
======
The benefit of calling the computes in batch doesn't only bring
functional consistencies, it also allow to improve the performances
without changing any existing features.
For example, let's have a look at the execution time and queries to
generate 1000 sales orders with 10 products lines each + 1 section
line, for 1000 different customers and shared between 2 salesmen.
We consider the "batch" time, aka the time to call the "create" method,
the flush time and the number of SQL queries.
In master:
BATCH: 121.97 seconds
FLUSH: 24.05 seconds
# queries: 53103
Now:
BATCH: 113.07 seconds
FLUSH: 1.22 seconds
# queries 22057
This means a reduction of:
- 7.2% for the batch time
- 95% of the flush time
- 21.7% for the total time
- 58.5% for the number of SQL queries
Note that the effect of the precompute, the onchange methods
conversions, and the optimizations on this PR are emphasized
when the sales orders are related to the same partners.
If we take a look at the flamegraphs when creating 100 sales orders
of 3 lines each, we directly spot that the methods are now called once,
which also justify the large decrease of execution time and SQL queries.
Master:
Now:
closesodoo/odoo#79093
Taskid: 2679099
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Victor Feyens vfe@odoo.com
Before this revision, when a payment was declined,
for instance because the authorization is declined by the bank,
or the credit card amount limit is exceeded,
the error was marked as
"Received data with invalid payment status: 2"
which is not very meaningful for the users.
This revision aims to set the reason why the payment
was declined with the meaningful error from ogone.
closesodoo/odoo#80742
X-original-commit: 758f94a173379ba7bd22813b2050e3a6f98210a9
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Compute was never called because of the compute, which lead to wrong
values (raising due to the SQL constraints).
Integrate the default in the compute directly.
* remove useless hook _get_customer_lead, since the field is now
computed
* Add inverse to properly modify existing stock moves when the customer
delay is modified
Laurent Stukkens (LTU)
