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.
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
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
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
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
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`.
* web_editor, website_blog, website_crm_partner_assign, website_links,
website_livechat, website_mail_channel, website_mass_mailing,
website_slides
Calling a model's method thanks to an RPC will now always send the
web_editor context automatically, making sure the method gets the
website_id all the time, removing the need to guess the current website
(now the get_current_website method uses the context website_id if any).
Note: other routes already have the website_id via request.env.context
if they correctly set website=True (this commit also adds website=True
for scss files customization routes).
Previously, for multi-websites it was decided that:
- creating a new website would not get already existing apps menu (shop,
blog, forum..).
- installing a new app would create the app's menu on existing website
This was decided mostly for technical reason but it is a weird behavior.
This commit saves the installed apps menus in order to copy them on new website
If this default menu got deleted, we ensure a minimalist tree menu for new
website
Note: This also fixes the bug where installing a website_module more than once
(with -i website_module in command line) would create the menu (blog, shop,
forum..) on the first website a second time.
This was because the website.menu.create() overrided in website would
return the last created record in the self loop, thus the last one created
would be the one set to the xml_id (ir.model.data).
This commit closes#27253
This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
Forcing website on session before navigating to the other website would not
work as expected if the other website has a different URL (hostname).
It would force the website on session on current website, then navigate to
second website which could still had another website in session.
Now, we force the website in session once we land on the website in the
dispatch() method.
Step to reproduce:
- Set website1 to 127.0.0.10
- Set website2 to 127.0.0.20
- From website1 click on website2 in website selector
- Website2 is forced on website1 session (wrong)
- You land correctly on website2 and see website2
- From there (website2) click on website1 in website selector
- Website1 is forced on website2 session (wrong)
- You land on website1 but see website2 since website2 was forced on
website1 session at steps 3/4.
This is even more trickier when there is a third website without a domain in
the equation (meaning this website can be seen from website1 and website2
without changing URL (hostname)).
This gives the user an overview of the possible actions,
including those he currently does not have installed.
It allows him to quickly install the missing applications
without having to go on the backend.
The commit also improves the existing actions:
- correct handling of the actions deferred
- add some translated terms
PR: #27110
task-1885419
Before this commit, when we ask for get_current_website, we always
get one website. If we don't know which, we took the first one.
Now we can ask, if we are into a website context or not with a new argument fallback.
Previous code like:
website = get_current_website()
if website:
...
Have now a sense ;)
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
Since Odoo saas-11.3, copying a record with it's inherited record in the copy
dict values will trigger translation of the inherited record's fields which it
shouldn't.
This issue will be fixed with #27108
In the meantime, we can avoid this issue by not copying the view separately
from the page as this code is a residue from the old implementation (no
inheritS between `website.page` and `ir.ui.view` + they both had `name` field)
and is not usefull anymore.
Modal generic:
- Fix footer overflowing buttons by pushing them to a new line.
Page manager:
- Add an SEO column to easily see which pages have incomplete SEO.
- Add an edit SEO column to navigate to the SEO modal on said page.
- Hide "edit in backend" column as debug.
- Generally improve the whole view by adding appropriate titles on icons, etc.
SEO modal:
- Improve general style.
- Add description length alert.
- Restructure the keyword table/suggestions.
- Reset page meta to their initial value on Discard.
- Various small usability improvements.
PR: #26897
task-1850579
Advanced user can do it from the backend by the way and it is not
obvious to understand the impact to set/unset this option.
Seems like I was the only guy to think that this feature was needed
task-1878245
- Remove useless onchange company id from website, now that we configure it
in the res config.
- Add the onchange company into the res_config_settings
- Remove left duplicate data from mass_mailing
- Add ALL social links into the res config
Reorder res.config.settings for website
Make website_id in no create in most view
Revamp res.configsetting and view Form simplified
Transform old 'useless' stored field for presentation by computed field.
We can consider that if there are not key, feature is disable.
Co-authored-by: rde-odoo
Co-authored-by: jke-odoo
This behavior is useless in the front end (`clone_page`) as people cloning a
page will leave the page with copy in the page name without even noticing it.
Furthermore, creating or copying a website will bootstrap (clone) some pages,
suffixing all of these page by 'Copy'.
With this commit now user can set custom meta image from the seo dialog. If the
user sets such image then it will be displayed when the user shares that URL in
social sites.
By default, it will show the list of images used in the current page.
Alternatively, user can use media dialog to select/upload images. By default, it
will take the company logo as a meta-image.
We also improved how custom meta tags are handled for different pages, Now we can
set custom meta tags based on the model and we can override '_default_website_meta'
method in case you want to change default meta values from the specific model.
e.g. For products displayed on the shop, if we want to change the value of
og:image to product specific images instead of default logo
In future, it will be used to add model specific metas like og:price, og:currency
We passed 'website_company_id' in frontend session info because we display
company logo in dialog for all pages. We can't use /logo.png as it is not
updating in multicompany and multiwebsite.
task id: 1835370
Closes: #25430
From now, when you install a theme, it load the data from xml to template
table theme [ir.ui.view|ir.attachment|website.page|website.menu].
Data are only copied from this template table into the real table when you
choose a theme on a website; Making them website_specific and with a link
to the original to allow futur update.
A special case is done to create theme.ir.ui.view when you are installing
a theme, even if you continue to use template tag to create quick view.
Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
Set up env & tools for module website multiwebsite (blog, event, sale..)
website_id in modelConverter and ir_rule
add _compute_domain_keys to have a different cache per website
or rules would not be correctly website_dependant
eg: blog 1 on website 1, blog 2 on website 2
access blog 1 from website 1 => can access -> normal
access blog 1 from website 2 => can access -> should crash because (ir rule)
split mixing website.published.mixin and website.published.multi.mixin to have
website_id only on last one.
multi mixing will:
- override website_published compute to take current_website into account (not in backend)
- force website when clicking on published in backend
- website blog, website_sale, website_event, website_forum, website_slides are now multi website
Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
google analytics, google map api key, ... can be set by website
Remove useless duplicated label
Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
In some case like for website_menu or res.partner from the sale_order form view
it is nice to know easily on which website this record is depending.
Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
Adrian Torres