*: web, web_editor
Instead of three lists + one map to define font information and user
choices saved as the index of the related fonts in those lists, the
fonts are now stored in an unique map <font-name> -> <data> and the
user choices are saved as the font name. This allow to have a visually
better definition of the fonts and allows to reorder fonts in the UI
without losing user customization (and actually simplify some code).
Unfortunately any user font customization < 14.0 will be lost, but this
is a small price to pay (users can still rechoose the same font in the
editor UI where they will go anyway to discover all the new shiny
features we are introducing there).
Part of https://github.com/odoo/odoo/pull/54065
task-2291398
closesodoo/odoo#54065
Related: odoo/design-themes#269
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The CDN implementation for resources works by matching well-know attributes
(`href`, `src`, `action`) that hold URLs matching the CDN filters and injects
the CDN prefix. However 13.0 introduced lazy loading for assets in #32181,
so the attributes are now prefixed with `data-` and replaced at runtime.
This PR updates the tag matching in order to cover both variants of
attribute names.
closesodoo/odoo#54156
X-original-commit: 6d4b5fcd11e96fd170d8df1ed27be2a8cea26e8b
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Now, slug uses seo_name if field exists before to fallback on display_name.
It allow to have a custom url without change the product name already used in
backend e.g. or just because you want add some keywords for seo.
task-2291676
When a theme was chosen, the footer disappeared if any footer template
different from the default one was previously selected. The related
code is actually meant to revert back to the default footer template
when switching theme (allowing the theme to set a different default one
if it chooses to), but it forgot to enable that default one... and was
only disabling all non-default footer templates.
closesodoo/odoo#53762
X-original-commit: 9f5c630768cbcf56aec97ba4296f90f3d7fbfa5b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, some code was resetting some default website config
on theme change.
Problem 1:
This was not done when *removing* a theme. Thus when you wanted to go
back to a default website theme, you were not properly reset to the
default theme config. This could actually crash: some themes define
more fonts than others; so if you selected font 13 in one theme then
removed the theme, the default one would crash if not properly reset
as font 13 would not exist.
Problem 2:
It was done for every theme dependency, making theme change slower for
no reason.
Problem 3 (theorically, not tested):
The current code worked by chance as it called the website
'make_scss_customization' method without giving any website to it. It
actually worked by fallback on the right website in normal user cases
(user in the context of installing a theme on a specific website) but
may not be working when trying to install a theme on a different website
calling those functions from custom code.
Now, a dedicated method is there for config reset and is called at the
correct place with the right website in the context.
closesodoo/odoo#53743
X-original-commit: 7307d696449ea2b7a231b0b9087e64f6bbf65d26
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When a view is:
- a specific view (duplicated for a specific website)
- inherited by a new view that is translated
the inheriting view will also be duplicated, but the translation will
only be created for the generic version and not the specific ones.
With this changeset, we duplicate translation of arch_db terms of the
generic view onto matching specific views.
Without the change, added test fails with:
AssertionError: '<div>hello</div>' != '<div>hi</div>'
loading module translation copy translation from base to specific view
fixes#51579
opw-2261278
closes#52451closesodoo/odoo#53012
X-original-commit: 989d58d26f8803b40c1411cb97b0171b05d274d7
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Taking a self and a separate action seems unnecessary given self *is
an action*.
Only do this change for the "new" naming scheme, so the old one keeps
working as-is.
There is no reason to call these directly, in fact it's not really
possible to do so as they expect an `action` object as first
parameter.
* warn against the presence of rpc-public runners
* move runner selection outside of ``run``
* improve doc a bit maybe
When you create an ir_ui_view form the backend, the encrypt function
was called with a Falsy value and crash with error:
TypeError: secret must be unicode or bytes, not bool
Now, when you create view from backend, we only set password if it is a qweb
view. In case of update, the field is dirty, so if you don't update it, it
will be not write.
closesodoo/odoo#53348
X-original-commit: 3d9101db0f7cc0adc1f34721c38b4c2f7089566d
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Wrong usage of self in for loops makes some apparently multi-friendly
methods not work correctly when called with a recordset of len > 1.
This commit replaces those references by the correct unique record
reference which should be used at this iteration of the loop, avoiding
potential exceptions or wrong behavior in the concerned methods.
closesodoo/odoo#53320
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
Before this commit, published column was not shown as option and user not able
to multi edit at a time in list
In this commit, we ease the purpose of multi edit at a time and keep a column
in option so user can keep hide it when not needed and can show as well.
task-2153812
Closes#43029
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The domain field on a website is used:
1) to get the right website in case of multi-website
2) to compute base URL of canonical URL
For the 2nd usage, a scheme can be set (eg. https://hello.world) that
will be used instead of default http://
opw-2266224
closes#52784closesodoo/odoo#52796
X-original-commit: bc2899ba0905fe14a481d922a8fc57decf069692
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Things to know about specific views:
Since the introduction of website specific views, we can have multiple
views that are related to a website (specific views). These views have
no xml_id as it is only set on the original view (generic view).
We rely on the view's key to identify related views as it is the same
for all specific views of a generic view. Also the key is equals to the
xml_id.
When a generic view is updated, we will check if the specific views have
the same values as the generic view. If it is the case, the value that
are the same are considered updatable and are updated on both the
generic and specific view. Else these are considered as noupdate.
When a generic view is created we will check if the potential parent
generic view has specific views. If it is the case we will create a copy
of the created view for each specific view.
The issue:
The method that checks if a created/updated view has specific views is
located in website. When we update a module, each modules are
initialized and updated in a specific order. If a generic view that has
specific views located in a module loaded before website this view's
specific views will not be updated/created as the method does not exist.
This issue is mainly affecting portal views at the moment.
The solution:
For write:
We now COW(copy on write) the views in base module, meaning this will
apply to all qweb views that are duplicated and not only the website
specific ones.
For create:
We will create the generic view as before but wait until we have
updated all the modules to gather all generic views that are supposed
to have a specific view but don't and create the specific views.
This will result in a change of behavior being that if a specific view
that have a parent is deleted it will be recreated on update
(same behavior as a generic view).
closesodoo/odoo#52629
X-original-commit: b1a90ee2bb441aa52e3cf4607c43fb464b55b1d7
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: fja-odoo <fja-odoo@users.noreply.github.com>
*: base
Previously, cropping an image was done inside of a modal window, turning
it into an inline widget makes the editor feel more integrated and
allows you to better see the result of cropping directly in the page,
it's also less intrusive to the user's edition workflow.
At the same time, the way cropped images are saved was refactored to use
the new original_id field on ir_attachment, as the old system was
creating problems.
Part of https://github.com/odoo/odoo/pull/51517
task-2192755
*: web_editor
Note: on color palette change, all the colors of the user are reset and
he is warned about it.
Part of https://github.com/odoo/odoo/pull/52224
task-2197038
*: web, web_editor, website_blog, website_event
New o_cc${xxx} classes where ${xxx} is a number [1-5] to style snippets:
they come with a background color, a text color, headings colors, a
link color, primary button colors and secondary button colors which
will later be possible to customize by the user.
The classes are made so that they are working on two levels. So if a
column receives a color class and the snippet too, everything will work
fine. More than 2 levels are not supported and the editor is made so
those cases should not appear. See o_colored_level class.
Part of https://github.com/odoo/odoo/pull/45856
task-2197038
Issue
- Install "Website" app
- Go to Website->Configuration->Redirect
- Click on Create
- Set "Action" to 308
- Set "Url to" to nothing or any url
with no leading '/'
The DB is broken.
Error in 'werkzeug' python library.
Cause
Missing leading slash in url or empty url.
Solution
Add a counstraint to check if url is valid (not empty and
with a leading slash).
opw-2266935
closesodoo/odoo#52189
X-original-commit: fe1e76638132197ef4804d1261fb5b9e23d44159
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
visibility_group was used for visibility, we now use the groups_id field.
groups_id is a M2M field while visibility_group was a M2O field resulting
in an issue to display the M2M field in the frontend. We decided to
allow editing the groups as a M2O in the frontend. If there is more
than one group the user will have to go through the backend to edit.
task-2264580
closesodoo/odoo#51846
Related: odoo/upgrade#1260
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This reverts commit fdd4a143f2148ec5f4aeea80fecd3138fea95dc6.
See discussion in #51969closesodoo/odoo#52028
X-original-commit: 0e602cc0ac295621864b50509f78bd5de1e61718
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
When a theme module is updated the changes made on a view are considered
as user changes, prenventing the view from being updated in the future.
Fixed by comparing the arch being written with the arch of the original
view. If it is the same the record should not be noupdate.
Plus added a test to make sure the theme views receive theme updates
after being updated once.
Introduced by: https://github.com/odoo/odoo/commit/4acf177b4c55f3a16362cbeafea3d332ef4fe819closesodoo/odoo#51557
X-original-commit: 221470ab9c9eda3f3a4e2da0fa1a7bb23d6288cc
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This restricts the attributes of a BaseModel instance to `env`, `_ids`
and `_prefetch_ids`. This way, one can only assign fields on a record;
other assignments are programming errors.
This also reduces the memory footprint of records from 168 to 64 bytes
(-62%), and makes their instanciation faster.
closesodoo/odoo#51075
Related: odoo/enterprise#10529
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Issue
- Install website
- Go to Website->Configuration->Pages
- Group By "View"
- Open and edit "Home" view of "My Website 2"
- Remove "Website" value and save
- It should list 2 same views for same url and no website
under one of the "Home" views
- Go to Configurations->Settings
- Create a new website
Traceback is thrown.
Cause
When fetching default homepage,
it retrieve more then one pages and then try
to assign it as homepage to new website.
Solution
Limit query to one to get only one homepage.
opw-2252208
closesodoo/odoo#51280
X-original-commit: 0698f3b0ccddf77a6c0c02812bb823da2d21b265
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
The method fields_view_get should be the only way to retrieve the view
content. This method is executed in a super-user context.
To avoid retrieving views for a model a user does not have access to
(as it may reveal some informations like name of fields), add a
verification of 'read' rights before retrieving the view content.
Execute _postprocess_access_rights with sudo(False) as this method is
used to evaluate which buttons should be displayed.
Remove the su flag to avoid misleading the user and displaying a
button they won't be able to use.
Retrieving the database id from an view key is not considered as a
sensitive information and get_view_id and viewref can be left as a
public methods.
Add missing sudo when needed
Change _handle_visibility in website to avoid increasing the query
count: Checking the visibility (to fail most of the time) to retry in
sudo was making unecessary queries.
Before this commit, url preview of a theme was theme_xx/static/yyy.png
Now we make this url absolue /theme_xx/static/yyy.png
It was the expected behavior, and since werkeug 15.0 utils.redirect() don't use
'/' anymore as root but the current path.
Without this fix, theme selector uses /web/image/<id>, and the location become
/web/image/theme_xx/static/yyy.png instead of /theme_xx/static/yyy.png
closesodoo/odoo#51018
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
With this fix, record.with_context(lang='fr').compute_url will have the url
with the slug in french.
Before, it was ignoring the lang since the field was not translatable.
The first compute was stored in cache, and next call just ignore the lang in
the context.
```py
for lang in ['en_US', 'fr_FR']:
print(record.with_context(lang=lang).website_url)
> "/my-name-1"
> "/my-name-1"
```
now
```py
for lang in ['en_US', 'fr_FR']:
print(record.with_context(lang=lang).website_url)
> "/my-name-1"
> "/mon-nom-1"
```
closesodoo/odoo#50951
X-original-commit: 43822adef4ee4c44d10786f28af46df4be260cf5
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
As of 02e01dce51 the website menu is prefetched for the user and saved
in cache.
If the sequence of a menu is changed (eg. with the "Edit Menu" modal on
website), the cache was not cleared so it seemed like this did not work.
With this changeset, changing a menu sequence will clear ormcache.
opw-2244908
closes#50683closesodoo/odoo#50703
X-original-commit: 8da3276e8b641e615e4c436b4f0f79139d158220
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Currently, the menu are only translated for installed language when we
create a new website.
When we create a new menu (eg. by installing a module) or install a new
language we will only translate menu without website_id set, so the menu
are not translated.
With this changeset, we try to match translation of menu without
website_id to menu with website_id when translations are updated:
- when a language is installed/updated
- when a module is installed/updated
Without the changeset, the added test would fail with:
- "Menu in english" != "Menu en français"
Load translation add missing translation from template menu
- "Menu in french" != "Menu en français"
Load translation with overwriting update existing menu from template
fixes#43365
opw-2209864
closes#48031closesodoo/odoo#50498
X-original-commit: 998987f8ee148235f4025eb97a424e838ac6fc9f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Some apps, once installed, automatically create a menuitem in website.
What complexify the UI and create useless menu withtout plusvalue.
It is not because you install livechat to make support online, that you want
a link in your menu to show stats e.g.
Now we remove the default menu created, and help user to find it when he create
a link. The autocomplete suggest most of the main App's controllers
task-2189613
closesodoo/odoo#49081
Related: odoo/enterprise#9733
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Add in one shot all the states (active or not) for all keys of customize_view
task-2211013
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
Most of the website rendering process depends of customize_show views which are
part of a configuration setup.
Once it has been setup, it will most likely never change afterward.
It makes sense to orm cache those infos to avoid having to query ir.ui.view
table everytime we render something.
Note that just store basic and small infos used for customize_show case.
task-2211013
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
The (private) Rule.build method takes a values *dict* parameter. From
the start it was called with an invalid argument, but before 0.15
`append_unknown` would lead to just not using the argument at all
unless the rule is dynamic (aka has converters)[0].
In 0.15 the code was refactored and the `values` mapping is now used
in every case[1], leading to a pretty systematic error when calling
`search_pages`, which occurs any time an auto-completed URL field gets
used on the website e.g. when converting text to a link using the page
editor or when trying to update menu items.
Fixing this in 13.0 because while the current debian stable ("buster")
still bundles 0.14, the soon-to-be-released Ubuntu LTS (20.04) updates
werkzeug to 0.16. Debian Testing (bullseye) also bundles 0.16 but
isn't expected to get released for another year so it's less of a
concern.
Fixes#47356
Relates to odoo/docker#299
[0]
https://github.com/pallets/werkzeug/blob/c769200d1dcf1e21daaa2781f0c5109586daad42/werkzeug/routing.py#L797-L828
[1] https://github.com/pallets/werkzeug/blob/048cdfd9b969c0c3a133d7ff43b8ad1ad6a673ec/src/werkzeug/routing.py#L1020-L1032closesodoo/odoo#50194
X-original-commit: 4f1589075d2aae65c67a01c5c0f75c19c50a61d6
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, There would be an error due to the required field `name` which was not passed in vals when the user creates new Redirects through Manage Pages from Website, while the `name` field is required at the model level.
In this commit, we pass 'name' field in the values of `website.rewrite`
Followup on be8fc2296bclosesodoo/odoo#49748
X-original-commit: a8125ebc1480b5b215bf3737f4e799ead5b34d9d
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
During theme install, theme.ir.ui.view are copied as ir.ui.view for the
requested website.
During theme update, those already created ir.ui.view will receive the
theme.ir.ui.view modifications, including the `arch`, even if it was changed by
the user, meaning the user changes would be lost.
Here are some examples which will be wiped away when the theme
is updated (only if the view is loaded from the theme module):
- Changes made from website HTML/CSS/JS editor.
- Changes made from website builder e.g. Theme modify footer with XPath
and user make changes in footer then user changes will be gone on theme update
- Changes made directly in the arch of ir.ui.view in the backend.
This commit fixes that behavior by not updating views which were modified by
the user.
closesodoo/odoo#49224
X-original-commit: 9906e1d403c4e9137a0313c342a455f425e95b8e
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Kishan Gajjar <kishanegajjar@gmail.com>
TL;DR: remember `osv` and `except_orm` ? You can forget about them.
* Deprecated `except_orm` dropped.
* `UserError` elevated as super type of all user-related
errors.
* Unused `DeferredException` dropped.
* Unused `QWebException` dropped (real one is in `qweb.py`).
* `MailDeliveryException` made a python exception.
* `name` legacy exception attribute made an alias of the python standard
`args[0]` attribute and deprecated.
* `value` legacy exception attribute dropped.
* `exception_type` RPC error response key dropped.
* Deprecated `osv` module dropped.
* `--osv-memory-age-limit` cli option made an alias of
`--transient-age-limit` and deprecated.
The `odoo.exceptions.Warning` have long been a deprecated alias to
`UserError`. It is going to be removed in a future version but first we
explicitly deprecate it with a warning.
The `odoo.exceptions.DeferredException` was a very old internal
exception, it has been removed without deprecation notice as it is never
raised.
The `odoo.exceptions.except_orm` has been a deprecated exception type
with deprecation warning for 5 years, it has been removed in favor of
UserError which becomes the super class of all user-related errors.
The `odoo.base.models.ir_mail_server.MailDeliveryException` was
inheriting `except_orm`. As it is not related to a user error but is
more of a problem an admin much take care of, the exception has been
made a Python error.
The `exception_type` JSON key in RPC error responses was holding an
hardcoded value derived from the exception type. Its usage has been
dropped in favor of the `name` JSON key that holds the precise exception
name. Again as it was hardly used in the source code (beside the crash
manager) it has been dropped without deprecation warning.
Since we are here trying to clean odoo custom exceptions, we are also
deprecating the `name` exception attribute in favor of the more standard
`args[0]` attribute.
The `name` (along with `value`) were two attributes used to raise
`except_orm` exceptions before the introduction of `UserError`,
`AccessError` and related exceptions. The `name` attribute, at the time,
was holding the exception type/title. Nowadays it contains the error
message. The `value` attribute, at the time, was holding the error
message. Nowadays it is no more used.
The `osv` module contains very old deprecated aliases. There is no
simple way to log a deprecation warning for osv, osv_memory and
osv_abstract but as they have not been in use for ages, they have been
removed too. To be consistent, the `--osv-memory-age-limit` cli option
has been made a deprecated alias to the `--transient-age-limit`.
closesodoo/odoo#45723
Task: 2187728
Related: odoo/enterprise#9162
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Steps to reproduce the bug:
- Module website is installed
- Multi companies is set
- Go to Website > Settings
- Remove the company for the current website and save
Bug:
A traceback was raised
opw:2228183
closesodoo/odoo#48839
X-original-commit: 2c27b9d100c1f3759bfe864f8ac78bc5c0436ecd
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Also remove all t-fields from footers to have only static contents in
footers. For social links, a controller is added so that a "static url"
/website/social/xxx always redirect to the correct set URL for the given
xxx social network.
Part of https://github.com/odoo/odoo/pull/38950
task-2087641
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit introduce multiple improvements regarding social image:
- (perf) Don't read ir.attachment through `social_default_image` when it is
not needed. Use a stored boolean to know if the field should be accessed.
This will remove one SQL query in attachment for public user.
- Show website logo, not the company logo since we now have a different logo
for website.
- Don't show images lower than 200 width or 200 height px. Logo will be
shown regardless of his size.
- Don't show website logo if there is a website social_default_image.
Indeed, the spec was to prevent showing logo and social_default_image if
they are the same image. Technically, this is hard to identify as they
could be the same image uploaded with different resolutions (media dialog),
especially if one of those was uploaded through the backend and one from
the frontend.
It is most likely we will never correctly identify duplicate as they won't
be exactly the same.
For this reason, it makes more sense to hide the website logo if the
social_default_image is set. It avoids every issues while it makes sense
since you won't want to use the logo over the social_default_image. If you
really want to, you could reupload it through the SEO media dialog.
closesodoo/odoo#47848
Related: odoo/upgrade#1012
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
The dispatching layer of Odoo (common to any call) can avoid a query on website
if those 3 values are cached.
Note that for complex business flows, there won't be any gain since website
infos will have to be fetched at some point.
About user_id:
In most cases, for a website page you will need to browse the website btw so
we don't remove this request previously. But in case of a simple image, the
controller /web/content need the public user just to set the request.uid in
auth_public but no other info from website.
With this commit, we don't do the 'select * from website where id in()'
request on each controller declared in auth='public' but use the user_id
from the cache. (Invalidated by the write on website_id)
task-2211013
Co-authored-by: Jérémy Kersten <jke@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
qsm-odoo