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>
*: website, web
Move the colorpicker dialog logic into a colorpicker *widget*, which the
colorpicker dialog will now instantiate.
Part of https://github.com/odoo/odoo/pull/46088
task-2195313
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.
Only system users should be able to access directly ir.ui.view records
Other users should use helper methods like fields_view_get or render
to interact with view records (or use sudo)
Give read access to views to publisher
He needs to call read_template on some views like
'web_editor.colorpicker' in edition mode
Restrict ACL on website.page
Apply the same ACL than on ir.ui.view as the model inherits from it.
Give access to designer to modify views
Bootstrap uses `font-weight: bolder` for its `<b>` elements. This is
good... but only works if the "bolder" font is actually referencing
an available one.
Indeed, since we only load 400 and 700 font weights for fonts, see the
following table. CSS values on the left, actual fonts being used on the
right.
```
<p> | <b> | <p> | <b>
----------------------
100 400 | 400 400
200 400 | 400 400
300 400 | 400 400
400 700 | 400 700 -> ok
500 700 | 400 700 -> ok
600 900 | 700 700
700 900 | 700 700
800 900 | 700 700
900 900 | 700 700
```
See how bolder and fallbacks works: [1] and [2].
With most fonts, the rendering of `<b>` was thus only working for elements
using 400 or 500 font-weight. For font-weight > 500, we'll consider
this as a limitation for now: bold area cannot be made bolder.
Font-weights < 400 are however more important as used by some of Odoo
and bootstrap style (e.g. the entire blog posts).
The problem is even deeper as website visitors could have more or
different available font-weights on their computer.
This fix adds the loading of 300 weights for all fonts so that:
- The displayed weights are more consistent across different computers.
- Making a light text bolder through the editor works.
[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/font-weight#Meaning_of_relative_weights
[2]: https://developer.mozilla.org/en-US/docs/Web/CSS/font-weight#Fallback_weights
opw-2226573
closesodoo/odoo#51061
X-original-commit: e7496b923b097f677bef09b890c52b5a680cf53c
Related: odoo/design-themes#277
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
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>
*: web_editor
Previously the theme body, text, header, headings and footer colors were
not added to the customs colors of other colorpickers if they were
custom. Now it is the case.
Those colors can be set to a theme color but it will be the css color
of the theme color that will be set, not its name.
This can lead to the custom color being a theme color which was not
checked before as it was not possible. Now it is checked.
Also before the theme tab, if the selected color was custom, it would
always appear in the palette and be marked selected. This is no longer
the case with the like of status colors as their color are
not part of the custom colors available on the color palette. Now we add
the selected color as a custom color to always have the selected marked.
task-2198177
closesodoo/odoo#50766
X-original-commit: d631b27b0bf04e708c16262378ab5729252838fe
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In 29f02a37f0 we bumped the verion of libsass that we use. One
breaking change introduced by the new version is that if a css variable
is interpolated to the empty string, it is still emited in the compiled
css [1]
This commit fixes that by explicitly omitting null values from the map
before looping over it.
[1]: https://sass-lang.com/documentation/breaking-changes/css-vars
task-2248360
closesodoo/odoo#50668
X-original-commit: 6faf327706169bbe31e188a42805085b95b78052
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit adapts several views to make them use newly defined
widgets, the new decoration-xxx mechanism on fields, and to adapt
them to the new design of buttons.
Part of task 2195254
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>
Before this commit, the Title for the `"Page Published"` was `visible` and `Not visible`.
With this commitment, we make it align with the main title.
closesodoo/odoo#50344
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
* = mass_mailing, web_editor, website_crm, website_event, website_form,
website_forum, website_hr_recruitment, website_mail_channel,
website_mass_mailing, website_sale, website_slides
When an outdated snippet's option are activated we display a warning
in the left panel that inform the user about the potential
malfunctions.
To do so the snippet's template key is added to the snippet as
data-snippet.
If a snippet is "t-call" inside another snippet, it will need to use
t-snippet-call instead of t-call to have the key on himself.
Those unique keys are used on snippet selection to retrieve the
snippet's version in the left panel and compare it with the currently
selected snippet's version. Versions are describe with data-vcss,
data-vjs and data-vxml. If a snippet's key is not in the left panel we
consider that snippet as outdated.
Added some tests to ensure that t-snippet and t-snippet-call really have
their template key as data-snippet
Adapted the views to the data-snippet changes adding
data-snippet="tmpl_key".
Part of: https://github.com/odoo/odoo/pull/44569
task-2189669
closesodoo/odoo#50254
X-original-commit: 28a6cd49b6e87b75c2e70771e241c41778bf9e87
Related: odoo/enterprise#10236
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.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>
Small bug introduced by [1]: now the website menu is loaded on demand
to avoid useless page loading. This was done when hovering the toggle
which induced two problems: not loaded if the user was already over the
button when the JS is fully loaded and not loaded if the dropdown was
opened via the keyboard.
Also, the 'mouseover' event was used instead of the 'mouseenter' and the
RPC was not checked for already pending ones. Both issues could lead to
have the RPC performed multiple times for no reason.
[1]: https://github.com/odoo/odoo/commit/4206c1f225f5b1c54a0cdd4913e1d8224a2e7889closesodoo/odoo#49986
X-original-commit: 7aebd7d88d1d0a0f81351b8a0e12a03964c8431a
Signed-off-by: Quentin Smetz (qsm) <qsm@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>
Steps to reproduce:
- install website
- install the theme "clean"
- go to website > customize > customize theme
- select the first "extra color" (alpha) and change it
Previous behavior:
All extra color that have not been set previously have changed
automatically without notice
Current behavior:
the theme is either showing primary/secondary colors or only "extra" colors
Good themes are supposed to enforce primary = alpha and secondary = beta
All extra color that have not been set previously change automatically but
an information tooltip shows up when you hover alpha to avoid confusion
opw-2180611
Forward-Port-Of: #46099closes#49730closesodoo/odoo#49789
X-original-commit: c9aada53b1e6b24da4e1fe9ac4d44db3ff8cacda
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
While the edit mode interface is full of useful things, it also adds a
lot of clutter, and alters the page's width and thus, its layout. This
commit adds keyboard shortcut for website editors to use, and allows
them to enter a "fullscreen" mode that hides the editor interface while
remaining in edit mode, allowing the user to have fewer distractions
while editing text content, and a closer rendition of the page's final
layout while editing.
For this, keyboard shortcuts were required, and a few other useful
shortcuts have been added, such as alt-1,2,3 for the navbar, just like
in the backed.
task-2126915
closesodoo/odoo#46953
Related: odoo/enterprise#9295
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Remove the z-index = 1 for the header because it introduces visuals
bugs where certain elements are displayed at the top of the header when
should be displayed under. Example: search button in events page.
task-2229057
closesodoo/odoo#49612
X-original-commit: e5a5b7f454befd9059f88dbd4f31a76e43e0eb77
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit places a tip to indicate the user to scroll when the anchor
is out of viewport.
Also now allow to wait that the user types on his keyboard before
consuming a step when text modification is required on a contenteditable
element.
Part of https://github.com/odoo/odoo/pull/48678
task-2228694
closesodoo/odoo#48678
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
If for some reason someone wanted to develop a textarea using the
editor which is supposed to work as a public user (like we are trying
to do on Odoo.com), it was not possible. The code was "designed" to
allow it but there was one problem: the lazy loading of the editor
assets required a `render_template` call to the server... which cannot
be done from a public user.
This commit solves the issues by allowing the lazy loading of assets
to use a custom route if required. That route is then used by the editor
"root". That route performs the render_template as a superuser provided
that the view's xmlid is whitelisted.
Note: there was another unauthorized call for public user: the
colorpicker. This was solved by disabling the colorpicker template rpc
for public user, they will still get the default summernote one.
Part of https://github.com/odoo/odoo/pull/48981closesodoo/odoo#48981closesodoo/odoo#49398
X-original-commit: e84a0bfdc99c21406861b88c02b11c925d92f927
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Forgot to add the vcss number on some s_title snippets.
task-2233240
closesodoo/odoo#49263
X-original-commit: 7fb36621665c739c7c91395b2bdaee12f908c88c
Related: odoo/enterprise#9773
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When creating a record and clicking on the go to website button before
saving it previously saved the record and browsed it on the website.
Currently it does not save it and the redirection is broken too.
This is fixed by using the same trigger as the other stat buttons.
Introduced by: https://github.com/odoo/odoo/pull/34261closesodoo/odoo#49262
X-original-commit: 700f57ef13e45527c2d249fc431e1d54e0bc1955
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.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>
Toggle method defined on ir.ui.view does the same job of toggle_active that
is the generic one available on all models.
Task ID 2170708
Community PR odoo/odoo#46563
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>
Before this commit, a lot of leftover import shims existed in the
codebase for py2-py3 compatibility, these are no longer needed since
Odoo 13.0+ doesn't support Python 2 anymore and is (finally) in EOL.
With this commit, these shims are dropped, making the code cleaner,
easier to read and with one less dependency.
Queue -> queue -> py2-py3 compatibility
xmlrpclib -> xmlrpc.client -> py2-py3 compatibility
ConfigParser -> configparser -> py2-py3 compatibility
itertools.izip_longest -> itertools.zip_longest -> py2-py3 compatibility
urllib -> urllib.request -> py2-py3 compatibility
__builtins__ -> builtins -> py2-py3 compatibility
_winreg -> winreg -> py2-py3 compatibility
mock -> unittest.mock -> merged into CPython
The debian/fedora packages and requirements.txt have been updated accordingly
closesodoo/odoo#44601
Related: odoo/enterprise#8141
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Swapnesh Shah