Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Add the support to be able to specify exlicitely module, class and method name in test_tags
Before this commit, there is no distinction between module tag and test tag. Meaning
that --test-tag module_name will replace the default +standard tag and execute all test
of the module.
This commit tries to keep the initial behaviour, while addind new features, like explicit
modules tag with /module_name, as well as class (:class) and method (.method)
Some usage examples:
--test_tags /module will execute all standard test of module
--test_tags :class will execute all standard test with class name 'class'
--test_tags .method will execute all standard test with method name 'method'
--test_tags external/module will execute all external test of module
--test_tags */module will execute all tests of module,
--test_tags */module,-standard will execute all non standard tests of module,
--test_tags -/website:TestUiTranslate.test_admin_tour_rte_translator will disable only rte translator test
closesodoo/odoo#34756
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit, `language_ids` field would be required through python code.
It is the only website res settings field that is required=True.
That's an issue since the website settings can be empty if there is no readable
website. In that case, the settings won't save.
Website res settings should be set as required XML side, in the view,
conditionned on the fact there is a website selected or not.
For the reason why there is not always a website selected, see bb473003d7.
closesodoo/odoo#34706
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Since https://github.com/odoo/odoo/pull/29442, "Animations" became
"Public Widgets" (even though the Animation class still exists as an
extension of standard PublicWidget).
Since that refactoring an error was introduced which made the code
modify the prototype of the 'events' key each time a public widget with
a 'read_events' or 'edit_events' was instantiated (while the goal was
to modify the widget's own 'events' key, not from the prototype). This
was the cause of very ununderstandable errors...
closesodoo/odoo#34600
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
If there is no website selected, there is no point to show the specific
settings (which are supposed to be wrote on website model, that will write on
an empty recordset) as it just flood the screen for nothing.
If multi website is enabled, tell the user he could select a website to load
the settings.
If not enabled, the user can't select a website as the select will be hidden.
In that case, just tell the user that he could create a new website for this
company.
More than just a display improvement, it will also prevent misunderstanding of
the website settings when an user arrive on the settings with no website
selected.
Followup of https://github.com/odoo/odoo/pull/34706closesodoo/odoo#34764
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
During checkout, the user can create a new billing (only for public user as it
will create a 'normal' `res.partner`), a new shipping, edit its billing (that
will edit himself) or edit its shipping address.
All those cases will go through the exact same methods, public user and logged
in user included.
This previously led to multiple issues and multiple fixes to correctly set
`company_id` and `website_id` on the address (res.partner).
See 44372471ef that fixed the `website_id` part.
See 3a0f05f33 that fixed the multi-company behavior, but needed 2ba71140 to not
modify the company of an already created partner, but was still incomplete as
after that fix a logged in user would still have the admin (sudo) company
instead of the website one as supposed.
This commit will fix that bug and add some tests for all mentionned issues.
Related to #28853 as we want to backport the mentionned commit but needed to be
fix first.
closesodoo/odoo#34596
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
closes odoo/odoo#31520
---
backport of 8e2f9a4fe2
Initially a improvement, it is now backported in 12.0 to fix#34430closesodoo/odoo#34474
Signed-off-by: Christophe Simonis <chs@odoo.com>
We have multiple ways of simulating a frontend context while running python
tests (mainly during TransactionCase):
- `MockObject` class from 8557bcfa30
- `simulate_frontend_context` method from a5a5a57e48
- `DotDict` from f8efc9a957
This commit moves `MockObject` to misc to be reusable and adapt it to be
accessible by dot notation with `DotDict`.
Part of #34396
Following the new editor of https://github.com/odoo/odoo/pull/29775,
many editor styles and behaviors were broken:
- Translation colors
- Background sizing cursor
- etc, etc
This is because commit https://github.com/odoo/odoo/commit/b49745e52d7a7bc27afd416206dcd5fa242aa07a
decided to wrap all the scss rules of the website editor scss file in
a `body.editor_enable` rule without any care. For example, the rule for
translation colors became:
`body.editor_enable > html[lang] > body.editor_enable > ...`
which obviously does not work.
closesodoo/odoo#34190
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Let a database with company C1, C2,
and a website W belonging to C1, used for both companies.
Settings in C2 cannot be saved without setting a website.
At settings load W is removed from C2 because it belongs to C1.
So reset C2's website to W.
This triggers a (useless) write of company_id (C1.id) on W.
Then we have w.user_id.company_id.id != self.env.user.company_id.id, (C1 != C2).
So if contacts are not shared, then accessing w.user_id.company_id would cause
an access error because of record rules, preventing the save.
As a result, settings are unusable for company C2.
opw 2008887
closesodoo/odoo#34102
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
Before this commit, those pages would be flag as noupdate.
If not modified, those view would not get modification on module update, which
is not logic.
Now, those view will benefit from any update. It makes even more sense since
multi-website as those views will never get modified directly (it will COW).
closesodoo/odoo#33920
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The BS3 'show' class cannot be supported as BS4 still defines a 'show'
class for other purposes which conflict with its former use (tab-pane,
fade effects, ...). Adding more complex rules won't solve the problem as
they would change css rules priorities.
closesodoo/odoo#34139
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Commit https://github.com/odoo/odoo/commit/4f9a0cb4fcdfa9fee66c042593f4d411dd0e192f
introduced a way for users to enable a compatibility template to provide
support for some old BS3 classes.
Some of these classes are the bg-gray-* classes. The problem is that
enabling the compatibility file forces them to the new BS4 gray values
while the user may have done a custo to generate them automatically
from other gray values. This commit allows to keep the compatibility
file enabled, without overriding compatibility grays the user may have
provided on its own.
closesodoo/odoo#34134
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Adrian Torres