As on enterprise module install order can be different from community
query count for some mail-related tests are different. This commit
updates some counters to avoid breaking enterprise runbot and give
time to find the source of added queries.
Purpose
=======
In a business point of view, it make no sense to merge record. if someone want really to merge record they have to do this manually to think about all corner case. What about id sent to the customer ? what about timesheet ? what about business ?
The idea of the task: remove this feature in both app, project.task and in helpdesk
Specification
=============
Remove both features
"Merge Selected Tickets" in helpdesk
"Merge Selected Tasks" in project.task
Since test cases of sale depends on account common
class test, they are executed post_install.
For some futur dev, we will need to launch them
at install (since stock module change the behavior
of consumable product for delivered quantity computation).
This commit:
- avoid test to use demo data
- reuse common helpers to generate testing
data
- make test suite share common test classes
Accounting tests are executed post install to be sure a chart
of account is install. However, for some case, we might want
to run test at module installation, involving accounting, without
being sure a chart of account is installed.
This commit provides a base common test class with a minimal chart
of account (some journals and accounts) allowing to start tests at
installation. this class should be extended in sale or expense for
this modules to be tests at installation. We will required this for
reinvoice test in sale later (test consumable product when sale_stock
is not installed, but maybe without a chart of account). The idea is
each test suite can call method to setup their own data.
This commit also use this common test class in sale_expense.
Accounting tests are done 'post install' because
their generally requried a chart of account to be
installed before test execution.
If a test is launched before l10n install, the test
will be skipped but nobody will know it, unless you
read all the logs of your server.
When skipping a test, a warning should be displayed.
The rte_inline tour was failing on chrome because jquery selector in
chrome does not like a space in the style selector.
On the other hand, other browsers and phantomjs need the space.
This commit change the selector to find the element on chrome and
friends.
When running the portal tour, the test succeed too early because it finds
the words "Your Details" on the wrong page (/my instead of /my/account).
The selector has a match on previous page, so tour succeeded when it 's
not complete.
This commit use another selector that only match on the '/my/account'
page.
When using the fast_counterpart creation method to automatically
reconcile bank statement lines, there was no verification that the
account id was not set or that the statement was already linked to journal
entries. It was causing a traceback in some conditions when the
demo data were loaded because the fast_counterpart_creation was called
without the verification, using an XML function.
This commmit introduce the necessary verifcation.
Thanks @qdp-odoo for the review and some docstrings/comments
When searching the id mail.mail_activity_data_todo a request is done and
should be taken into account by the assertQueryCount.
This commit does just that... for the employee login.
Thanks to the murphy's law, the test branch was green.
When searching the id mail.mail_activity_data_todo a request is done and
should be taken into account by the assertQueryCount.
This commit does just that.
New tests are added in test_mail to have tests for message_post and
complex mail thread features. Purpose is to have performance counters
for more complex stuff in mail and begin to work on performances
and try to lessen those counters.
This rev. introduces two helper functions for the tests: patch
and unpatch. Those function allow patching an Odoo Widget (e.g.
AbstractField), and unpatch it at the end of the test with the
guarantee that the Widget's prototype is exactly the same as it
was before the test.
This was necessary because the way it was done before was a little
bit too naive, and could lead to unexpected behavior. Indeed, doing
var someFunction = AbstractField.prototype.someFunction;
// test content
AbstractField.prototype.someFunction = someFunction;
is correct if someFunction is actually define (or overriden) in
AbstractField, as in that case, it really exists on its prototype.
Otherwise, it isn't correct if it is not directly defined on the
prototype before the test, as it will be after..
The 'on_reverse_breadcrumbs' option of do_action() allows to
define an handler to execute when coming back to the previous
action by clicking on the breadcrumbs.
This option was set when executing the Import client action, to
ensure that the previous view was reloaded when the client action
was left. However, the view to restore is always reloaded, so
specifying the option in this case produces a double reload.
Before this commit:
To know if an event menu is an auto generated one (eg: location, register..),
it checks if the menu name is the same as the hardcoded one in
_get_standard_menu_entries_names.
If user change the menu name, the code won't retrieve it and will act as if the
menu had been deleted and it will recreate it.
This leads to 2 bugs:
*First (website_event)
- Change menu name from website_event (eg: location, introduction or register)
- Check/Uncheck 'Track on website' or 'Track Proposals on website' to force
the code to rewrite missing menus.
- Go back to the event front end, theses menus have now been recreated, and
are duplicated.
*Second (website_event_track)
- Check 'Track on website' on event's back end
- Change the 'Talks' menu name in front end
- Go back to backend, 'Track on website' is unchecked because
_compute_website_track won't retrieve an event menu named exactly 'Talks'
Now:
We don't use euristics to try to recover missing menus.
We just create related menu when option is checked, and we delete them when
option is unchecked.
To know which menu item comes from which option, we store a value in a new
model 'website.event.menu'.
We don't want to try to check if the menus are all there and recreate them if
needed anymore. There is cases where user wan't to delete a menu and repace
it with a link to that menu's URL in the page content.
Before this commit, the option would've been unchecked since it won't
retrieve the menu.
This technical dependency module adds settings to res_company for the
company's social media pages.
It is introduced to fix duplicated fields for res_company in website and
mass_mailing, these two modules now require social_media as a dependency
Add the context manager method `assertQueryCount` to count queries,
the decorator `@users(...)` to execute a test for several users, and
the decorator `@warmup` to execute a test twice (warm-up, then real).
Creating data directly in tests was done when tests were located in mail
module to avoid creating real data or demo. Now that mail tests have their
own module we can create demo data and use them in tests. It is simpler to
have demo data for things like subtype and email templates to ease
understanding and reuse.
Before this commit, an user could not create or remove a website.menu since
there was no list/form view for it. Changing sequence also impossible.
Therefore, it was impossible to create or delete a menu from an event. (you
could just edit the existing one)
Now, user can access in debug mode to the list and form view of website.menu to
manage the menus.
This commit also add a link on the ir.ui.view form view to access it's related
website.page
This closes#21302
Impacted modules: rating_project, project, sale_service_rating,
website_rating_project and rating.
This merge remove some small modules to integrate them
directly into big one; indeed, we wanted to set rating as
dependency of project module.
As consequence, we see:
- rating_project is removed (its features) are included in
project, hidden with a group
- sale_service_rating is absorbed by sale_timesheet
- website_rating_project is moved into project too, so the
rating page does not depends on website anymore
No feature change, simply moving code, and reorganize some ;)
Displaying the rating of project is moved directly
in project module, since it does not depends on website.
User may want to display rating of its support project
even without website.
Since rating in on project directly, and task
and issue are merged, we can simplify some domain
and replaced them by default filters.
The search domain will be less complex and the
performance will be better.
Impacted modules: project, rating_project,
sale_service_rating and website_rating_project.
Removed modules: rating_project and sale_service_rating.
Move code to empty 'rating_project' module, in order
to kill it.
Code is not modified, simply copy/paste at the right
place in 'project' module code.
However, 'enable rating on task' options is convert
into a res.groups that can be activated from the
project settings.
Customer portal is not dependent from website anymore. In this commit we
move customer portal code related to sale stock directly in sale stock
instead of website sale stock.
When making a SO with a stockable product with an expense policy set,
confirming
the SO will increase the delivered quantity according to the validated
picking. But
when unlocking and modifying the ordered quantity on picking the
delivered quantity
on SO does not change (it is if the product have no expense policy).
So the expense policy influence the flow in a way (update validated
picking) but not
on the the other (confirm SO) to compute SO line delivered quantity.
This commits make the expense policy not relevent when modifying ordered
quantity
on picking.
It also prepare the cleaning to unify API of delivered quantity
computation on SO
line for stock and service.
Since partner is not required on analytic account, nor
on AAL, we may have lines related to different partner (a 'support'
project for instance, with task for different partner, the AAL will
thus also have different partner). This use case is not possible with
the field override in account.
This commit will allow to do cost analysis by partner in the same
analytic account.
When installing account module, some field semantic on AAL
changed. Indeed this module modify some concept for its own
use cases.
Since analytic accounting is only used inside the company,
there is no interess to have the amounts stored in both
currencies. So the fields amount_currency, analytic_amount_currency
and company_currency_id can be removed. Doing that, we remove the
unfair related of account module.
Since quantity to invoice and quantity invoiced
already take into account refund invoices, the
calculation of those amounts can be simplify.
Also, we simply need those on the sale.report,
so removing them from sale.order.line model
will ease performance.
If an user (or a developer) wants to install this module twice, she
could not before this patch. Because those demo data call a function
that crashes if the state of the demo data has been modified... and
modifies it!
We avoid this issue by resetting the states of the demo data
explicitely (before a deeper refactoring)
Thibault Delavallée