-Instead of having animate options on whole section, make it available
on a column.
-Rename "Disable animation" into "No Animation".
task-2545252
X-original-commit: 9a4d4d1527c004f4157d6c039acdd99f8d7e8231
Part-of: odoo/odoo#76610
Purpose
=======
The work entries generation is not scaling properly
for large employee datasets. A lot of improvements
have been made to reduce the number of query to the
database. However, one of the remaining bottleneck
was the new records insertion, made 1 by 1 on the
database.
Due to the fact that the model doens't have a lot
of columns, and doens't have columns containing
too much data (HTML fields for example), we could
imagine inserting the records by batch, for example
1000 by 1000, as it is done with SELECT.
The results weren't satisfying enough, so we prefered
using the new cron triggers mechanism, to re-trigger
the same cron at the end of its execution in another
transaction, to avoid exceeding the non return point
from which posgreSQL is pedaling in the semoule.
With this commit, it takes less than 30 seconds to
generate the work entries for 1000 employees, instead
of 3 min, and allows to generate the work entries in
a linear execution time instead of a exponential one.
Create method analysis:
=======================
Note, that only the call to the create method is
tracked, not the preprocessing time to retrieve
the work entries values.
When inserting the records 1 by 1:
----------------------------------
records - Elapsed Time (s) - AVG Time per record (s)
10 - 0.0045862197875976 - 0.00045862197875976
432 - 0.1101946830749511 - 0.00025508028489572
192 - 0.0525383949279785 - 0.00027363747358322
522 - 0.1418645381927490 - 0.00027177114596312
892 - 0.2803149223327636 - 0.00031425439723404
8800 - 3.4928441047668457 - 0.00039691410281441
88000 - 188.82338452339172 - 0.00214572027867490
176000 - 1172.4313135147095 - 0.00666154155406084
We observe that from 10.000 new record, the create
method is not scaling anymore before this commit.
For a company with 1000 employees, the mean work
entries by month is 1000*2*21=42.000 work entries,
and the time to create the records is not acceptable.
When inserting the records 1000 by 1000
---------------------------------------
records - Elapsed Time (s) - AVG Time per record (s)
10 - 0.003406763076782 - 0.0003406763076782
432 - 0.075028181076049 - 0.0001736763450834
192 - 0.030718326568603 - 0.0001599912842114
522 - 0.084228038787841 - 0.0001613563961452
892 - 0.145947217941284 - 0.0001636179573332
8800 - 2.204506397247314 - 0.0002505120905962
88000 - 181.9736533164978 - 0.0020678824240511
176000 - 1146.928646564483 - 0.0065166400372981
We observe a sligh improvement, but cleary not enough
and not worth the complexity of inserting the records
in batch on the database.
Note: The following explanation is speculative and could
be validated with a real analysis, but according to the
results we obtained with the cron, this is most likely
to be true.
In fact, this is a limitation of PosgreSQL. In the
implementation that manages the transactions, the number
of inserts becomes greater than certain memory limits,
suddenly it falls on a slower alternative storage (this
is the problem with SELECT and tuples of ids ).
When we inject 100,000 ids into a query, PosgreSQL parses
the query (already there it could have some trouble), then
it stores the ids in a data structure: hash if not too
large, other (on the file system) otherwise. Then it
executes the query and uses the data structure to check
the validity (membership).
Specification
=============
Instead of inserting the record in batch in the same
transaction, it would be more interesting to split the
transaction into several transactions:
Each transaction process N employees who have not yet been
processed, until there are no more. With the new cron
trigger mechanism, it is possible to:
- When the cron runs, it processes N employees
(N to be determined)
- If there is still some, he retriggers itself at the end
of his transaction
Like that, the cron is scheduled 1x / day, but it is
retriggered as many times as necessary each month.
Regarding the number of employees to process, with 100
employees, we can expect:
100 * 2 (morning / evening) * 21 (working days) = 4200
work entries to generate, which is manageable given
the above measures.
closesodoo/odoo#76488
Taskid: 2646056
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this fix, a cash basis OSS tax used together with a product using the "non-EU origin" tag didn't appear properly in the OSS import report. This was due to the fact the product tag was not copied on the cash basis move: it only appeared on the invoice, on non exigible lines.
To fix that, we make the choice to keep the product tag as markup on the invoice, and to copy it to the cash basis lines created from move lines containing this tag. We therefore need a non-ambiguous way to identify account.account.tag objects that are used on products, since we don't want to copy tags used by taxes. Hence, we introduct a new value for the 'applicability' field of account.account.tag, limitating their use to products.
closesodoo/odoo#76626
X-original-commit: 0dd712b876844c3e342447e4cf26b324fcaffc37
Related: odoo/enterprise#20916
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Currently, if the user configures his survey with questions of type
'simple_choice', 'multiple_choice' and 'matrix', but doesn't configure any
selectable choices, the survey result page can crash.
This is not really a "standard" use case but this commit adds a few checks to
avoid a complete traceback and instead give empty data results.
Task-2622869
closesodoo/odoo#75586closesodoo/odoo#76606
X-original-commit: 8051be7c96417cf2feb9d542bb3d230022c8cc54
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Currently, if the survey participant does not answer questions of type:
- simple_choice
- multiple_choice
- matrix
The system does not register any survey.user_input_line with the "skipped"
attribute set to True. Meaning that this question's answer will not appear in
the survey statistics as skipped (in fact it will not appear at all).
This commit makes sure we correctly save a user_input_line set as skipped=True
when not answering to those types of questions.
A unit test has been added to make sure that we consider every non-answered
question type as properly skipped within the survey statistics.
Task-2622869
X-original-commit: 87ea302044ff7ac26888000101254b1af2524046
Part-of: odoo/odoo#76606
Remove the negative tax groups from account_data. The negative tax groups have no application. The taxes that were in the negative tax groups are reassigned to their positive counterparts.
closesodoo/odoo#76586
Signed-off-by: William André (wan) <wan@odoo.com>
Before this PR, the RPC to notify peers was called too much time too quickly.
Reducing request overload significantly improves the overall connection time.
closesodoo/odoo#76625
X-original-commit: f4c1d974b5d55868f81cd3259c45e83d934686f5
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this patch, if you wrote newlines or more than a single whitespace character while sharing any document, in the note, those'd get collapsed in the final email.
@Tecnativa TT31901
closesodoo/odoo#76624
X-original-commit: 6914371e95afff565fa6880f3ff9cf410b357750
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Jairo Llopis <jairo.llopis@tecnativa.com>
Currently we are getting all records of mailing.mailing instead of
getting only records with mailing_type=mail. This bug was produced
by commit[1].
Now we have computed only that records which have mailing_type = mail,
So we can get perfect count in mail stats button in campaign.
commit[1] -> odoo/odoo@3f6625ef13
Task-2417993
closesodoo/odoo#76622
X-original-commit: 4f2924c5fcab672882ca78a9e6eb38b363d2d1b3
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
Open the gantt view and add a few shifts for different resources
Observed behavior:
https://nimb.ws/1t38Jl resources are not sorted by alphabetical order
Expected behavior:
https://nimb.ws/NqIAG3 resources should be sorted by alphabetical order
task-2633936
closesodoo/odoo#76621
X-original-commit: 9c4ed2bcadc417a2927877902c4c275e5d9d16d5
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
While we do want to support the member list for guests in the future,
currently it is not supported so for now we just hide the corresponding
part of the UI.
closesodoo/odoo#76616
X-original-commit: 8d6e82c621b4e211250d0ef4adcc5504d2c2eb1c
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
While we do want to support at least some commands for guests, they
currently aren't supported. This commit stops prompting guests for
commands as they will not work.
X-original-commit: dbad80dbeec5bd76c27dc9dd4b2cb7daaf97b939
Part-of: odoo/odoo#76616
Guest cannot search for partners to invite, this commit stops displaying
the part of the UI that allows that when the current user is a guest.
X-original-commit: 317d912905354eaa2b6cd784fb292bdd51b9bfee
Part-of: odoo/odoo#76616
Previously, guest would not get any error dialogs when errors were
occuring, while the error service and dialog service were correctly
deployed, they were missing the main components container which allows
the dialog service to display the currently opened dialogs. The main
components container also allows the norification and popover services
to work, allowing them to be used for future developments if needed.
X-original-commit: 2a73d441babee25343bf09b5e1a6513afb084c92
Part-of: odoo/odoo#76616
This feature is not available to guests, this commit makes it so that
guests can no longer hover/click on the thread name/description and
attempt to edit it which would not work anyway.
X-original-commit: 099e5cb5126cd741e52e2d45ba4dcddbb2076c1a
Part-of: odoo/odoo#76616
Guest cannot star messages, the button to do this should not be shown to
them.
X-original-commit: 3efd1160271d7e66e986aa0a2a2994a28cbbfb4f
Part-of: odoo/odoo#76616
1. Define a product [TEST] with automated inventory valuation (AVCO)
2. Define a landed cost product in the same way
3. Create a RFQ for [TEST], Confirm and Receive product
4. Create Bill, add the landed cost on the bill
5. Confirm the Bill and create the landed cost (from transfer of point 3)
6. Create a SO for [TEST], confirm, delivery and create the invoice
7. Generate product margin analysis, [TEST] will be present
8. Register a payment for the invoice (it should have the status 'In
Payment')
Generate product margin analysis again, [TEST] entries will be missing
This occur because, when the invoice is in 'in_payment' state the
records are not taken into account
opw-2631974
closesodoo/odoo#76605
X-original-commit: f62c20d38844c50c678e4233913a97845420d766
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
While only notes can be deleted on threads, some tracking messages are
created with the type "notification", some messages are created as
notes. This commit prevents deletion and editing of messages that have
tracking values, as they are invaluable for traceability and not
user-created.
closesodoo/odoo#76593
X-original-commit: b51de3464e3c30ef23f0ee4e8d6128f9ca6ce8b1
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The fix 18ea11c99a7e2bd58d7469927352587cb14c76c4 incorrectly set the rule
o_control_panel .o_cp_bottom_left { display: inline-block } to fix a
problem with the graph view buttons in mobile mode: the graph view has
many buttons and they were put on the same line pushing the view switcher
far too rigth. But the above rule had some other unexpected effects.
For example, an action menu button was put incorrectly on an different line
from the button line. Here we simply fix the css rules that regulate on witch line
the control panel buttons are put and their spacing.
closesodoo/odoo#76620
X-original-commit: 1e308b270b6b1f6612b256db35b188bd0a2f5493
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, if the user searched the command palette and pressed
the enter key without waiting for the rendering, then the command executed was incorrect.
The "inputPromise" promise used to know if the new commands were loaded correctly.
This one did not wait for the resolution "setCommands" called by "onSearchInput".
So we modified the "debouncePromise" utility to make sure that it waits for
the resolution of the function given to it before resolving its promise.
closesodoo/odoo#76613
X-original-commit: 53b905d6993b4e25fec574d92429f2ff91501dfa
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, it is impossible to scroll with the arrows
in the command palette on Firefox.
Using a <span> to wrap the commands made the offsetTop value wrong on
Firefox and the offsetHeight value wrong on Google Chrome.
So we replaced the <span> with a <div> which solves the problems. So we
will be able to use this <div> in the scrollTo and not its child.
X-original-commit: f52eb7ee6b93aef0c5b80744127548b0a2fdb4fd
Part-of: odoo/odoo#76613
This commits adds to the existing conditional visibility option
introduced in [1], the option to display or hide blocs to a user,
depending on if he's logged in or not.
A select widget was added as an alternative to the many2one widgets that
were currently used, as we don't need to connect to the database to
display logged in/logged out option.
[1]: 1c442782f8
task-2618946
closesodoo/odoo#76609
X-original-commit: a42634f8cef57dce0a6a5a09408c3f5823fc647a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
See sub-commits for details.
This merge allows to create and edit gradients instead of just having
the possibility to select pre-defined ones.
task-2599771
closesodoo/odoo#76608
Forward-port-of: odoo/odoo#74045
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit the button custom color colorpickers were not updated
when a color was selected - but this was alright because the
colorpickers did not remain opened.
After this commit the button custom color colorpickers are updated
whenever a color is picked, which is necessary during gradient edition.
task-2599771
X-original-commit: f40c980d7ff68f27b389a93cd2b8f60cbff5baa6
Part-of: odoo/odoo#76608
Before this commit the color palette was updated directly during the
color picking event management.
After this commit picking a color updates the whole UI, and the global
UI update also updates the already opened palettes.
task-2599771
X-original-commit: 5698cf982c7e4499ed8b6f933ad364b9db475922
Part-of: odoo/odoo#76608
Before this commit the colorpicker UI remained unchanged when the
setSelectedColor method was called, and it also triggered a color
preview event.
This was not a visible issue as long as the popup was closed every time
a color was selected, but the popup now remains open when editing a
gradient.
After this commit the colorpicker UI is updated to show the color
changes when setSelectedColor is called, and it does not preview the
color being set.
task-2599771
X-original-commit: 4abf222b532d1f42d9699f400e856b1aaddb92b4
Part-of: odoo/odoo#76608
Before this commit, if there was a Google ReCaptcha public key
registered on the database, it was given to the backend along with
the assets in the `session_info` global key.
Since this key is meant to be used on the frontend to generate recaptcha
tokens, it should be available there as well.
Now, it is also given to the frontend version of the `session_info` key.
closesodoo/odoo#76600
Task: 2639095
X-original-commit: 27136cd09abfb4e012b0df2d53877534cbcdad28
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
* add t-out to set of text-generation attributes
* fix comment location
* don't handroll `iterancestors()`
* only check the `@string` on the toplevel button, doesn't really make
sense that a button would contain a button in the first place (in
fact it's not allowed per the HTML spec, a button can only contain
*non-interactive phrasing content* cf 4.10.6)
Part-of: odoo/odoo#76581
Since mail dependancy has been extracted into a bridge module auth_totp_mail,
the test about "Invite to use 2FA" is misplaced in the wrong module.
This commit moves the test on 2FA invite button to the bridge module and fixes
the test on auth_totp module to use another indicator that 2FA has been disabled
for the currently tested user (see test file).
Task-2645206
Parent Task-2638538
COM PR: odoo/odoo#76381closesodoo/odoo#76579
X-original-commit: 305f94bf1b7ac7c106e05e60601640feca934005
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Assigning a value to an element's classList is bad practice and unpredictable
behaviour. The recommended way of manipulating the classList is to use the
add(), toggle(), and remove() methods instead of direct assignment.
This commit corrects 41f7c7bc which did that multiple times.
closesodoo/odoo#76578
X-original-commit: 0c655afce51e0bd200ba101a183e4bef17c23cae
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
exportLocalState -> getLocalState
exportGlobalState -> getGlobalState
saveParams -> getContext
Moreover, the last one no longer returns an object with a "context"
key, but rather directly returns the context itself.
closesodoo/odoo#76576
X-original-commit: 12111f114c096c50adbb87cea9f1dd97dc16c47d
Related: odoo/enterprise#20894
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit factorizes the sample data logic to the Model and
useModel hook. That way, nothing as to be done in concrete models
anymore.
This commit also ensures that searchParams given to the view are a
deep copy of what relies in the SearchModel. Before this commit,
the PivotModel cloned them in its "load" method. It is now done
in the SearchModel for every views.
X-original-commit: 0f43b7994b6963644cea5b694ba6b07df7af8989
Part-of: odoo/odoo#76576
- PivotModel: methods are protected, not private
- PivotModel: rename meta into metaData (same as in GraphModel)
- GraphView: use the "useEffect" hook
- PivotView and GraphView typo: ArchParser is a class
X-original-commit: 71059a4887cf208552e4932ed2f3b6f53d75c369
Part-of: odoo/odoo#76576
When hovering header cells in the pivot view, the whole column is
highlighted. In comparison mode, a wrong column was highlighted
when hovering a measure.
X-original-commit: 751c2a78d375d67fc7e2cc20342d29188a3d11b5
Part-of: odoo/odoo#76576
Before this commit, it was possible to alter the table while it
was being reloaded (e.g. because a filter had just been applied,
or a measure had just been toggled). Those operations that altered
the table (e.g. sort rows, add groupby, expand group, close group)
typically cancelled the reload, which led to a situation where the
table was frozen, and only another reload from the search could
unfreeze it.
With this commit, we simply ignore all operations on the table
itself when it is being reloaded.
X-original-commit: dcdec74dca65e91998d90e3da0c14d8ee3df1567
Part-of: odoo/odoo#76576
Before this commit, if the user clicked on flip axis while the
data was being reloaded (e.g. just after applying a filter), the
reload was cancelled, and the axis wasn't flipped.
With this commit, we wait for the data to be loaded, and then
flip the axis.
X-original-commit: 5dc0631e339d04cc9f696490e73cf85d45b918fa
Part-of: odoo/odoo#76576
Let's assume the following scenario in a pivot view
- toggle a filter on a slow network s.t. it takes a while to load
- while it's loading, toggle a measure
Before this commit, the view was kind of locked after those two
steps, i.e. toggling measures, expanding groups, flipping axis did
not work anymore (it could be unlocked by interacting again with the
search view though). The reason is that the new filter triggered a
re-rendering of the withSearch component (the parent of the pivot
view), thus calling willUpdateProps on the pivot view, which reloads
the data. Toggling a measure cancels the current load operation
(via keepLast), and the promise returned by willUpdateProps is thus
pending forever. From that point, only another re-rendering from the
parent (withSearch) could unlock the situation by cancelling the
previous rendering.
X-original-commit: b9278e07b9ff01e608ccba6f4602eb9069213a46
Part-of: odoo/odoo#76576
Before this commit, if the user quickly clicked on several measures
(before the reload is over), only the last click was taken into
account. With this commit, all changes are aggregated such that we
only display the final result, with the desired measures.
X-original-commit: a4bae57e1f3b095a4e2d35b3da424c34df59b8dd
Part-of: odoo/odoo#76576
Benjamin Vray