This commit revamps the UX of the StateSelection field widget. Now, instead
of filtering the options by removing the current selected value, the field
displays the entire list in the dropdown, and the selected item has a
checkmark to indicate its status.
This allows us to remove the tooltip, since its presence was not useful
anymore, and was unintuitive to use. This changes required to adapt some
tests asserting its presence, as well as the number of items shown in the
dropdown menu.
task #3177182closesodoo/odoo#113203
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit the message was only containing a message 'Personal
information update.' but it was not clear why the person was receiving
this message nor why he was receiving it.
closesodoo/odoo#113550
X-original-commit: de0061326bbd9e2fc5319c05448395afa5b71afe
Related: odoo/enterprise#37492
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit only adds the missing test from the original PR
since the feature was added back in without the test
opw-3032052
closesodoo/odoo#113562
X-original-commit: 542516b6b07c44e08b21271fbc9129c446e12c1b
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
There was an error in the XML template of the 'department_chart', the
opening tag was a <div> but closed with a </t>
sentry-3951803776
closesodoo/odoo#113543
X-original-commit: 2ea1efb20861c1cbd1d3a19ef9b4ef54385effed
Signed-off-by: Adrien Widart <awt@odoo.com>
In one of the previous commits from v15.5 the account code was improved but it
created a bug for Account Payment Terms .As we know odoo has defined default
Decimal Accuracy for Payment Terms is 6 and even on changing the decimal
accuracy for Payment Terms. The field Value in account_payment_term only
showed 2 decimal points because of the changes made in a previous commit.
We have fixed it by removing the digits attribute from the
account_payment_term view
Commit link-
https://github.com/odoo/odoo/commit/3dad4b3cb1cb823ae6ccbf56b990012ceca61d99
opw-3200888
closesodoo/odoo#113542
X-original-commit: 049c628945278477b35984864cfb19128892142f
Signed-off-by: Josse Colpaert <jco@odoo.com>
When loading a module, the code in the tests directories should not be
loaded.
One does not need freezegun on a server without running the tests.
closesodoo/odoo#113536
X-original-commit: 705c5d5dd9b76850638bd5d36b8395314ba78248
Related: odoo/enterprise#37481
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Sale Analysis report shows prices in company currency, converting foreign currency into the company currency according to the currency exchange rate.
Currently, the currency conversion is done incorrectly.
For example let's say 1 EUR = 25 CZK OR 1 CZK = 0.04 EUR.
Sales order: 39 EUR = 975 CZK.
Sales Analysis report shows 1.56.
This is because we are trying to multiply the order amount by 0.04, while it should be divided.
It used to be divided up until 16.0.
This commit changes the operator to convert the currency correctly.
opw-3167522
closesodoo/odoo#113525
X-original-commit: ef57d53866dc1d404138809132176c79d60a3b51
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute field ``email_add_signature`` in
compute method.
When having a template, consider it defines completely body and do not add
signature. Without template, add signature by default in comment due to post
processing for notification emails. Mailing mode does not handle signature.
Followup of odoo/odoo#107356
Task-2088884 (Mail: Use editable computed stored fields in composer)
closesodoo/odoo#113522
Related: odoo/enterprise#37478
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Inactive users should not be added in followers of records, especially using
automated subscription. Indeed they mainly generate noise in notification
process and are generally skipped.
Few use case exists of inactive users creating records. One use case is the
mailgateway running as root but a context key 'mail_create_nosubscribe' is
used to avoid it. Other use cases include automated action for example who
are also generally protected.
Anyway better be sure and consider this is a standard use case. To extend
this rationale, inactive people are currently not added when posting. It
therefore makes sense to keep this behavior coherent through the mail stack.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#113522
Currently an inactive user that creates records is added in followers. Standard
use case is the mailgateway but it has the 'mail_create_nosubscribe' context
key that avoids the mailgateway user to be added in followers automatically.
A test is added without the context key that shows that inactive users are
added as follower when creating a record. This is due to the direct call
to '_insert_followers' that does not perform any filtering on inactive users.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#113522
Allow to return <mail.mail> records and found outgoing emails when using
asserts. It eases doing checks in some specific tests e.g. checking
notification layout usage in emails. Indeed this is quite low level and
does not really deserves its own assert tooling methods.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#113522
In this commit:
- project tasks kanban view: if partner_is_company, we display partner_id
else commercial_partner_id -> this information is useless so we decided to
display partner_id in both cases.
- manager_id is not used in any view -> drop the field
- when creating a task by mail, email_from is set to the sender email then will
be changed depending on partner_id and parent_id, the field name is not significant
as it change and no more contain the original email sender, it's also a duplicated
information that can be got from partner / parent -> delete the field and create
a new partner if no one already exist with the same email.
- when project.analytic_account_id is changed, only tasks that have the same old
analytic_account_id will follow the name value -> we decided to change the behavior
and apply the new value for all tasks.
- project_analytic_account_id not used in any view and in only place in python
-> delete field
- project.project: partner_email, partner_phone are not used in any view ->
delete field
- project.task: partner_email not used -> delete field
- ancestor_id is no more used in any view or python reference as it's a complicated
field to understand by users -> remove ancestor_id from project.task and remove also
ancestor_task_id that is related it to it in timesheet context and replace it with
parent_task_id which is more simpler to understand by users.
task-3103701
closesodoo/odoo#110101
Related: odoo/enterprise#37246
Related: odoo/upgrade#4269
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
As with fieldsToFetch in commit 25bf5a3fabfa9da5367e82d1c5713425c77bc373,
we will convert fieldDependencies into an array of fields.
We did it because it's easier to use and more natural to has an array.
Part of task 3179751
closesodoo/odoo#113482
Related: odoo/enterprise#37449
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When using the ControlPanel's bottom-right slot in another component, if
`viewSwitcherEntries` wasn't defined in `env.config` it would raise a
traceback, as the template would try to check an `undefined`'s length.
Removed the workaround that added an empty `viewSwitcherEntries` in the
forecast report and the bom overview report since it's no longer
necessary.
closesodoo/odoo#112415
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adds an icon on hover of sections inside the questions ListView
to indicate more clearly to the user that they can edit these lines.
task-2988062
closesodoo/odoo#108731
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add an external code field on the hr_work_entry model to have
a custom code when exporting the work entries to another system.
task-2929493
closesodoo/odoo#104326
Related: odoo/upgrade#3998
Related: odoo/enterprise#33337
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Finland is comprised in the EAS list but is not currently supported in
Odoo. This commit makes UBL Bis 3 available for Finnish companies.
opw-3178684
closesodoo/odoo#113509
X-original-commit: 6ade738c2fc63c824adee570886376019459ab73
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Steps to reproduce:
- Create a new journal Bank
- In Sequence, find the 'New Bank Check" and edit it so the sequence can be 10 number digits long
- Create a Vendor Payments with the the New Banck and Check as a method
- Click on Print a check
- Set any number > 2147483647 and validate
Issue:
Traceback
Cause:
The query SQL make a check to verifiy that the number is correct ('025'::integer == '25'::integer but '025'!='25)
But using INTEGER limits the number up to 2147483647 (https://www.postgresql.org/docs/current/datatype-numeric.html)
Solution:
Use BIGINT whose limit is 9223372036854775807
opw-3140973
closesodoo/odoo#113499
X-original-commit: 49dd9dffd7b96fd90860123f8b3f0e623979b246
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Currently, when editing a report line, it's possible to create
a new expression with a label already used on the same report line.
This is problematic as the columns are using the expression label
to select the right expression. Indeed, one expression is going
to be selected but there isn't any obvious way to guess which one.
The solution is to add an SQL constraint on the report line expression.
task-3199014
closesodoo/odoo#113222
Signed-off-by: John Laterre (jol) <jol@odoo.com>
This commit aims to simplify the extractProps api by removing "field".
The Field will need to go into
this.props.record.fields[this.props.fieldname] to access the information
previously stored in the "field" parameter.
Part of Task: 3179751
closesodoo/odoo#113214
Related: odoo/enterprise#37469
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Allows model to provide default values for auto creation of related res_partner
such as name, title, ... It avoids the user to enter the information twice.
Use the newly introduced mechanism for crm.lead to prepopulate auto created
res_partner:
- when selecting a suggested recipient, by prefilling the simplified form (job
position, phone, ...) along with non modifiable data that will also be used to
populate the res.partner like the address, website, ...
- when selecting a template for a message on a lead without a partner, the
partner is automatically created with values from the lead: email, phone,
address, ...
Task-3024050
closesodoo/odoo#105111
Related: odoo/enterprise#33687
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This fixes the problem of the full res_partner form being displayed instead of
the simplified one in some cases (and vice-versa).
The problem can be reproduced by the following steps:
- launch odoo without xml dev_mode enabled (otherwise the cache is disabled)
- in helpdesk, go to an existing ticket and click on an existing customer (this
will load the full form for the customer into cache)
- create a new ticket by first completing name and customer name, save it
- complete the email address, save it
- go to "Send message" and click on the email checkbox
- the full form is loaded instead of the simplified one
(base.view_partner_simple_form)
It is also possible to get the simple form instead of the full form by
reversing the order of the visited forms.
Technical note: The problem has been fixed by adding the context key
"force_email" as cache key using _get_view_cache_key override. Indeed,
_get_view_cache uses _get_view which result depends on that context variable in
its redefinition in res_partner.
Task-3024050
Part-of: odoo/odoo#105111
When the contact name was not yet set, the email was displayed twice in the
composer: first as the contact name and then as the email in parentheses. Now
when the contact is the same as the email, nothing is displayed in parentheses.
Technical note: the regexp in the mail util parseEmail method has been slightly
modified because it was returning in some cases the name surrounded by quotes
(ex.: "newlead3@ex.com" <newlead3@ex.com> --> name: "newlead3@ex.com"). This is
no longer the case with this change. That change was needed for comparing the
name and the email to avoid to display the same thing twice (when the email and
the name are the same). Note that the method is only used once, where we have
done the change.
Task-3024050
Part-of: odoo/odoo#105111
Selecting a recipient for which there exists no partner trigger a partner form
dialog creation. For some model (ex.: crm.lead), some default values can be
prefilled from the current record. This is what we do here by calling a generic
mechanism that allows each model to define default value for related partner.
Note that we don't provide a more detailed form to the user because some will
otherwise feel obligated to fill it out entirely.
Technical note: As there is no need for a custom form per model from which the
data are extracted to populate the related partner, the simplified partner form
(view_partner_simple_form) is just augmented with additional invisible field by
modules that add fields to partner and need to populate them automatically from
values of another model.
Technical note: In TestCRMLead.test_message_recipient_partner_auto_creation, we
test that the _message_get_suggested_recipients returns the correct default
values to copy some fields from the lead to the partner to avoid the user to
reenter them. But we don't test specifically that it also work when using mail
composer and template (which generate the partner) because it has already been
tested when introducing the mechanism. Although, we verify that it should
behave the same because we verify that the default values returned by
_get_customer_information, that is used in mail template when using the
composer, are the same as the ones returned by _message_get_suggested_recipients
which is tested here.
Task-3024050
Part-of: odoo/odoo#105111
Define information taken from the lead when a partner is automatically
created from it. It avoids the user to enter the information twice and
automated partner creation now correctly takes information when possible.
Task-3024050
Part-of: odoo/odoo#105111
Allow model to provide default values for auto creation of related res_partner
such as name, title, company_id, ...
It is used when claling 'Partner._find_or_create_from_emails()' that now
accepts custom data when creating partners based on a given email_normalized.
This allows notably to flatten a loop due to multi-company when creating
partners from emails in template management. It is now done using this email
based dict allowing to create all partners at once.
Task-3024050
Part-of: odoo/odoo#105111
Allows to rate any record extending mail_thread. This change was needed because
the rating template could be sent on any record (with some minor changes like
removing reference to specific record) and if the record was not extending the
rating mixin, it was crashing when the controllers using rating mixin features
were used.
This commit moves the code from the mixin rating.mixin to mail.thread and
adapts the test for testing rating submission with and without the mixin.
Technical notes
- rating_ids field has been added in mail.thread instead of using a simple
query because it improves performance while getting rating token in mass.
- the rating mixin now inherits from mail.thread to add features on top
of basic rating support in mail.thread.
Task-2674649
closesodoo/odoo#103966
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This task integrate the rating feature in mail.thread which adds one query in
the unlink method (for deleting the related rating) on model that were not
inheriting from rating.mixin.
Task-2674649
Part-of: odoo/odoo#103966
Small correction to make the code more robust.
Technical note: we encountered a case where the group 'portal_customer' (to
classify recipient for mail_thread) where not present although it is added by
portal.mixin inherited by sale.order. That problem has been fixed since. So it
doesn't fix an actual problem but a potential one (condition of the "if" cannot
be false because the generator will generate an exception before).
Task-2674649
Part-of: odoo/odoo#103966
Various: im_livechat, rating, test_mail_full, website_{sale|slides}
Allows to rate any record extending mail_thread. This change was needed because
rating template could be created for any models, even those not inheriting from
rating.mixin. If sent on a record of such model, it was crashing when the
controllers using rating mixin features were used. This is no longer the case.
This commit moves the code from the mixin rating.mixin to mail.thread and
adapts the test for testing rating submission with and without the mixin.
Base behavior accepts rating and provides an access to ratings through the
'rating_ids' field. Rating.mixin inherits now from mail.thread to ease
computation, and adds statistics and some advanced capabilities.
Inheritance of some model have been reordered now that rating is build on
top of mail.thread.
Task-2674649
Part-of: odoo/odoo#103966
In an edge case the content of the field has already been
prefetched as sudo during the read of another field as sudo,
therefore it doesn't try to read the field as the normal user
closesodoo/odoo#88134
Signed-off-by: Julien Castiaux <juc@odoo.com>
To reproduce the issue:
1. Install [Accounting]
2. [Settings]: Toggle on [Batch Payments]
3. Enter [Invoices]
4. Click on several invoices and [REGISTER PAYMENT]
5. Hover over [Group Payments] to see the guide message
Impacted versions: 16.0 up to master
opw-3178431
closesodoo/odoo#113493
X-original-commit: 0866ee676084ae52e6a0b13360a24dacbccd5237
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
Report line `l10n_kz_tr_line_300_00_017` has two expressions with a duplicate expression label, which shouldn't happen. This commit merges them, with taxes being allocated into the same expression.
closesodoo/odoo#113437
X-original-commit: e758e616929e8050ebbf152207b1f45f74b8919e
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Steps to reproduce the bug:
- On the website application, add an image gallery snippet.
- Change the "Speed" parameter.
- Save.
-> Nothing happens: The displayed image is always the first one and
there is no cycle between the images of the snippet.
Since Bootstrap 5, the amount of time to delay between automatically
cycling to the next item is defined by `data-bs-interval`. The bug
comes from the fact that some parts of the code still used the old
parameter name (`data-interval`).
opw-3165570
closesodoo/odoo#113423
X-original-commit: 8368fa1f5e45a14ed8938017b2da90a810dbf0c8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Step to reproduce issue:
- Go to sales settings, activate "Unit of Measure"
- Set user define default of field "uom_id" of model "product.template"
- install "loyalty" module.
While loading file "addons/loyalty/data/loyalty_data.xml" file it will create product and gives traceback.
Or
- It will also give error while upgrade database from 14.0 to 15.0 or more
Note : This error occurs while there is user-define value for uom_id is set and any module tries to
create product from data file.
Current behavior:
- When product creates, uom_id and uom_po_id gets default uom value from
"_get_default_uom_id" method which return "Unit" uom as default.
But when user have default value for uom_id(let's suppose Days), it sets that default
value and for uom_po_id we got uom value as "Unit".
- So now as uom category of Days and Unit are not same it violates "_check_uom" constraint.
Traceback: https://pad.odoo.com/p/utpr-set_default_uom
Soultion:
- When product creates, if there is default value for field uom_id in "ir.default" then
"_get_default_uom_id" method sets same value for uom_po_id.
closesodoo/odoo#113300
X-original-commit: 33a20cf799a6cbca6a55cb82f90c4451df60fa1c
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
- l10n_it_edi: EDI receiving cron error handling fix
If we cannot receive invoices or bills from the IAP proxy we also can't
iterate over them
- l10n_it_edi: Check edi_format before trying to remove signature
The edi_format must be checked before trying to remove the eventual
PKCS#7 signature from the file, otherwise we're uselessly going to try
and remove the signature for every edi_format check (facturX etc.)
- l10n_it_edi: .p7m files can wrongly be missing the signature
In the case that the .p7m extension is put by mistake, try to use the
content of the file as it is before discarding it.
Task link: https://www.odoo.com/web#id=3189457&model=project.task
Task-3189457
closesodoo/odoo#113451
X-original-commit: 942e3c7f2b549fed86f9eb76f98f30b7e5db1ae9
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
With this revision, the label of the field of the first row groupby is
inserted as the row title.
Task-id 2901960
closesodoo/odoo#107220
Related: odoo/enterprise#37395
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
If a user decrease the SOL qty of a kit once the return is done, an
unexpcted picking will be created
To reproduce the issue:
1. Create a kit K:
- With one component
- There is one component in the stock
2. Create and confirm a SO with 1 x K
3. Process the delivery
4. Return the delivery
5. Set the SOL qty to 0
Error: a useless and unexpected picking is created to return the kit
When setting a new SOL qty, we check if we should create and run a
new procurement to adapt the qty on delivery-side. To do so, we get
the qty being delivered, and we compute the difference with the new
SOL qty. Here is the issue, when getting the qty being delivered, it
returns the old SOL qty (1.0):
https://github.com/odoo/odoo/blob/797f67bcb222142b79a9eee3e4a882ff679af9db/addons/sale_mrp/models/sale.py#L164-L167
This is not true. Since the kit has been returned, the qty being
delivered is zero. As a result, a procurement is created to
compensate that incorrect qty.
The incorrect return value (1.0) comes from [1]. However, that fix
is not correct. Here was the initial issue: To get the qty being
delivered, we use the moves of the components, include the BoM lines
qties and try to compote the kit quantity. To do so, we call
`_compute_kit_quantities` with the components' moves and the kit qty.
However, there is an error: the moves are based on the old kit
quantity, and we give the new kit quantity to the method. This is why
the result was incorrect in the use case of [1].
[1] bafad58353c562a9b79735640c23d3cca004e0b0
OPW-3077209
closesodoo/odoo#113438
X-original-commit: 0b8af1d63d496489ac1608141c9b2dbccc8b7966
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
It may happen that the response of a json rpc isn't json parsable,
for instance when the connection pool is full (PoolError). In this
case, the response is an internal server error (500) in html.
Trying to json parse it throws an error. Commit [1], backported in
15.0 by [2] aimed at throwing a more readable and meaningful error
when this happened.
However, this error occurs frequently on the saas for the moment
(see task 3193565), and users constantly report those HTTPError
tracebacks introduced by [1].
In 14.0, we were using jQuery ajax, and the legacy rpc and error
system, where those internal server errors were handled as
connection lost errors (error code -32098). So basically, a
notification was briefly displayed instead of an error dialog.
This commit restores the previous behavior in the new rpc service.
[1] https://github.com/odoo/odoo/commit/5c4a54022b320
[2] https://github.com/odoo/odoo/commit/a01122543a79cclosesodoo/odoo#113434
X-original-commit: 278686d8540a194f0af51e1a0b68b26b13eaf544
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Bug
===
The number property should be formatted like a normal integer / float field,
in the form view (show 2 decimal for the float, thousands separators, etc,
even when editing).
Task-3162402
closesodoo/odoo#113449
X-original-commit: 99c251820dcf4791625fabd3fcd61db84280d408
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
product._get_rules_from_location, orderpoint._compute_lead_days
and orderpoint._compute_rules can all be performances
bottleneck. This is mostly because the rules are retrieve
one by one, i.e lots of 'SELECT ... LIMIT 1' queries
are executed.
Refactoring this in stable is difficult because
there are lots of methods involved and the rules have
some type of hierarchy based on the location_src_id field.
So there are recursive calls that are hard to refactor.
Instead of doing that, the idea of this commit is to speed up
these individual 'SELECt ... LIMIT 1' queries by adding
b-tree indexes on some of the stock.rule fields that are
used as conditions of these select queries.
opw-2773988
closesodoo/odoo#113444
X-original-commit: a76c4944d09be9cacfe8d3bac805841d84fb3f41
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Van Delft Aurélien (avd) <avd@odoo.com>
l10n_gcc_invoice implements invoice template with mixed english arabic labels.
This commit makes some clean up on text/columns direction and alignment with a
focus on RTL readers.
1.
Lines with Invoice Date, Due Date, Delivery Date, etc. are aligned to right
Before
*Invoice Date: 9/11/2001 :etaD eciovnI)* ____________________________
After
____________________________ *Invoice Date: 9/11/2001 :etaD eciovnI)*
2.
Columns of order lines are reversed
Before
*Description - QTY - ... - Total Price*
After
*Total Price - ... - QTY - Description*
3.
English/Arabic titles in the headers are inversed (Arabic is on the top now, English is on the bottom)
4.
Small table with subtotal/taxes/total has reversed columns too, so values are
just below of Total column in the main table
Before:
*Title/eltiT - Value*
After
*Value - Title/eltiT*
5.
This commit also improves Payment Reference section to comply with other
sections, i.e. print single value and two labels.
Before
Payment Reference: INV/2020/00019 INV/2020/00019 :ecnerefeR tnemyaP
After
Payment Reference: INV/2020/00019 :ecnerefeR tnemyaP
STEPS:
* install l10n_sa
* create an invoice with customer that has Arabic language
* use "Send & Print" button to get pdf file
opw-3115673
closesodoo/odoo#113443
X-original-commit: 9f6ed327fe34738740d8cb3584313972c8a0f782
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
This commit removes the default `stage_id` group in the
'All Tasks' list view, as it is causing performance issues
closesodoo/odoo#113435
X-original-commit: 759d7b1a30841535de57c19954eff3507dd61eff
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Larcin Vincent (vila) <vila@odoo.com>
The delay of tooltips opened with the tooltip service can be given
in xml, with attribute data-tooltip-delay. If not specified, there
is a fallback in the service to 400ms. Before this commit, the
fallback wasn't correctly applied, because we parsed the xml delay
into an integer, which was NaN when the delay wasn't specified,
and as NaN isn't undefined, the fallback wasn't applied. As a
consequence, we opened the tooltip in a setTimeout with NaN as
delay, and it thus opened directly.
closesodoo/odoo#113425
X-original-commit: 553b2775a4b31c75d1d246816b749e4521e25726
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Let's say there is one account with code 431 and another with code 4310,
`ODOO.BALANCE("431,4310", 2022)` counts 4310 twice.
The reason is queries are done one code at a time, one by one.
The account 4310 is counted first when using 431 as a prefix (431%) and once
more with 4310 (4310%).
Now, the query uses all codes all at once.
The original idea was to cache queries as much as we could. If you later add the
formula `ODOO.BALANCE("431", 2022)`, the result would have been cached
because queries were done code by code.
Given the issue it brings, we thing this opmitisation is not worth it and is
therefore removed. It also makes the code client-side simpler.
opw-3144473
closesodoo/odoo#113418
X-original-commit: 07bd67f3a389bde4f33e08d97967dbb70ad5a19f
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
luvi