Those values are only used on the website navbar when the user is in both groups
so the vast majority of the time they are done for no reason.
This reduces the number of queries by 2 on every page when the user is not admin
and/or multi website is not enabled.
Part of task-2061122
closesodoo/odoo#36483
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Commit 54d30d5194 introduced `lastmod` and `priority` on sitemap locs.
This was broken with 4ecbacaf59 which introduced `website.page` model as it
removed the `PageConverter`.
Before website.page:
1. PageConverter returned records with `__lastmod`
2. `enumerate_pages` loop on converters would remove the prefixed `__`
After website.page:
1. code to remove `__` was still there but the pages would be found and looped
on after that code, making it useless.
With this commit:
1. The code to remove the `__` is moved after searching the pages.
Following #36090
Related to #35464
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, every model having website_id would have the default
`set null` as ondelete value for that field. Exception for `ir.ui.view` and
`website.redirect` which are set to `cascade`.
This meant that deleting a website would basically transform all its specific
records into generic ones.
That would lead to unwanted behavior, such as multiple `ir.attachment` with
same URL, when 2 websites had been theme-customized. Deleting one of the
website would result in later crashes when trying to open theme customization
in the remaining website(s), since those website would find their specific scss
custom attachment as well as the generic one from the deleted website.
Probably more behavior might be problematic when deleting a website before this
commit.
To summarize the choice of this commit implementation, every model not existing
outside website module are set to `cascade` (website.redirect, website.menu,
product.wishlist..).
The rest should be in restrict, as we don't want to delete a whole forum, blog
or job, which should probably be managed case by case to decide what to do.
Thus, restrict is a good choice to notify user of what should be handled.
Some exception remains, ir.ui.view should be delete on cascade while sale.order
should be set to null.
opw-2038414
opw-2035249
closesodoo/odoo#35398
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this patch, if a website is deleted, its redirections will stay, affecting other websites.
Now, website-specific redirections will disappear along with their corresponding website.
closesodoo/odoo#35130
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Steps to reproduce:
1. Go to "My Website".
1. Click *New > New Page*.
1. Page title: "hello", add to menu: yes.
1. Add a snippet, write "hello 1", save.
1. Go to "My Website 2".
1. Click *New > New Page*.
1. Page title: "hello", add to menu: yes.
1. Add a snippet, write "hello 2", save.
1. Go to *Pages > Edit Menu*.
1. Edit the "hello" menu.
1. Change URL to `/hello-world` and save.
1. Click on the "hello" menu.
1. A page with "hello 2" appears.
1. Go to "My Website".
1. Go to *Pages > Edit Menu*.
1. Edit the "hello" menu.
1. Change URL to `/hello-world` and save.
1. Click on the "hello" menu.
Current behavior: Error 404
Expected behavior: A page with "hello 1" appears.
closesodoo/odoo#34913
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, it was not possible to install website_forum if the 'Main
Frontent Layout' had been COW'd.
When loading Forum Layout view which is a primary child view, it would crash
during view validation, not finding the element to xpath.
Triggering COW instead of copying fix the issue.
opw-2036119
closesodoo/odoo#35138
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.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>
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>
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>
- 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>
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>
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.