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>
On a eCommerce page were there was no SEO optimization change:
- Customize > Activate "eCommerce categories"
- Customize > Activate "Colapsible category list"
- Promote > Optimize SEO > Change description > Save
Nothing happens.
Actually, an SQL error is raised because of the `ondelete='restrict'`
set at:
https://github.com/odoo/odoo/blob/897feb553e6ef75af9434cb77436b26abde3a761/odoo/addons/base/models/ir_ui_view.py#L212
In this case, we have the following structure:
```
View 1
|
---> View 2 (Website-specific)
|
---> View 3 (Website-specific)
```
For example:
```
Products
|
---> eCommerce Categories (Website-specific)
|
---> Collapsible Category List (Website-specific)
```
Since the inherited view (View 2) is website-specific, we duplicate it
and try to unlink it. However, this view has children, which raises the
error.
To solve the issue, we re-attach the children of the inherited view to
its copy. In a realistic situation, the children of a website-specific
view should also be website-specific, so there is no need to apply the
'copy or re-attach' logic recursively.
We end up with:
```
View 1 (Website-specific, duplicated)
|
---> View 2 (Website-specific, duplicated)
|
---> View 3 (Website-specific)
```
opw-1997946
closesodoo/odoo#33787
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit removes the field `datas_fname` from `ir.attachment` as
it was unnecessary and most of the time the duplicate of `name` or
`url`.
Task #1909865closesodoo/odoo#32976
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
This commit goal is to encapsulate every tour-test into a separate assets
bundle that would be called only during tests (command line) or by URL
(debug=tests). That way, a lot of .js files would not be loaded anymore
uselessly outside test mode and will speed up the page loads (especially in the
frontend as the backend do not reload the page anyway).
In order to do that, we needed to propagate the `debug` state from page to
page.
Otherwise, every page change during a test would simply lose the debug mode and
the test would stop as the test assets would not be loaded.
As we could not add the `&debug=tests` on every link (either hardcoded or
preprocess during the rendering), it has been decided to store it in session.
Technical summary:
1. `debug` state (currently only stored in URL) will be stored in session.
Either when adding the `debug` param in URL (handled with _dispatch) or by
starting Odoo with `test-enable` or `test-file` (handled by session init).
2. Once activated (and so set in session), debug mode will remain activated
even if not visible in URL (after a page navigation eg).
To deactivate it, set its value to nothing, `debug=`. That will exit debug mode
(whatever mode it is: debug, assets, tests).
3. As tour-test files are now in a separate bundle, every layout (when needed)
should `t-call="web.conditional_assets_tests"`.
As it would be redundant and verbose, no `t-if` is needed on the t-call to
load it only in test debug mode. That will be handled by
`compiled_assets_tests` that will actually do the conditionnal t-call-assets
to web.assets_tests, if tests debug mode is activated.
4. In addition to separating the tour-tests files in a separate bundle, we also
moved those files to a specific folder under /static/tests/tours next to
QUnit tests.
5. Also, tour files will be moved in a specific folder /static/src/js/tours for
cleanness purpose (those files will still be kept in their 'normal' assets
as needed outside test mode since it is tours).
This will be done in the next commit.
6. It is possible to enable multiple debug mode, such as 'tests' and 'assets'
together. Simply separate debug modes with a comma, eg '?debug=assets,tests'
task-1934445
Comes with https://github.com/odoo/enterprise/pull/4281Closes#33213
* http_routing, portal, rating, survey, website, website_survey,
website_slides_survey
Before this commit, the final base layout of website was a fully
overridden layout of the one in portal, which was somehow a duplicated
one of the login one in web, which... so lots of duplicated code.
This commit is a first step towards a better organization:
1) The web app defines a frontend layout (to include base frontend
assets), with a base company logo as header.
2) The portal app modifies that layout in place to include the base
header, footer, ... It also uses a primary extension of it for
portal pages.
The survey app simply uses the above layout instead of defining its
own (by primary extension to include its own assets for its own
pages)
Same goes for the rating app and pages.
3) The website app modifies that layout in place to include the UI
assets, to add website UI, ... This allows to create frontend apps
which do not depend on website, with a non duplicated layout that
will be automatically adapted if website is ever installed (this
therefore allows to get rid of website_survey definitely)
This commit also fixes the session info system and the translation URL
on the frontend side to not require to redefine the whole session_info
for portal, website, ... Now the frontend session_info is defined in web
and http_routing extends it to add translation informations, then
website extends it again to add its own elements (not to redefine them
all as before). Note: before, http_routing defined the translation route
but only portal was adding it in its layout...
This is an adaptation of the work that was done with commit
https://github.com/odoo/odoo/commit/99821fdcf89aa66ac9561a972c6823135ebf65c0
Note 1: Many frontend but non-website apps (not only survey / rating)
could probably use this too but this would be the topic of another task.
Note 2: survey currently depends on http_routing but does not add itself
in the list of frontend apps to translate, it probably should.
Note 3: web_editor does currently not depend on http_routing but does
add itself in the list of frontend apps to translate, it thus uses a
function it does not really depend on... to check after its work-in-
progress refactoring.
task-1961045
closesodoo/odoo#33825
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
- Create 2 companies A & B
- For each company, create a website linked to a different URL and
activate 'Free sign up' and 'Specific User Account'.
- As a public user, go to website of company B
- Go to 'Sign in > Don't have an account?' and create an account
The user is created in company A (the company of the user template)
instead of company B (the company of the website).
We set the company of the user based on the company of the website.
opw-1962197
closesodoo/odoo#32823
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, when you go on website config settings, you can't save.
This is because the website default lang field is not set anymore (supposed to
be set in onchange), and since it is hidden in the view if only one language,
there is no clue about the error field.
Following d0bb596f1d, x2many fields of new records are new records, meaning
that:
`self.many2one in self.x2many`
is not true anymore since self.x2many is a new record.
Also:
`self.many2one = self.x2many[0]`
is not working as before, the new record is not saved in the many2one
closesodoo/odoo#33716
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Generate a unique URL for translations and cache them forever in the
browser. This reduces the number of requests, in exchange for computing
the hash of the translations when the session object is added to the page
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closesodoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Since b5a12b4aac the website_id was not set anymore.
Indeed, before this commit website_id was the field from the inherits, thus
when writing on website_id from res.user, we would write on the partner field.
But with b5a12b4aac the website_id was explicitely overrided on res.users as a
related to res.partner (its inherits) with readonly=True.
Thus, writting website_id on res.users was not working anymore.
closesodoo/odoo#33521
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, the URL of the bootstraped homepage for a new website
could be '/-1' instead of '/'.
Indeed, creating a new website ends up calling `page.copy` which try to get an
unique URL for the website (to avoid duplicated URL after copy). Typically, the
copied page will have a suffix (-X).
But `get_unique_path` in charge of doing that is based on `get_current_website`
method which will/could return a wrong website (not the one we created).
For instance the one forced in session after using the website switcher or
creating a website or installing a theme.
As those website already have (most likely) a homepage '/', get_unique_path
will create the bootstraped homepage with '/-1' as URL.
Step to reproduce (among others):
- Create a new website in backend through res.settings screen
- Create another new website, it's homepage will be '/-1'.
- Repeat indefinitely, every two website created, the bug will appear.
(One out of two, the bug won't appear since it will try to get an unique URL
on the previously created website which only has '/-1' so '/' is assumed
unique)
closesodoo/odoo#33372
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Previously the image that we uploaded as a favicon of the website was not
resized, so it could be extremely excessive in size and resolution, and it also
was not guaranteed to be a square.
Now we always resize it appropriately and save it as an ICO file.
The default favicon is now applied to all websites instead of only the first.
task-1958000
PR: #31811
Reintroduces 5324284f5 that was reverted because in the case of an URL
like /payment_stripe/static/src/js/stripe.js directly inside a QWeb
template, we would possibly get:
/fr_FR/payment_stripe/static/src/js/stripe.js
Which is not accepted by werkzeug SharedDataMiddleware we use to serve
static data in /{module_name}/static/ directories.
Added test without changeset failed with:
- test_process_att_no_request_lang: <AssertionError>
line: self._test_att('/en_US/', {'href': '/'})
wrong result: {'href': '/en_US/'}
- test_process_att_with_request_lang: <AssertionError>
line: self._test_att('/', {'href': '/fr_FR/'})
wrong result: {'href': '/'}
- test_process_att_matching_cdn_and_lang: <AssertionError>
line: self._test_att('/en_US/a', {'href': 'http://test.cdn/a'})
wrong result: {'href': 'http://test.cdn/en_US/a'}
- test_process_att_no_route: <AssertionError>
line: self._test_att('/my-page', {'href': '/fr_FR/my-page'})
wrong result: {'href': '/my-page'}
- test_process_att_url_crap: <IndexError: list index out of range>
line: request.httprequest.app._log_call[-1],
opw-1922051
closes#32095
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit, if the website's company was different than the user
company, the ecommerce would use the user's company instead of its own
pricelists.
Step to reproduce:
- Set company2 to website1
- Create a pricelist1 for company1 and a pricelist2 for company2
- With an user from company1, visit the website1.
- The pricelist used will be the one from the user, pricelist1 and not the
pricelist2 from company2 which is the website1 company.
Before this commit, at multiple places to check if we were in a frontend
context we would check if `request and hasattr(request, 'website')` and
then access `request.website`.
Now, we call an utility method to get that website if we are in a frontend
context. If not the method will return False.
This method will be usefull for incoming pricelist fixes & tests.
Indeed, we will have more check of that kind and this will be easier to mock as
mocking this method will be enough, instead of mocking every method doing that
if condition to simulate a frontend context (to do website tests in python
wihout having to go frontend with a tour).
Before this commit:
The `if` condition doing a `View._views_get` was supposed to be a sort of
'hack' for when the error occured in a child view (as the template raised would
be the parent, not the broken child).
But since we refactored that part to use etree, it was actually going into that
condition for every error even if the error was in the called template.
Proof is, we only set `editable` in that if condition, meaning going in the
else would actually prevent to show reset template.
Indeed the following code would always be true:
et = etree.fromstring(view.with_context(inherit_branding=False).read_combined(['arch'])['arch'])
node = et.find(exception.path.replace('/templates/t/', './'))
as read_combined returns all the view hierarchy DOM
Note: We could not fix this by checking exception.path against `arch` as we
could have false positive (eg the child view replace the <p> element by another
<p> element which is broken, then the path would be found in the parent view
even if the error was in the child view).
closesodoo/odoo#31515
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Commit 5a81d8883 fixed the COW view deletion on module update but introduced an
error when installing a theme.
Indeed, when installing a theme, the first step is to remove the currently
installed theme from the website (by unlinking its ir.ui.view).
Commit 5a81d8883 introduced the fact that deleting an ir.ui.view during a
module uninstall also search and delete the COW views, calling
`_get_specific_views` (that expects a singleton).
When installing a theme, it calls `_theme_cleanup` which search COW views and
unlink them. If not cow view, unlink is called with an empty record set raising
the singleton error.
closesodoo/odoo#31662
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, when a view was removed during a module update (eg: the
record was deleted from the file), its COW views would not be deleted.
This could lead to unwanted behaviors including tracebacks(1).
This commit is somehow related/an extension of b5fe23055d that handle COW view
write during module update and 2e32cc5aa3 that remove COW views during module
uninstall.
task-1931683
Note: Some existing tests had to be run post install
(1) A view doing a t-call is COW'd, then that view and its t-called view are
removed. If the cow view is not removed, the t-call will crash (see tests
in this commit for detailed case).
closesodoo/odoo#31295
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Reset view feature code still had remains of initial release (Odoo 9.0).
At that point all the view tree was returned, not only the broken view.
Since it has been fixed in 12.0 and refactored in saas-12.3 with this PR, it
now only takes the broken view as argument, handling multiple views has no
sense anymore.
Thus, this commit remove the (unused) multiple view compatibility.
This commit also add a test to test the refactoring or this feature.
Coming from #32009 (task-1943001)
Before this commit, when a t-call was calling an unexisting template, a QWeb
exception would be raised with the callee and not the caller as template.
That would be an issue since there was clean way to retrieve the view that did
the wrong t-call, for instance to be able to repair that view.
Now, in such a case the caller view will be returned.
That will avoid crapy code to retrieve the caller, eg searching on every Qweb
view archs.
Coming from #32009 (task-1943001)
- Store previous arch to be able to reset it (soft reset)
- Add the possibility to reset from file if possible (hard reset)
- Adapt frontend reset page to these new fields
- `arch_fs` hack to check if view was modified got moved to new field
`arch_updated` as we now need to keep track of the `arch_fs` to reset a
broken view.
Closes#32009 (task-1943001)
Christophe Simonis