The onboarding demo data cannot be loaded since f96ea753f3.
Steps to reproduce:
- Start a database without demo data (--without-demo=True)
- Open a POS session for the default shop
- Click to load demo (onboarding) data
An error is raised.
The error is due to a mistake in the XML, the food category logo is not assigned to the right record.
closesodoo/odoo#136392
Task-id: 3519677
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Since a869ee87f2, the cashier can no longer close a session from the frontend UI if the POS config has not a cash payment method.
Steps to reproduce:
- Remove any cash payment method from the POS config you want to use
- Open a POS session for the previous POS config
- Make an order
- Try to close the session
A (silent) error is raised, the user cannot close the session.
This error is particularly noticeable when we don't use demo data (--without-demo=True).
The fix consists in correctly checking if there is a cash payment method or not.
closesodoo/odoo#136387
Task-id: 3519547
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
In 6698406b92a598f24fa0a778a28b6ef727adc008, we removed action
mrp.mrp_production_report. action_view_mos still using this action, we
change it to use mrp.mrp_production_action instead.
closesodoo/odoo#136382
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1” with BoM:
- Component C1:
- Quantity: 2
- supplier:
- add any vendor, min quantity: 3
- Create a MO to produce 1 unit
- Click on the manufacture overview
Problem:
A user error is triggered:
`“The unit of measure Units defined on the order line doesn't belong
to the same category as the unit of measure False defined on the
product. Please correct the unit of measure defined on the order line
or on the product, they should belong to the same category.”`
The _compute_quantity function is called with supplier.product_uom even
though no supplier with the requested quantity is available.
opw-3495770
closesodoo/odoo#136340
X-original-commit: 17e5323e292a7b29ee6d30711cf3f083e05dd008
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
The safeConvert function in the useDateTimePicker hook will call parseDate with
an undefined format when no format option was provided to the hook. Before this
commit, since the options object passed to parseDate still contained the format
property, the undefined format will also be passed on to the parseDateTime
function. This is problematic, because now the parser will use the default
datetime format, and it will fail because of the absence of a time value in the
input string.
For some input formats, parseDateTime will still yield the correct result using
one of its backup parsing methods. However, a wrong result will be returned for
date formats containing some textual parts (for example MMM/dd/yyyy).
Making sure no undefined format values are passed on in the parseDate function
resolves the problem.
opw-3478797
closesodoo/odoo#136221
X-original-commit: b04482ed87db05b3fc2523a08ce7ca5818af578b
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Signed-off-by: Tom De Caluwé (tdc) <tdc@odoo.com>
When calling action_repair_done on a Repair Order that has been created
from a Sale Order (which is done by adding a product.template with field
'create_repair' set to True), we should update the delivered quantity of
the product responsible of the creation of the Repair Order if and only
if this product Invoicing Policy is in ['Ordered Quantities',
'Delivered Quantities', 'Prepaid/Fixed Price'].
closesodoo/odoo#136195
X-original-commit: fcbc689dc37cafd5a0cba7b57a2f40ad6acf4e26
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Mathias Mathy (mama) <mama@odoo.com>
cherry-pick of a4904fb4889c16322494981f5a1be586683704bd
Steps to reproduce the bug:
- Create a storable product “P1”
- costing method: avco
- Create a PO:
- Add the product “P1”:
- Line 1: Qty= 10, price= $50
- Line 2: Qty=1, price= $10
- Confirm the PO and receive the product
- Go to purchase → Reporting → Purchase Analysis
Problem:
The average price is incorrect, the current calculation is:
(50 + 10) / 2 = 30
The average should take into account the quantities purchased in each
line, And not simply the number of line, so the correct calculation
should be:
((10 * 50) + (10 * 1)) / 11 = 46.36
The SQL query is correct, it is when applying the read_group that the
calculation is incorrect, we should override it to make a personalized
calculation of the average.
opw-3136406
closesodoo/odoo#136097
X-original-commit: cd84549a3e5ea09d230dc1d02e05456a2372fd34
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Purpose
=======
When a user tries to reach a course, an AccessError can occur when we
unslug the URL. Instead of the traditional error page, we want to
redirect the users to /slides, and the error will be displayed there.
Task-3477630
closesodoo/odoo#135926
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current behaviour before commit:
In table, when clicking table menu icon it throws
traceback.
Desired behaviour after commit:
Now, clicking table menu icon opens table menu
without any traceback.
task-3503806
closesodoo/odoo#135324
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, when `a` tag is in a td, the color of text ellipsis
(3 dots) is different than the text because the text-ellipsis is set on
the parent element, that is `td` element and the color is set on the `a`.
This commit sets the right color on td element when that element has `a`
element.
Limitation (only for td inside element with `o_portal_my_doc_table` class):
if the `td` element contains `a` tag and another element
then the color has to be set to that other html element otherwise,
the color will be the one of the a tag.
task-3251721
closesodoo/odoo#134993
X-original-commit: b28459ddee3bf76630e2968baecd1dd4bc7cba93
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit fixes the issue of partial coloring of table cells.
Before this commit, if one colors part of the text in the cell
and then seeks to color the whole cell, the last coloring
would not apply on the previously colored text.
We do that by preventing the cell coloring to be done differently
than other elements except if we want to change the
background color.
Task-3454903
closesodoo/odoo#130646
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit adapts website_blog tests to change in website_helpdesk. The
method _compute_visible of model website.menu is modified to display
help team menus to backend user, even if they are unpublished. This
potentially add extra requests when rendering a website page. Therefore,
the performance tests are adapted accordingly.
task-3186564
closesodoo/odoo#134976
Related: odoo/enterprise#45115
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
current behavior:
When a product with tax included is sold with a fiscal position that
match the tax to a tax of 0%, then when you refund this order the
fiscal is applied a second time. This result in the 15% tax removed 2
times and the price of the product is incorrect.
steps to reproduce:
- Create a product with 15% tax included
- Create a fiscal position that match the tax to a tax of 0%
- Create a POS with this fiscal position
- Open PoS, and make an order with the product
- Applyy the fiscal position
- Refund the order
- The price of the product is not the same as the one of the original
order.
opw-3371028
closesodoo/odoo#136348
X-original-commit: 58406515233234ac0ed342d81a5c55886c3b5712
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Prior to this commit the combo choices were displayed in their ID order. This
commit add a sequence field that allows the user to choose the order of
the combo choices.
closesodoo/odoo#136331
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The async methods of field service were not declared in its key async.
This would allow destroyed components to process the results of those
methods (despite an initial call to useService). We fix that.
closesodoo/odoo#135950
X-original-commit: 7955def19c7d4a8c49be472413423bbf3beec2e5
Signed-off-by: Géry Debongnie <ged@odoo.com>
This commit changes the way transactions linked to a document (sales
order, invoice...) are created in a payment flow. Rather than receiving
and trusting the transaction values from the controller, they are now
read from the linked document, and the payment flow is rerouted to use
the document's module's controllers instead of that of `payment`.
This ensures that no unexpected value can be passed to the `create`
method of a transaction, and simplifies the implementation of the
payment flows of linked documents.
task-3136240
closesodoo/odoo#126425
Related: odoo/enterprise#43212
Related: odoo/upgrade#5124
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The method get_resource_path is redundant with file_path but without
all the checks.
The method will be deprecated in master but make it use file_path in
stable.
closesodoo/odoo#136272
X-original-commit: 64ab4a6914dadd741cfe61d9bd1959ae4509a1ca
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This previous commit : https://github.com/odoo/odoo/commit/d197efa60cf7c00168847ce7afcfa1741410aee1 aimed at ventilating rounding error corrections on multiple lines. But this would introduce errors or unbalanced moves if the rounding amount/lines quantity was smaller than the rounding of the currency. E.g. à 0.01€ error divided on 3 lines would add 0.00333 on each line, and when the amount is rounded, it would vanish.
closesodoo/odoo#136366
X-original-commit: 0627b4609e8b1b3d15651d6cde0ff4cfdc85c5d6
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
* = bus, calendar, im_livechat, hr, project_todo, sms, snailmail,
test_mail, web, website_livechat
The current implementation often led to tests relying on DOM structure
to properly target the correct element with the text.
It is now easier to simply check if a parent contains some text.
closesodoo/odoo#136295
Related: odoo/enterprise#47770
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Some tests are updated to lessen diff in future tests, especially about
aliases. Some tests are fixed as they are somehow incorrect (notably
in gateway testing) but currently passing as mail gateway is quite
permissive.
Add some tests preparing MC / alias domains configuration notably about
company / alias synchronization, which is currently only based on config
parameters.
Also update some tests by using fstrings which are generally more readable.
Finally move some tests to their right file / main testing class to keep
them ordered by main topic.
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#136318
X-original-commit: odoo/odoo@c18300e225
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Cleanup some code bits in common classes, add some docstrings. Improve
notifications related helpers, notably to ease checking content of mail.mail
or outgoing emails when posting messages.
Update 'test_message_post' with those new helpers, to ease inclusion of
additional specific values test with alias domains in mind in next commits.
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
X-original-commit: odoo/odoo@513fb74f5c
Part-of: odoo/odoo#136318
Before this commit, users were required to compute the API URLs, which is
specific to each Adyen account, themselves. After this commit, users
will be able to copy their account prefix from Adyen to automatically
generate the API URLs.
task-3338126
closesodoo/odoo#126831
Related: odoo/upgrade#4876
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
If a list view row switches to more than one line (e.g. because of some
field which overflows), the record selection checkbox need to respect
the same alignment as other 'blocky' widget like statuses, priorities,
etc. and be middle-aligned.
Task-3515864
closesodoo/odoo#136222
X-original-commit: 77252ff7201625f25667f64f07cee627d3c47b99
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
When adding a new raw SM to a confirmed and locked MO, it should still
be possible for the user to define the to-consume quantity (else, he
would have to unlock the MO and only then to edit the new line)
OPW-3253204
closesodoo/odoo#136009
X-original-commit: b78c468317079ac415d7b1fdbd4d4d081ff3976b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
When you are using a different currency in a PoS config, invoicing
a POS order that was created in a previous session, causes an
unbalanced entry error. Because the amount_currency and balance of
the payment moves are incorrect.
Steps to reproduce:
- Create POS config with currency other than company currency
- Create order in a session
- Close the session
- Open a new session
- Load paid orders
- Try to invoice the created order
opw-3479292
closesodoo/odoo#136294
X-original-commit: 17a8b70594d97a04c2389f9fb6f0cf370c6074c5
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Current behaviour:
Traceback when trying to create
a new external identifier
Steps to reproduce:
1. Activate the developer mode
2. Go to settings
3. Technical > External Identifiers
4. Click on "New"
5. Traceback
Cause of the issue:
Introduced by https://github.com/odoo/odoo/commit/3c62ca1eb96d571b2b686b5caee370324c589ab4
When computing display_name, the model
can be false, and not be in self.env
opw-3489581
closesodoo/odoo#136279
X-original-commit: 2462df26977acc9e3ccafd57863703aacd2f059e
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Co-authored-by: Rémy Voet <ryv@odoo.com>
Prior to this commit if an order was sent to another pos with the cross
order, if the product was missing in the target pos, the product will be
missing in the order. This commit loads the products that are missing for
the cross orders.
Task-3504316
closesodoo/odoo#136263
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Commit [1] changed the separator of cids in the url to make it
better looking, by using a character that doesn't need to be
encoded (namely, "-" instead of ","). However, by doing so, urls
still using the former separator couldn't be correctly parsed
anymore. This commit adds a small backward compatibility layer,
s.t. links in emails for instance keep working as before.
[1] abae4d4a5cclosesodoo/odoo#136247
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
We here fix the `SurveyQuestionAnswer._compute_display_name`
method introduced in 55fa52be.
`survey.question.answers` used as matrix rows and columns
require different treatment as they are not used in triggers
but are both shown on the `survey.user.input.line` views,
where the display shouldn't change (nor cause a crash).
It also doesn't make much sense to create answers outside the
context of a question, so we remove the button that already
wasn't shown on the tree view.
As users may not fully upgrade their views or may wish to customize,
we add a fallback question title in `_compute_display_name`too.
Task-3495142
closesodoo/odoo#135853
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Vivek Pathak <vivp@odoo.com>
When a user creates a downpayent with a fixed amount, the amount is tax included. This can generate rounding issues as sometimes the amount is impossible to be reached by any base amount / tax combination. (fixed amount = 100€, tax is 21% -> 100/1.21 = 82.64 -> 82.64 * 1.21 = 99.99). This can lead to up to 1 rounding error per downpaylent line.
Until now the total amount delta was added/removed on one tax line, one receivable line and one product line. While the total amount was correctly corrected, the amount on the individual lines would be off.
On a SO with :
base | tax | tax incl
1000€ | tax_21%_a | 1210€
1000€ | tax_21%_b | 1210€
Generate 1 DP for fixed amount 200€
Invoice lines :
BEFORE:
tax | balance | price_total
base lines ----------------------
tax_21%_a | -82.64 | 100.01 <-- 0.02 correction
tax_21%_b | -82.64 | 99.99
tax lines -----------------------
| -17.37 | 0.0 <-- 0.02 correction
| -17.35 | 0.0
receivable line -----------------
| 200.0 | 0 <-- 0.02 correction
AFTER:
tax | balance | price_total
base lines ----------------------
tax_21%_a | -82.64 | 100.0 <-- 0.01 correction
tax_21%_b | -82.64 | 100.0 <-- 0.01 correction
tax lines -----------------------
| -17.36 | 0.0 <-- 0.01 correction
| -17.36 | 0.0 <-- 0.01 correction
receivable line -----------------
| 200.0 | 0 <-- 0.02 correction
closesodoo/odoo#135698
X-original-commit: d197efa60cf7c00168847ce7afcfa1741410aee1
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Downpayment might have been determined by a fixed amount set by the user.
This amount is tax included. This can lead to rounding issues.
E.g. a user wants a 100€ DP on a product with 21% tax.
100 / 1.21 = 82.64, 82.64 * 1,21 = 99.99
This is already corrected by adding/removing the missing cents on the DP invoice
but it would still be wrong when creating the final invoice (as it is based on the actual base amount + tax of the SO DP's)
opw-3466409
X-original-commit: 0a6e2d47107727040664176740535707286a1355
Part-of: odoo/odoo#135698
How to reproduce:
- open a record with an html_field (i.e. todo or a Knowledge article)
- switch back and forth with the pager or the knowledge sidebar between 2
records
Current behavior:
- traceback `this._elementHookMap.get(element)` is undefined
Expected behavior:
- no traceback
Technical explanation:
When changing the editable content (i.e. `resetContent` when changing record),
there is no guarantee that `_intersectionObserverCallback`
(intersectionObserver) won't be called before `_updateHooks` (mouseMove/resize
after a mutation occured).
This is an issue because `this._elementHookMap` may not yet have a hook element
related to the editable element which stops intersecting the document.
If such a case occurs, the next `_updateHooks` should be called when the
mutationObserver flags `_resetHooksNextMouseMove` to `true` and then after the
next `mouseMove` (or after the next resize).
Ignore the hook style update if there is currently no hook for an element which
stops intersecting.
Remove a redundant check in `_getMovableElements`
task-3506666
closesodoo/odoo#135464
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Include the 'duplicate' action in the action menu in list view. The copy_batch
method will call the copy method with a loop to keep any existing override.
closesodoo/odoo#133977
Task-id: 3456679
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Up until this commit, which view was displayed by default on mobile was
somewhat of a lottery.
Initially, only kanban views were considered as 'more adapted to mobile
devices' and used as a main fallback to display records who had a kanban
view in the window action definition.
The the concept of 'mobile-friendly view' was extended to map and grid
so that these views could take precedence over the kanban view in
specific circumstances (indsutry_fsm and timesheet_grid, both of which
are enterprise edition apps) - basically they were marked as
mobile-friendly not because they *are*, but because it was the only way
to override the kanban override.
But this comes with its lot of problems and limitations, namely that the
mobile friendly view will be found based on the order of view modes for
a window action, so if you have a window action with the view modes
`kanban,map,tree,form`, you will never be able to have e.g. the kanban
view shown on desktop by default and the map view on mobile.
This commit introduces the notion of a 'default mobile view' on window
actions so that one may decide on an *arbitrary* view mode to use on
mobile for an action - without impacting the ordering of views on other
models, etc.
Task-3460374
closesodoo/odoo#133608
Related: odoo/enterprise#46562
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the payment providers (e.g., Stripe, Adyen...)
available for payment were displayed on the payment forms. The customer
had to select one to process their payment. After that, the customer had
to select their preferred payment method (e.g., Credit Card,
Bancontact...) from a list of payment methods supported by the selected
provider over which the website administrator had close to no control.
This was making the payment forms confusing because the payment methods
were displayed sometimes more than once, if at all, in a non-controlled
order, and behind the selection of a payment provider that customers
should not have to deal with.
As the payment method was selected in an iframe or directly on the
provider's website, the information on the selection payment method was
not available in Odoo. This posed many problems, among which were the
impossibility of assessing whether a specific feature (e.g.,
tokenization, refunds, manual capture...) was available, not being able
to easily identify payment tokens through the payment method logo,
listing available payment methods on the website, sorting and
fine-grained configuration of the available payment method, subpar
payment method-specific display on the payment form (e.g., PayPal that
requires displaying a "Pay with PayPal" button), etc.
In this commit, the payment providers are thus replaced by the payment
methods on the payment forms. All contextually available (depending on
the country, currency, requested feature...) payment methods are
displayed one after the other on a single-level list and in the order
configured by the website administrator. Each payment method is
"powered by" (i.e., linked) to a single payment provider: the first one,
by model order, to support it. This allows, for example, offering the
PayPal payment method through Mollie, which charges low processing fees,
while also offering Klarna through Stripe, which supports more payment
methods but charges higher processing fees.
While doing so, the two different payment forms, "Checkout" and
"Manage", are also merged together in a new, configurable case-by-case,
payment form that is entirely redesigned to offer a better user
experience.
After payment, the information on the selected payment method is saved
on the transaction and eventual payment record and updated with the
information received from the provider.
task-2882677
closesodoo/odoo#120446
Related: odoo/upgrade#5103
Related: odoo/documentation#5717
Related: odoo/enterprise#40666
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: Anita (anko) <anko@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
Co-authored-by: Valeriya (vchu) <vchu@odoo.com>
Several functions were:
- called with `await` while there are synchronous;
- declared as synchronous while they should have been asynchronous;
- declared as synchronous but their overrides were async;
- explicitly encapsulating their return values in a `Promise` when it
was unnecessary.
This commit also cleans up a few mistakes in comments and docstrings.
task-2882677
Part-of: odoo/odoo#120446
This commit mainly removes the extra indent level left over after commit
odoo/odoo@8ec2e8cf. It also cleans up purely cosmetic code styling
inconsistencies.
task-2882677
Part-of: odoo/odoo#120446
Current behavior:
If you had 2 products with different expense account and using real-time
inventory valuation, there was an error when validating the picking.
This was happening because move_vals we were trying to assign multiple
moves to one pos_order here https://github.com/odoo/odoo/blob/95cec6ea3daebce6491cc2a8a69d9688322989ba/addons/point_of_sale/models/stock_picking.py#L155
The account move is actually reserved for the invoicing of the order.
So we just need to remove that line.
Steps to reproduce:
- Create a product with expense account A
- Create a product with expense account B
- Make sure both products are set to real-time inventory valuation
- Activate ship later in the PoS
- Open the PoS and add both products to the order
- Validate the order with ship later and no invoice
- Close the PoS and try to validate the picking of the order.
opw-3428033
closesodoo/odoo#136254
X-original-commit: a2c8ea0adbd93cb9d178977f73e93492e84dfec3
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Use the same method and date used to compute the rate on aml field currency_rate
closesodoo/odoo#136230
X-original-commit: adae60fc532cf6a853815f840cb49e93eb008cb7
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to reproduce
==================
- Use a mobile viewport
- Create a quotation
- Add an order line
- Set a packaging
-> The Packaging Quantity field is missing
The same happens on purchase orders
---
opw-3504829
closesodoo/odoo#136213
X-original-commit: c5d665cc2b43a0040c3f5644265e74048c3d5ded
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Since the new model (PR: odoo/odoo#114024), updating a record no longer
triggers a deep render and therefore no longer triggers the onWillUpdateProps
for Field components.
The goal of this commit is to adapt the usage of onWillUpdateProps
in Field composents in order to fix the bugs introduced by the RelationalModel
closesodoo/odoo#135842
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This solves the following problem:
- Add 150 records with 2 activities each (ex. A call and a to do)
- Go to the activity view (ex.: event through the systray) and clear filter
- Only 50 of the 150 records are displayed (instead of 100)
- Going to the next page, only 2 are displayed (instead of ~50) (will depends
on the data already present)
Technical notes:
Not all activities were displayed because the search limit was applied on the
activity search instead of searching all activity related to the records.
The method fetchActivityData was doing half of the job because it was not
assigning the activity data fetch on the server to the instance variable
activityData, which was causing strange behavior when clicking on next page. To
simplify and correct the code, that logic has been moved to that method instead
of relying on the caller to do that assignation.
Task-3508744
closesodoo/odoo#135651
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The activity view pager test is improved to use the actual get_activity_data
mock rather than checking that it is called with the right parameters. Thanks
to that, we also check that the activities are displayed. To ensure that the
pager influence only the records displayed and not the related activities, we
set up test records with 2 activities each and check that there are 2 times
more activities displayed than the number of records.
Task-3508744
Part-of: odoo/odoo#135651
Theo VINCENT (thvi)