An ir.attachment record can be served as a request's reponse if:
- a request triggers a 404
- the ir.attachment record has its url field matching the url of
the failed and is of binary type
Following rev[1], portal users have the right to create these kind of
records, and it is a security concern.
This patch restrict the ability to create and write on the ir.attachment
records that may be served through the dispatch's exception mechanism to
settings users.
As the asset bundles files are served through the use of these special
ir.attachment, we make sure to retrieve only ir.attachment records
created by the superuser in the `get_attachment` method.
As website administrators often need to play with these special
ir.attachment, we also let to this group the permission to manage them.
[1] 61065b6d04
Refactoring of qweb to call _post_processing_att for each nodes. This
change remove the crappy ovewrite in website module. The website overwrite
only the _post_processing_att to add the cdn parameters.
The static node (without t- attributes) can stay static (remove overwrite
of _is_static_node), the cdn is applied at the compile time for this
nodes instead of at the running time like the dynamic node.
res_config_settings.website_id should be ondelete='cascade', however
that is not suitable for stable, so we emulate the ondelete cascade
with an SQL query during ir.model unlink (website uninstallation).
Fixes#25078
This commit:
1. removed the possibility to create page from the menu manager.
The usability of this feature wasn't great since create menu as a new page
would redirect to that newly created page without saving the menu manager
state.
Plus, there is already the 'NEW' button on the navbar to create a new page,
the menu manager should, as its name hint, only manage menus.
2. Handle a new case (officially at least) of menu: menu container.
Those menu are simply menus with '#' as URL. It will be usefull to create a
menu as a dropdown list container.
Note: We should take care of a menu's URL being updated to '#' to avoid the
menu's page URL to be also edited to '#'.
opw-1825883 & opw-1824263
Before this commit:
1. If a menu was used as a container (dropdown) and had an unpublished page_id
(website.page), we would never show that menu (and so its submenus) even if
it has visible submenu.
Some users are stuck with this since they:
a) create a new page 'A' (unpublished by default) included in menu.
b) create a new page 'B' (unpublished by default) included in menu.
c) set 'B' as a submenu of 'A' in the menu manager
d) decide to publish the website.page linked to menu 'B'
Then, since menu 'A' is linked to an unpublished page, the menu 'A' and 'B'
are never visible.
2. If a menu is being created with an URL that match a website.page URL, the
m2o relation will automatically be set (website.menu.page_id).
Still, if the user type the URL without the leading slash, the m2o won't be
set.
This could be misleading since on the page property in the page manager the
URL is being shown without the leading slash even if it is stored in DB.
Now:
1. We always show menu container if they contains visible submenu, even if the
container menu is linked to an unpublished page
2. The page URL search is more clever and will match URL even if the only
difference is the leading slash.
This closes#24635
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
web (tagged with `openerp-web`) translations are loaded in the backend, in
`odoo.addons.web.controllers.main.WebClient.translation(mods=None, lang=None)`
method (through `/web/webclient/translations` controller).
In website, the controller `/website/translations` is called used, fetching
the translations from modules with the (fragile) clause `name ilike 'website'`
This commit fixes two bugs:
1. Install `website_sale`, activate discussion on products
-> the chatter is not translated as the portal translations not loaded in the
`/website/translations` controller
2. Install `helpdesk` but not `website`, go to portal view of a ticket
-> the heldesk chatter is not translated as the `/website/translations`
controller is not called (only provided by the website module)
This patch implements a modular approach to translate the web resources of the
right modules only.
The controller /website/translation is moved to http_routing and each module
override the new _get_translation_frontend_modules_domain method to adds its
translatable module
Closes#23618Fixes#23610
Before this commit if /foo redirect to /bar?a=1
/foo?debug=1 was redirectd to /bar?a=1
After this commit,
/foo?debug=1 is redirected to /bar?a=1&debug=1
Website Versioning module (website_version) is applied when displaying
views by interfering when doing the "render the view of this `key`" and
showing the view with the same `key` but of the currently displayed
version.
The website.page model when directly rendering a page would directly
specify its `id`, thus website version was bypassed and just the master
page was displayed.
With this commit website.page has a "get_view_identifier" that can be
overrided in website_version and has the same previous behavior
otherwise.
This changeset also solves a conflict (`website().get_current_website`
also modify `request.context`) when modifying the context which also
disabled versions.
opw-1824957
closes#23847
Currently some base context used for evaluation is computed when rendering
QWeb templates. Evaluation context is build in base and improved notably
in website module.
This commit adds an option to skip this context build and have a minimal
evaluation context based on given values. Purpose is to avoid having to
search and browse unnecessary content when evaluating some custom templates.
When we know precisely what we need when rendering a template there is no
need to add unnecessary items in the evaluation context.
This commit is related to task ID 1817951. Closes#23291 .
Purpose of this commit is to standardize portal user behavior and creation.
As all portal required features (user, group, support) have moved to
base let us move the template user used to create portal users to base.
'Portal User Template' is therefore moved from auth_signup to base module.
Various config parameters are updated due to the change in xml id.
This commit is related to task ID 31399 .
Christophe Simonis