Currently, res.partner has:
1. `website_id` field hardcoded in website module
2. `website_published` field from website `website.published.mixin` in
website_partner module.
At the end, the res.partner model has all the field of the mixin
`website.published.multi.mixin` without having the mixin.
As a result, we have all the multi-website fields but we don't have access to
the mixins methods & computes.
Now, we use the `website.published.multi.mixin` on res.partner in website
module even if `website_published` is not needed if website_partner is not
installed.
+ add tooltip to `website` field to prevent warning since 2 fields would have
the same label
closesodoo/odoo#29711
*: tools, web, website, website_forum, mail, im_livechat
This commit refactors ir_http to make it more readable
and flexible.
Move the resize function of web/image to odoo.tools
Co-authored-by: XavierDo <xdo@odoo.com>
Co-authored-by: Antony Lesuisse <al@openerp.com>
closes: #28563
task: #1908896
Before this comit:
The `_views_get()` method would be called recursively for every
`inherit_children_ids`.
At the end of the method, we would get the complete view hierarchy, including
duplicate hierarchies for website specific copies (COW).
Then, the `get_related_views` that is calling `_views_get()` would be overriden
in website module to keep only most specific views.
But this would not be enough as it would leave orphans from other trees:
- Have a base view 'B'
- That has an inherited view 'I'
- That has itself an inherited view 'II'
- Now make the hierarchy specific on a website from 'I'
- And add another inherited view to 'I' on the generic tree
This become:
B
/ \
/ \
I I'
/ \ |
II II2 II'
As explained, filtering duplicates would not be enough as it would correctly
remove 'I' and 'II' from the generic tree but would not remove 'II2'.
At the end, it would return "B", "II2", "I'" and "II'".
Now, we correctly return only "B", "I'" and "II'" by ignoring generic trees
when there is a specific one.
Closes#29347
In a particular case, `_views_get` was mixing apples and oranges, ir.ui.view
and theme.ir.ui.view.
This was the case if a theme has a theme.ir.ui.view t-calling another
theme.ir.ui.view.
(Only theme's sale bridge cause this issue, eg theme_kea_sale.products)
Then, having that theme installed on a website would make all other website
without that theme to crash when opening the /shop customize menu.
Indeed, the theme.ir.ui.view would have the xml_id theme_kea_sale.search.
The generic view `website_sale.products` would have `theme_kea_sale.products`
as inherit child which is website specific and t-call `theme_kea_sale.search`.
Then, on a website witout theme_kea installed, opening the customize menu would
call `get_related_views` that would call `_views_get` that would loop through
inherit children calling `_view_obj` that would not find a view with that key
and would fallback on self.env.ref, finding the theme.ir.ui.view.
Note: `_views_get` might return specific view for another website but that will
be filtered on `get_related_views` override in website.
Step to reproduce:
- Have at least 2 websites and website_sale installed
- Install theme_kea on a website, it will also install theme_kea_sale
- Go on the website that has not theme_kea installed
- Go to /shop
- Open Customize menu, it won't load because of python crash
opw-1914576
Closes#29347
Before this commit, everyone could use the `fw` query string to force a
website during the dispatching. Plus, it would not require multi-website to be
enabled (multi-website only display UI elements, it does not affect behaviors
as they are already triggered even if multi-website is disabled).
This was intended but caused an issue for public users.
Indeed, the code that would force a website during the http dispatching would
be executed in `_add_dispatch_parameters`, after the auth methods.
Then, the request.uid would be the one from the website we were leaving and not
the one of the website we are forcing.
Public user would then not be recognized as such (if both websites have their
own public user) and would have interface glitchs (considered as connected).
Note: Next reload or page navigation would set the request.uid correctly.
Now:
To avoid such a behavior, we decided to allow only designer user to be able to
switch website with the `fw` query string, and only if multi-website is
enabled.
Note: The designer group check is done on the leaving website and not the
forcing one as `_add_dispatch_parameters` is executed after auth methods.
There is no way to check with which user the user will be logged on the
forcing website (Public, Same user, different user?).
Also, it would have to handle the same domain/different domain.
Step to reproduce:
- Activate multi-website
- Activate multi-company
- Create SiteA and SiteB
- Create CompanyA and CompanyB
- Set CompanyA on SiteA and CompanyB on SiteB
- A new public user will be bootstraped for CompanyB
- Optionnaly, setting manually a different public user for CompanyB will do
the same.
- Go to website 1, request.uid is PubUserA and request.website is SiteA
- Navigate to website 2 with `?fw=2` in URL, request.uid will be PubUserA and
request.website will be SiteB.
This is wrong, request.uid should be PubUserB as we are on SiteB
This will result in multiple bug, mainly the non logged user will see the
dropdown in the navbar as if they were logged in showing 'PubUserA'.
Fixes#27998closesodoo/odoo#29136
This commit replaces calls to pycompat helpers that were intended for
python 2 <-> python 3 interoperability for python 3 builtins, as python
2 is no longer officially supported by Odoo.
This includes:
* calls to imap/izip/ifilter replaced by map/zip/filter
* uses of text_type replaced by str
* uses of unichr replaced by chr
* calls to implements_to_string, implements_iterator removed
* string_types and integer_types replaced by str, int respectively
* calls to to_native replaced by calls to to_text
This is done in preparation to the removal of these deprecated helpers
in the following commit.
This commit only re-indents the COW feature code and adds comments to
help understand its tricky parts. Also evaluate the 'no_cow' flag only
once per write.
closesodoo/odoo#28753
Before this commit, when enabling a generic view from a specific website
context and that view already had a specific view for this website, the
view was duplicated again instead of writing on the already existing
specific one.
This is because we did not consider inactive views when checking if a
view that is being written already has a website-specific view.
closesodoo/odoo#28743
Before this commit:
1. If a view A is being inherited by a view B and C and the view C is doing an
xpath on B (but inherit A), then copying the tree to make it specific would
crash.
Indeed, when copying C, the view inheritance check (while doing the xml
check) would break since C would be tested against the generic tree and not
the new specific tree.
2. If a generic view being written with a website_id in the context had already
a specific child, we would copy both its specific child and generic child
for the same key instead of simply copying the specific one.
This happens if we triggered previously a COW on a child view, then only
that view had been made specific (and is still in the generic tree).
Then, when cloning the parent, we need to copy and make specific all the
hierarchy but ignore the generic elements if they already have a specific
one.
Now:
1. Fixed with adding the inherit_id on the copy vals
2. Fixed with filtering children_ids with filter_duplicate() before cloning the
children tree
opw-1908308
Closes#27914closesodoo/odoo#28405
Check that it makes custom binary fields into attachment as that's the
main reason for the change: when users create binary fields via Studio,
they're necessarily db-stored (as the interface doesn't allow altering
the attachment attribute and it's unclear how we'd handle users
switching it on/off every time), which significantly bloats their
database (and burns storage & backup space), especially as the primary
use case for binary fields is adding images and documents to records.
* check that binary fields are properly created as attachment=True
* add attachment=False on fields where that seems relevant (most but not
all of the fields previously using the default)
* remove occurrences of attachment=True
closesodoo/odoo#29308
web_editor dirty elements are saved by calling the ir.ui.view `save()` method.
As this method is called through call_kw _rpc on the ir.ui.view model, self
is binded to the view which has the `id` sent in the request.
In some cases, when editing a field for example, the id sent is the id of the
field's record (eg: product.template for price field).
In that case, the view binded on self will be the view with the id of the
field's record being edited.
If there is no ir.ui.view with the same ID as the field's record, self won't
exists.
This misbehavior resulted in no error luckily since we only use self to call
ir.ui.view methods without ever using self properties.
Since multi-website 47b00c5d53 overrided the `save()` method and used self.key
it was crashing when the self record did not exists.
This commit will fix that by doing the multi-website check only when it is a
view and not a field that is being edited. (We know that if xpath is set)
opw-1904637
Step to reproduce:
- Go to a product on ecommerce, eg product.template 13013
- Edit the product price field, the oe-id attribut is 13013
- Delete the ir.ui.view that has the same ID than the product (13013)
- Save -> It will crash since self is binded to "ir.ui.view(13013,)" but it
does not exists and we try to access key
closesodoo/odoo#28469
On res.config.settings for website, when removing a language from language_ids, if this language is defined as default_lang_id, the default language will be updated by an onchange to prevent any inconsistency.
The same should happen when doing this directly on the form view of a website record.
closesodoo/odoo#27727
Before this commit, our asset bundles had a special behaviour for
bundles of type css: because of an old limitation in IE9, css files had
to be split to make sure they had less than 4095 rules per stylesheets.
Since we no longer support IE9, this code can be removed, which should
slightly simplify the bundle code, and should slightly reduce the number
of requests required to properly load odoo.
closesodoo/odoo#27933
Before this commit
When user was in company A and try to create a second website for company B an
error was raised, because the search from user in company A don't find a public
user in company B and the same default user (public-user@company-B.com) was
created again before to be catched and raised by the sql contraint login_key.
Now we use '-' instead of '_' to avoid parser of email to detect it as invalid
After this commit, we don't have anymore the error:
- 'You can not have two users with the same login!'
or - 'Login must be a valid email address'
opw-1891315
closesodoo/odoo#27873
Commit 850e1675eb improved the website.menu creation on module install
(eg: /shop for website_sale).
This commit aims to do the same on module uninstall.
Before this commit:
Uninstalling a website module would uninstall its website.menu (/shop) stored
on the default menu tree.
But the copies of that default menu, on websites, would remains.
Indeed, there is no direct link between the default menus and its copies.
More annoyingly, installing that website module again after uninstalling it
would create a new copy of the default menu, resulting in multiple same menus
on website.
Now, if the menu to be uninstalled is in the default tree menu, we remove all
its copies (the website.menu having that same URL).
Closes#27488, closes#27721
on the webiste sale, have a category with a subcategory
Then in the customize menu, enable "ecommerce categories"
Before this commit, the option to have collapsible categories wasn't there
This was because, due to multi_website, the children views of the "categories"
that were inactive weren't written upon when copying their parent
After this commit, the functionality is back
OPW 1893169
closesodoo/odoo#27796
Purpose
=======
display_name is equal to doing name_get()[0][1]
Replacing name_get()[0][1] by display_name could be good for 2 things:
- Uniformization of the code
- Probable optimization if name_get is used inside a for loop on a recordset (as the values will be prefetched and put in the cache).
TaskID: 1849250
closesodoo/odoo#26341
Commit 7077f18e3 tried to fix the website event menu issue.
But the fix was wrong and fixed only the event having a website_id set.
After the 7077f18e3 fix, event with a website_id set are working as expected
but the ones without a website_id are not working.
Indeed, it will create a website.menu without a website_id which will result in
the menu being duplicated for each website (multi-website rule).
The required on website_id when activating website menu on event was trying to
hide that new issue but it was problematic since:
1. We were removing a feature for no reason as it would not be possible anymore
to create a generic event (no website) with website menu activated.
2. The required would only work in form view, demo data or custo data loaded
through xml without a website_id but having website menu activated would
still bug and would not have a menu. Worst, the menu would be duplicated for
every website and added to the website navbar.
Now, regardless of the event having a website_id set or not, activating or
deactivating event menu will work.
closesodoo/odoo#29036
* base, website
An image URL may be like "/web/image/<xml_id>" where <xml_id> is the
xml id of an ir.attachment. In fact, the route does not use the xml_id
but the 'key' field, which is normally equal to the xml_id for standard
attachment. In the context of themes + multi-website, the value used as
an xml_id may refer to a theme.ir.attachment instead of an ir.attachment
and this led to a bug as those must not be used the same way.
The crop route which gets image information is adapted by this commit to
always look for the *current website* *ir.attachment* related to the
given xml_id/key.
Thanks to @kig-odoo for spotting the issue.
Closes https://github.com/odoo/odoo/pull/27588closesodoo/odoo#27611
Using `request.env` should be reserved for code that lies outside of
model methods (typically: controllers). Model methods have to use the
appropriate `self.env`.
This particular case caused frequent Python-PostgreSQL undetected
deadlocks during installations of website-related modules in 12.0.
One way to reproduce it was to trigger the installation of both
`website` and `website_form` in a single transaction, with neither
pre-installed.
Installing Apps that depend on both would do the job, such as
`website_sale`, provided that GEOIP is available on the system.
In details:
During installation of `website`, new attachments creation would call
get_current_website (see 602807acdf and
4f6ec1cd2a), using the wrong database
cursor: the one from the request instead of the one for the
installation, as provided by `ir.module.module._button_immediate_function`.
This would acquire database locks on `res.country` and `ir.model` in
the wrong transaction, later blocking alterations to `ir.model` in
the installation transaction, e.g. for website_form's
'website_form_access' column.
This combination of events was possible before 12.0, but more difficult
to reproduce as module installations used to happen with a super-user
account, ignoring ACL checks and therefore not locking `ir.model`.
Jeremy Kersten