It allows to always have a OdooResponse Object and don't allow redirect
to external except when you allow it explicitly with local=False.
Always return to a local url:
/website/add
/slides/slide/<model("slide.slide"):slide>
/microsoft_outlook/confirm
Allow previously external redirect without reason, now blocked
/website/lang/<lang> -> open redirect
Allow external redirect for good reason and url is controlled by code.
/social_facebook/redirect_to_profile/
PS: HTTP Code 303 is a better default for generic redirects. It's not
historically the default for werkzeug.utils, but it is what we want in
general. Contrary to 302, there is no browser-dependent behavior, and
no risk of asking the user whether they want to accept the redirect if
the original method wasn't GET. It's always a non-permanent GET on the
target location.
closesodoo/odoo#95019
X-original-commit: 77f8d9c5d96a9274785ffc2ad83b95ea157d26ad
Related: odoo/enterprise#29000
Signed-off-by: Olivier Dony <odo@odoo.com>
Signed-off-by: Jérémy Kersten <jke@odoo.com>
The website architecture has been refactored for the internal users and
admins with [1].
Now, they can access the website in the backend inside the website app.
Long story short, the website will be displayed in an iframe in a client
action. The URL of the browser will be tweaked to reflect the iframe one
instead of the real one (which is something like /web#action=..).
It had a few drawbacks:
- On page refresh (F5 or browser button), the user would land on the
frontend version of the website instead of remaining in the backend.
- When the user edited the URL (Like removing `/shop` and typing `/jobs`
instead, he would land on the frontend version too.
- Impossible to directly go to the backend version of the website.
Those are improved with this commit by using a slightly different URL
when we are in the backend. A `/@/` will prefix the iframe URL.
If logged in, the user will land on the backend. If not, it will simply
redirect to the frontend version of the website.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#94580
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web, web_editor, web_unsplash, website_blog, website_event,
website_forum, website_hr_recruitment, website_links,
website_livechat, website_sale, website_slides, website_twitter
This commit fixes two issues related to the loading the wysiwyg and
editor assets.
The media dialog components are now defined in a new assets_media_dialog
bundle, to make them available both in the frontend (needed to post
comments on the forum for example), and in the backend (used in the
context of the wysiwyg edition or in the seo dialog). Ideally, The media
dialog component would lazy load its own bundle, but right now, it is
not possible when used in a ComponentWrapper.
The wysiwyg assets are now completely loaded in the frontend, after
creating the website root, when the frontend is displayed in an iframe.
It would be better if the frontend loads only what it needs of the
wysiwyg assets (some editor classes and the drop zones css), an
improvement would be to create an assets_wysiwyg_frontend or
assets_wysiwyg_minimal bundle.
The website edition components are moved to the assets_editor bundle.
For now, this bundle is included in the backend and the edition menus
are hidden from the users that are not website publishers. Ideally, the
client action would lazy load the assets_editor, only if the user is a
website publisher.
Many optimizations regarding assets will be done post-merge.
See merge commit for more information.
task-2687506
*: website_blog, website_hr_recruitment, website_sale, website_slides
This commit changes the redirections from the controllers, that were
always redirecting to the frontend before.
Now, we want to open the website in its backend client action most of
the time (for example, when clicking on the "go to website" buttons on
the form views).
For that, a new get_client_action_url is introduced on the website
model.
See merge commit for more information.
task-2687506
The goal of this commit is to add options to manage website pages as in
frontend page manager using list view.
- The click on list view item will redirect iframe to the targeted page.
- The Page Properties dialogs (DuplicatePageDialog, DeletePageDialog)
are used to clone/remove pages.
- The pages listView is loaded using the current website domain.
See merge commit for more information.
task-2687506
Before this commit, the configurator was its own frontend application.
With the website edition UI moved to the backend, it makes also sense to
move the configurator to the backend, as a client action, so that it is
easy to trigger it after installing a website (or the website module),
and returning to the website_preview client action after having
completed it.
This commit adds a new color_palettes.scss file, added in the
assets_backend, that will print the values of the color palettes (so
that some js can handle it). For now, it is needed for the configurator
and the editor. It will probably need to be reviewed later to not put
everything in backend assets.
See merge commit for more information.
task-2687506
On website, the edition is done in an iframe while the SnippetsMenu
resides outside of said iframe. This means that the SnippetsMenu no
longer has frontend styles. Therefore, colors aren't accurate.
This commit aims at patching web_editor widgets, such as color_palette,
so that the color displayed is always accurate. To do so, it computes
the color inside the iframe and adds style attributes to color_palette
preview elements.
See merge commit for more information.
task-2687506
*: mass_mailing, web, web_editor, website_blog, website_event,
website_event_meet, website_livechat, website_sale, website_twitter,
base
This commit does 3 things:
- Adapt existing code so that the editor can be run outside of its
editing element. Prior to this commit, it was expected that the
editor would be attached to the element it was currently editing.
This needs to change however as the editable is now inside an
iframe for the website edition. mass_mailing already had a similar
approach but the editor was started within the iframe.
With these changes, the editor is alongside the iframe, editing
the content that's inside it. This allows multiple features
such as reloading the iframe while keeping the editor visible and
resizing the iframe for a mobile preview.
- Adds logic to the wysiwyg_adapter so that it can undertake
the duty of the previous widget sytem. The wysiwyg existed not only
in the legacy widget system, but most importantly in the frontend.
One of the duties of this adapter is to send events inside the
iframe when it is necessary to reach the frontend public widget
(i.e. widgets_start_request)
- Removes existing SCSS that is no longer used.
See merge commit for more information.
task-2687506
*: website, website_sale_comparison, website_sale_loyalty,
website_sale_slides, website_sale_wishlist
This commit adapts "customize show" options from website sale modules by
creating new options available in edit mode.
See merge commit for more information.
task-2710582
*: website_blog, website_event, website_forum, website_hr_recruitment,
website_livechat, website_sale, website_slides
The NewContentModal component is added. It displays tiles, which will
install a module if not already installed, or perform an action defined
by the module otherwise. So that modules can patch that component to
define an action when installed (for example, website_sale will handle
the logic of creating a new product), the elements to displayed and
their state (NOT_INSTALLED, INSTALLING, INSTALLED) are listed in the
state of the component.
A key 'isDisplayed' is added on the new content elements that should not
be displayed to the user, depended on his security groups.
By default, the new content elements are displayed to the system user.
See merge commit for more information.
task-2687506
No method was readily available to know if a user is `internal` (has
group `base.group_user`), which was inconsistent with other base groups.
_is_internal is now used in the codebase where it is clear that
`.has_group('base.group_user')` is called on a single record.
Part-of: odoo/odoo#85703
Rationnals
----------
Web servers can serve some resources (e.g. static files) right away
without any interaction with the web application. The network model of
most web servers makes them capable of handling thousands of
simultaneous requests when it comes to intensive IO operations such as
streaming data from a file. The network model of Odoo is different: it
is capable of a lot of processing power but can only serve a handful of
requests at a time, i.e. Odoo (with some help from postgres) is
optimized for CPU operations, not IO.
Some users don't configure their web server, they use a basic
configuration that relay all requests to Odoo. The result is that many
Odoo HTTP Workers can be busy streaming static files instead of
processing other requests. This can lead to a worker starvation, i.e.
all workers are busy streaming files and cannot process new requests.
X-Sendfile
----------
In this work, we add the support for the [X-Sendfile] header family,
they are multiples http headers that can be used by the web application
to communicate with the web server in order to delegate the delivery of
files stored on the file system. Odoo still receives the request but it
does no more stream the file content from within its HTTP worker,
instead it skips the response body altogether and sets the `X-Sendfile`
special header with the path of the file on the filesystem. The web
server intercepts that special header, open the file and stream it.
Using those headers, we can use the best of both the web application and
the web server. The web application is still responsible to locate the
resource and verify the access rights, the web server is still
responsible of streaming the content.
Using X-Sendfile is opt-in via the `--x-sendfile` CLI flag. We set both
`X-Sendfile` (apache) and `X-Accel-Redirect` (nginx). If you are using
apache, make sure `mod_xsendfile` is enabled. If you are using NGINX
you have to add the following location block:
location /web/filestore { # custom path, hardcoded within Odoo
# Prevent access from the outside world, i.e. makes this
# route only accessible via X-Accel. MANDATORY!!!
internal;
# Give access to the filestore using this server's
# permissions. Odoo is in charge of verifying the access
# rights.
alias /path/to/odoo/data-dir/filestore;
}
The Odoo [deployment documentation] has been updated accordingly.
[X-Sendfile]: https://www.nginx.com/resources/wiki/start/topics/examples/xsendfile/
[deployment documentation]: https://www.odoo.com/documentation/master/administration/install/deploy.html#serving-static-files-and-attachments
Changes to the API
------------------
To benefit most from X-Sendfile, all APIs related to streaming content
over HTTP has to be adapted. They are: (1) `request._serve_static`,
(2) `ir.http._serve_fallback`, (3) `/web/content` and (4) `/web/image`.
Each used it own way to deliver content: (1) `_serve_static` was using
`send_file` (flask's send_file that as been vendored with odoo 10
years ago and not maintenained since then), (2) _serve_fallback was
handcrafting a `werkzeug.wrappers.Response`, (3) /web/content-image were
using the "binary server" `ir.http.binary_content` API.
I has been decided to remove all 3 APIs and to merge the code inside of
the new `http.Stream` object and the `ir.binary` helper model.
A Stream wraps what is going to be sent to the browser, it can be a path
to a file on the locale filesystem, a blob of raw data or an URL to an
external resource. The Stream also holds various metadata that are
mainly used for caching. The preferred way to create a Stream is via one
of its three factories so that all the metadata are set. The factories
are: `from_path`, `from_attachment` and `from_binary_field`. A stream
instance exposes a single method `get_response()` used to create the
corresponding HTTP response object out of the stream.
Inside of `ir.http` were a few methods that were not related to the http
routing and formed what was called the "binary server". All those
methods have been removed and the feature have been refactored inside of
the new `ir.binary` model. The removed methods are:
- `_xmlid_to_obj`
- `_get_record_and_check`
- `_binary_ir_attachment_redirect_content`
- `_binary_record_content`
- `_binary_set_headers`
- `binary_content`
- `_response_by_status`
- `_get_content_common`
- `_content_image`
- `_content_image_get_response`
- `_placeholder_image_get_response`
The new `ir.binary` abstract model exposes the following utilities:
**`_find_record`**
Find an attachment or a record with a binary-field out of an xmlid or
out of a pair record-model/record-id. Check the access rights and the
access token.
**`_get_stream_from`**
Create a Stream from an attachment or a record with a binary-field.
**`_get_image_stream_from`**
Same as `_get_stream_from` but adapted for images. It sets a sensible
ETag on the stream and has image resizing support.
**`_placeholder`**
Get the image placeholder blob.
Testing
-------
It is possible to test the web server configuration using the
`test_http` module. Install the module then run the unittest using the
`webserver` test-tag. By default it attempts to connect to a web-server
running on `http://localhost:80`, you can change this URL by setting the
`WEB_SERVER_URL` environment variable.
odoo-bin -i test_http --stop-after-init
WEB_SERVER_URL='http://localhost:80' odoo-bin --test-tags webserver --stop-after-init
closesodoo/odoo#88134
Task: 2801675
Related: odoo/documentation#2083
Related: odoo/enterprise#26191
Signed-off-by: Julien Castiaux <juc@odoo.com>
- Show the Odoo version only in debug mode to logged in user, as we do
for the technical module name.
The purpose of this page is to generate some backlinks and improve
(does it really?) the SEO of Odoo.com.
The Odoo version doesn't bring any value and is another way to easily
retrieve DBs based on their version with a simple Google search.
While there is many other ways to do so, let's avoid this one.
- Prior to the introduction of `website.page` and the new page serve
mechanism, there could be template collision when an user would create
a page with the same key/name than the template of this controller.
This is not the case anymore.
We can remove the refresh meta tag.
See [1] and [2].
- The check to see if the template exists is useless, we don't do that
kind of check when rendering a controller, we just assume the view was
not manually deleted by the user.
I guess it was historically useful when people would not want that
/website/info page to be show. But now, there is a clean way to "hide"
this page by simply disabling it in the "Customize" option of the
website in the navbar.
[1]: https://github.com/odoo/odoo/commit/4cfd86edaa27d09f1066dd017bf466b8b30611e5
[2]: https://github.com/odoo/odoo/commit/7f6c669530ed7f9935de6516fadb7283ac00a9e4closesodoo/odoo#91131
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When the homepage was set to a different page than /, the resulting page
was blank.
The problem is related to a change of the rerouting algorithm, before
the httpocalypse it was re-dispatching the request itself, now it is up
to the called to do so. Here it is what `serve_path` does.
closesodoo/odoo#91034
X-original-commit: b00fefec2a26eb36be8a13cb845ee4f12f87d4eb
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
Issue
-----
When website is installed, the rendering of template uses a side effect
of the ORM cache (cache shared between sudoed env vs non-sudoed env) and
the fields prefetching feature to work correctly.
The `self.visibility` in (`_handle_visibility`, website/ir_ui_view.py)
is done in sudo mode, then it will fetch all prefetchable fields and put
them in the cache (that will be read in non-sudo mode in the render of
the template). Another example of issue related to this:
https://github.com/odoo/odoo/pull/83341.
Because of this, the fields of mixin `website.seo.metadata` were forced
to be prefetchable (the default for translate is to be not prefetchable
since https://github.com/odoo/odoo/pull/82896), which causes a useless
LEFT JOIN on "ir_translation" in most of business flow.
Fix
---
Remove the `prefetch=True` on mixin fields, and add a extra read to fill
the cache in case of website rendering. It also allows to read these
fields at the same time.
Part-of: odoo/odoo#85220
We can easily avoid a read on the website table when serving the
homepage by simply caching the website.homepage_id value and then
browsing the record (no query needed) instead of reading it on the
website record.
While this code is not really elegant, it seems like a good tradeoff to
gain a query on this particular homepage serve controller, which is the
main entry point of a website and generally the page the more often
served.
task-2774979
X-original-commit: 69b443b85656c895c66a1f83b235f5d1e53727d4
Part-of: odoo/odoo#85456
- Three controllers were actually useless as the relevant public methods
of the web_editor.assets can be called directly via RPC in the related
usecases.
- Review the web_editor.assets model methods organization in the model
declaration.
closesodoo/odoo#85392
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit is the 14th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
* `request.uid = x` => `request.update_env(user=x)`.
* `request.context = x` => `request.update_env(context=x)`.
* `request.context = dict(request.context, x=y)`
=> `request.update_context(x=y)`.
* `request.cr = None` => `request.cr.close()`.
* `http.mono_db()` => `request.db`.
* `http.dispatch_rpc()` => `service.dispatch_rpc()`.
* `@service.model.check` => `service.model.retrying()`.
* `request.endpoint`
=> `env['ir.http']._match(request.httprequest.path)[0].endpoint`.
* `request.routing_iteration `=> `removed`.
* `request.jsonrequest` => `request.dispatcher.jsonrequest`.
Note that `request.params` is now set much later in the process. If you
are in a situation where you values from the query string or the
http body you can use `request.get_http_params()`.
Note that using the new `request.future_response`, it is possible to
add headers and cookies on the response object before the response
object is initialized. Please note that headers/cookies saved on
the future response will NOT be injected in case of error.
PR: odoo#78857
Task: 2571224
Issue
-----
When website is installed, the rendering of template uses a side effect
of the ORM cache (cache shared between sudoed env vs non-sudoed env) and
the fields prefetching feature to work correctly.
The `self.visibility` in (`_handle_visibility`, website/ir_ui_view.py)
is done in sudo mode, then it will fetch all prefetchable fields and put
them in the cache (that will be read in non-sudo mode in the render of
the template). Another example of issue related to this:
https://github.com/odoo/odoo/pull/83341.
Because of this, the fields of mixin `website.seo.metadata` were forced
to be prefetchable (the default for translate is to be not prefetchable
since https://github.com/odoo/odoo/pull/82896), which causes a useless
LEFT JOIN on "ir_translation" in most of business flow.
Fix
---
Remove the `prefetch=True` on mixin fields, and add a extra read to fill
the cache in case of website rendering. It also allows to read these
fields at the same time.
Part-of: odoo/odoo#83818
The configurator introduced at [1] uses a frontend controller to
display its content. However this results in inconsistent language
translation as the python code uses the users's language but the
localization services uses the frontend's language when on a frontend
page.
Steps to reproduce:
- Create a database with the only language being french
- Install website
- In the configurator, all the pages will be in french except
"Pages and Features"
With this commit, the language for the configurator will always be
the language of the website it's configuring. A test also make sure
that this is the current behavior.
[1]: https://github.com/odoo/odoo/commit/e8a5af2e28a4724f86783746706cb59175f086bf
task-2687416
closesodoo/odoo#84810
X-original-commit: a0f8fdc65566fafe98dab21f5c2dbab9505c3d5c
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
website{_*}: website, website_blog, website_event, website_forum,
website_sale, website_slides
Since the generic search bar was introduced in [1] all text fields were
truncated in search results.
This caused problems for long URLs which were truncated as well, and
therefore could become invalid.
After this commit URL fields specify `'truncate': False` in their search
detail metadata, which informs the rendering to skip the text truncation
step for that field.
Also added previously missing controller-level tests of the
autocompletion.
Steps to reproduce:
- start odoo with website_forum and demo data
- go to the Help forum
- search for "configure" in the Help forum
- click on the auto-complete suggestion
- => redirected to a 404 page because the URL was shortened
To test the fix on other models, use a long enough name that causes the
problem. E.g.: "This product has such a long name its URL would have
been truncated without the fix contained in this branch".
Note that the problem did not occur on blogs because the URL does not
contain the name, but the same fix was applied for consistency.
[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986
task-2727788
closesodoo/odoo#82621
X-original-commit: 045f741be35e62f5e3a636490c6c1d475b5d78eb
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, the "ripple effect" no longer worked because the
assets were never activated for the following reason:
- To activate the ripple effect assets via the editor options, we
activated a template that no longer exists (with
data-customize-website-views). Instead of activating the assets with the
new system of assets using records.
After this commit, a new "data-customize-website-assets" xml attribute
was created so that the assets can enable/disable in the same way as the
views. The "write" method for ir.asset has also been overridden in
website so that each website has its specific assets (via COW).
task-2686370
closesodoo/odoo#81833
X-original-commit: 9f56357cc1f4a7b8606ef4d5fd431fc396bdf1e8
Related: odoo/design-themes#546
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before Odoo saas-14.4, one should call `_get_http_domain()` on website to get
its domain. Indeed, that method was in charge of cleaning that domain, as it
was done with commit [1].
Since Odoo saas-14.4, that cleaning is automatically performed on domain before
saving it into database, thanks to commit [2].
Thus, we can now remove the `_get_http_domain()` and use directly the domain as
it is considered clean.
Note that migrated databases coming from version older than Odoo saas-14.4
could still have an incorrect domain (trailing slash, no scheme..).
This will be handled during migration with [3].
[1]: https://github.com/odoo/odoo/commit/3ad775aab717b395a5d11527aeb3596af66afa99
[2]: https://github.com/odoo/odoo/commit/042c95b0219bb0aa13e73385e092fa76ff1a1b0a
[3]: https://github.com/odoo/upgrade/pull/2951closesodoo/odoo#78766
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
PURPOSE
Before this commit when the method returned an empty string, the calling
method _fetchData couldn't processed map() on the result.
After this commit the result will be an empty array thus the map method
won't fail.
LINKS
Task-2489680
PR : odoo/odoo#
closesodoo/odoo#76497
X-original-commit: ef813860b7582e9f1a92debb40d6dcda5519e607
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit the `_search_get_detail` result contained callback
functions to handle special behavior during fetching and rendering.
After this commit a `website.searchable.mixin` is introduced that must
be inherited by models that participate in website-based searches.
Custom behavior previously achieved with callbacks is now achieved by
overloading methods of this mixin.
task-2379555
https://github.com/odoo/odoo/pull/65871
Part-of: odoo/odoo#65871
(*: website_blog, website_event, website_forum, website_sale,
website_slides)
Before this commit the search bar was specific to products.
After this commit a generic search bar is available as a general feature
of website which can be configured to inspect specific models.
The snippet is used to replace the old search bar in blog, courses,
event, forum, page and shop.
The search results of these pages and the autocomplete of the search bar
run through the same search mechanism.
A new hybrid results page has also been created as a target of a search
on "Everything".
In each involved module, `website._search_get_details()` is implemented
to return search metadata for every model related to the `search_type`
parameter.
Search metadata for a single model is returned by `_search_get_detail()`
on that specific model.
The autocomplete runs through the additional
`website._search_render_results()` pre-rendering step that prepares the
data to fit in the autocomplete template.
task-2379555
https://github.com/odoo/odoo/pull/65871
Part-of: odoo/odoo#65871
* = crm_livechat, hr, hr_holidays, im_livechat, mail_bot, purchase, sms,
snailmail, survey, test_discuss_full, test_mail, web_editor, website,
website_livechat
- Create new model `mail.guest` for guests.
- Rewrite some RPCs to target routes rather than model methods so that
guests are able to use them.
- Patch JS and python models to support guests.
- Create a stand-alone page and boot the channel in it.
task-2494829
closesodoo/odoo#75496
Related: odoo/enterprise#20417
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Now you can specify into the dynamic_filter_template the number of record to
use for desktop, mobile, and the number of record to fetch.
Some template have only sense to be shown with 1 record e.g. a full width.
Syntax:
Add on root element one or more of these attributes:
data-number-of-elements="2" -> number of record on Desktop
data-number-of-elements-sm="2" -> number of record on Mobile
data-number-of-elements-fetch="2" -> number of record to fetch
closesodoo/odoo#75662
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Regarding previous commit, the option parameter can be removed
from _get_asset_content api, followed by a nice snowball effect.
Part-of: odoo/odoo#75248
In order to limit encoding decoding, the _render method returns a
unicode string in the markup safe object instead of a MarkupSafeBytes
closesodoo/odoo#68299
Related: odoo/upgrade#2454
Related: odoo/enterprise#17270
Signed-off-by: Antony Lesuisse (al) <al@openerp.com>
Mark the fragments as markup-safe after fetching them.
Also make _render private (don't see any reason for it to be publicly
accessible), and avoid unnecessary intermediate enc/dec in it.
This branch adds request.redirect on all requests.
In case of a front end request, we do an url_for to the location.
We removed redirect_with_hash that was only for retro compatibility
local_redirect has been renamed to redirect_query, and param keep_hash has been
removed and moved.
Default code for redirect is 303 now instead of 302.
Now redirect and redirect_query make local redirect by default, you need to
pass local=False to make external redirect.
All werkeug.utils.redirect has been replaced by request.redirect.
Http.redirect now use an http.Response type, and it become easy to add an
override like 'set_cookies' e.g.
Dispatch of a website.page return an http.response too, so we first need to
check if it is a cached version before to check if it is an Odoo Response.
Migrate your code:
http.redirect -> request.redirect(location, code, local)
http.local_redirect -> request.redirect_query(location, query, code, local)
http.redirect_with_hash -> request.redirect
Courtesy of odony for help and review ;)
closesodoo/odoo#72599
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
New features to show suggested links as an autocomplete when creating a menu
was introduced with 9b9829416b.
But it was missing a sudo, so non-admin editor could not read module records.
task-2583737
closesodoo/odoo#73035
X-original-commit: d8206db3da541ba3f0c3e9cb63eab802e3ff096b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
* http, http_routing, website, website_sale_comparison
At an crawling engine/SEO level, having trailing slashes or not in URLs doesn't
change anything.
Still, whichever solution is chosen, it should be done consistantly: either all
URLs have trailing slashes, or none of them have it.
See https://developers.google.com/search/blog/2010/04/to-slash-or-not-to-slash
" Be consistent with the preferred version. Use it in your internal links. If
you have a Sitemap, include the preferred version (and don't include the
duplicate URL). "
opw-2505818
opw-2513575
Community: https://github.com/odoo/odoo/pull/71065
Enterprise: https://github.com/odoo/enterprise/pull/18615
The page manager shows an advanced structure if the user has multi website
enabled. It will show specific pages as a child of its generic one.
It is useful to directly understand and figure which pages are 'overiden'.
But it doesn't really makes sense for an end user, which doesn't know there is
actually generic and/or specific pages.
It makes more sense to show that behavior only in debug and not in multi
websites, even more since pages are overiden even in mono website.
closesodoo/odoo#68902
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, the routing map generated and used would be the one from
the website the request is performed, instead of the one from the `fw` website
ID which will be the one we redirect the user to.
This issue was introduced with the routing map by website, be8fc2296b and is
restricted to a single case: a publisher using the website switcher, and it
won't happen on next page naviguation/refresh as the `fw` website id will be
the same as the current website's ID. Thus there won't be any routing map
mismatch.
Step to reproduce:
- Create a page on website 2, set it as homepage
- Naviguate to website 1 on '/' url
- Naviguate to website 2 on '/' url
This will raise a werkzeug error about `EndPoint not iterable`.
----- Technical analysis ------
This is the current flow:
1. `_dispatch()` is setting `website_routing` to `get_current_website()` -> 2
2. `_dispatch()` is calling `_match()`
3. `_match()` is calling `routing_map()` with key = `website_routing`, which
was set to 2 in step 1.
4. `routing_map()` is calling `_generate_routing_rules()` which generate the
rules based on `website_routing`, which was set to 2 in step 1.
5. `_dispatch()` authenticate the user by calling `_authenticate()`
6. `_dispatch()` is calling `_add_dispatch_parameter()`, where URL param `fw`
is forced in session, so `get_current_website()` now return the correct
`website_id` -> 1
The issue: in order to handle the `fw` URL parameter (step 6.), we need to
check the rights to ensure we can allow the website switch.
To check rights, user need to be authenticated (step 5.), which is done after
generating the routing map (2. & 3. & 4.).
The routing map is generated based on the current website (step 1.)
Step 6 depends of steps 5 which depends of steps 2/3/4 which depend of step 1,
but step 1 should depend of step 6, which is an impossible cycle.
closesodoo/odoo#70397
X-original-commit: 4eb26497a774e934d7e1a6be9f505400fd9e2cdb
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Add a big fat warning when the qweb compiler finds a `t-raw`.
`t-esc` should now be used everywhere, the use-case for `t-raw` should
be handled by converting the corresponding values to `Markup`
objects. Even though it's convenient, this constructor *should never
be made available in the qweb rendering context* (maybe that should be
checked for explicitely?).
Replace `werkzeug.escape` by `markupsafe.escape` in
`odoo.tools.html_escape`, this means the output of `html_escape` is
markup-safe.
Updated qweb to work correctly with escaping and `Markup`, amongst
other things QWeb bodies should be markup-safe internally (so that a
`t-set` value can be fed into a `t-esc`). See at the bottom for the
attributes handling as it's a bit complicated.
`to_text` needed updating: `markupsafe.Markup` is a subclass of `str`,
but `str` is not a passthrough for strings. So `Markup` instances
going through would be converted to normal `str`, losing their safety
flag. Since qweb internally uses `to_text` on pretty much
everything (in order to handle None / False), this would then cause
almost every `Markup` to get mistakenly double-escaped.
Also mark a bunch of APIs as markup-safe by default
* html_sanitize output.
* HTML fields content, sanitization is applied on intake (so stripped
by the trip through the database) and if the field is unsanitised
the injection is very much intentional, probably. Note: this
includes automatically decoding bytes as a number of default values
& computes yield bytes, which Markup will happily accept... by
repr-ing them which is useless. This is hard to notice without `-b`.
* Script-safe json, it's rather the point (though it uses a
non-standard escaping scheme).
* Note that `nl2br`, kinda: it should work correctly whether or not
the input is markup-safe, this means we should not need to escape
values fed to `nl2br`, but it doesn't hurt either.
Update some qweb field serialisations to mark their output as
markup-safe when necessary (e.g. monetary, barcode,
contact). Otherwise either using proper escaping internally or doing
nothing should do the trick.
Also update qweb to return markup-safe bytes: we want qweb to return
markup-safe contents as a common use-case is to render something with
one template, and inject its content in an other one (with Python code
inbetween, as `t-call` works a bit differently and does not go through
the external rendering interface).
However qweb returns `bytes` while `Markup` extends `str`. After a
quick experiment with changing qweb rendering to return `str` (rather
unmitigated failure I fear), it looks like the safest tack is to add a
somewhat similar bytes-based type, which decodes to a `Markup` but
keeps to bytes semantics.
For debugging and convenience reasons, MarkupSafeBytes does *not*
stringify and raises an error instead (`__repr__` works fine). This is
to avoid implicit stringifications which do the wrong thing (namely
create a string `"b'foo'"`).
Also add some configuration around BytesWarning (which still has to be
enabled at the interpreter level via `-b`, there's no way to enable it
programmatically smh), and monkeypatch `showwarning` to show warning
tracebacks, as it's common for warnings to be triggered in the bowels
of the application, and hard to relate to business logic without the
complete traceback.
`t-out`
=======
`t-esc` is a bit confusing for the new behaviour of "maybe escape
maybe not", so add a `t-out` alias with the same behaviour.
Unlike `t-raw`, `t-esc` is only soft-deprecated for now: there are
thousands of instances, so editing all the templates is not
great. Eventually we'll add a `ci/style` to prevent addition of new
ones, and eventually we might do a bulk-replace and hard-deprecate.
Attributes handling
===================
There are a few issues with respect to attributes. The first issue is
that markup-safe content is not necessarily attributes-safe
e.g. markup-safe content can contain unescaped `<` or double-quotes
while attributes can not. So we must forcefully escape the input, even
if it's supposedly markup-safe already.
This causes a problem for script-safe JSON: it's markup-safe but
really does its own thing. So instead of escaping it up-front and
wrapping it in Markup, make script-safe JSON its own type which
applies JSON-escaping *during the `__html__` call.
This way if a script-safe JSON object goes through `markupsafe.escape`
we'll apply script-safe escaping, otherwise it'll be treated as a
regular strings and eventually escaped the normal way.
A second issue was the processing of format-valued
attributes (`t-attf`): literal segments should always be markup-safe,
while non-literal may or may not be. This turns out to be an issue if
the non-literal segment *is* markup-safe: in that case when the
literal and non-literal segments get concatenated the literal segments
will get escaped, then attributes serialization will escape
them *again* leading to doubly-escaped content in attributes.
The most visible instance of this was the `snippet_options` template,
specifically:
<t t-set="so_content_addition_selector" t-translation="off">blockquote, ...</t>
<div id="so_content_addition"
t-att-data-selector="so_content_addition_selector"
t-attf-data-drop-near="p, h1, h2, h3, .row > div > img, #{so_content_addition_selector}"
data-drop-in=".content, nav"/>
Here `so_content_addition_selector` is a qweb body therefore
markup-safe, When concatenated with the literal part of
`t-atff-data-drop-near` it would cause the HTML-escaping of that
yielding a new Markup object. Normal attributes processing would then
strip the markup flag (using `str()`) and escape it again, leading to
doubly-escaped literals.
The original hack around was to unescape() `Markup` content before
stringifying it and escaping it again, in the attribute serialization
method (`_append_attributes`).
That's pretty disgusting, after some more consideration & testing it
looks like a much better and safer fix is to ensure the
expression (non-literal) segments of format strings always result in
`str`, never `Markup`, which is easy enough: just all `str()` on the
output of strexpr. We could also have concatenated all the bits using
`''.join` instead of repeated concatenation (`+`).
Also add a check on the type of the format string for safety, I think
it should always be a proper str and the bytes thing is only when
running in py2 (where lxml uses bytestrings as a space optimization
for ascii-only values) but it should not hurt too much to perform a
single typecheck assertion on the value... instead of performing one
per literal segment.
Note: we may need to implement unescape anyway, because it's still
possible to get double-escaping with the current scheme: given an
explicitly escape-ed `foo` and `t-att-foo="foo"`, `foo` will be
re-escaped.
fixup! [CHG] core, web: deprecate t-raw
The following two points are necessary adaptations for
the correct functioning of the configurator with the
module deployed on iap-services.
- The routes of the api_website module deployed on
iap-services.odoo.com use model converters to retrieve
the industry selected by the user. The configurator
has been updated accordingly. We now use industry id
instead of industry name. Using id instead of name make
record retrieval faster and model converters handle
exception if the record doesn't exist.
- 'homepage' is now added to the requested pages by
the client. Previously, this page was added by the iap
module to the requested pages.
The following two points are changes to the configurator
route handling:
- multilang=False has been added to the route rendering
the configurator in order to avoid having the lang in
the url.
- If no step is specified in the url, the implicit step
is 1. Therefore /website/configurator/1 has been changed
to /website/configurator.
closesodoo/odoo#69370
X-original-commit: b6efa4caf6514484c254869cb2f1965d207e7c65
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Sébastien Mottet <smottet@users.noreply.github.com>
On website app installation and on new website creation a configurator is launched.
The purpose of this configurator is to generate a website that meet the user's needs.
The configurator is composed of 4 steps:
1) Business description: the user is asked to describe its need with its website purpose (dropdown), its industry (autocomplete search) and its objective (dropdown).
2) Logo and palette selection: the user must select a color palette for its website. He can also upload its logo. In this case color palettes recommendations are generated based on the logo's colors.
3) Features selection: the user select the pages and applications he needs.
4) Theme selection: three themes are recommended to the user based on its industry. This screen display a preview of these three themes.
task-id: 2451965
ENT PR: odoo/enterprise#16949
UPG PR: odoo/upgrade#2316closesodoo/odoo#67537
Signed-off-by: Sébastien Mottet <smottet@users.noreply.github.com>
Before this commit the recently viewed products were handled differently
from the dynamic product snippet.
After this commit the dynamic product snippet supports the functionality
of the recently viewed products snippet:
- its template used to show each product
- its filter of displayed products
- its "Add to cart" feature (with the animation)
- its "Forget" feature (only applicable when viewing recently viewed)
Also added "Accessories" and "Recently Sold With" filterings.
Several kinds of filtering can be combined.
- Products can be restricted to a given category
- Pseudo categories for all products or current category can be used
- Products can be restricted to matching names
- Products can be obtained from one of the following:
- Newest
- Latest sold: ordered by descending frequency in last 8 orders
- Latest viewed
- Accessories (of the current product)
- Recently sold with (the current product)
Accessories and recently sold with are only available in product pages.
Also, generic templates have been considered useless and the whole
mechanism allowing them has been removed (this includes the
pre-rendering mechanism for the fields specified in the filter).
task-2453416
https://github.com/odoo/odoo/pull/65554
Before the commit, if an exception occurs there was an error saying:
`TypeError: _handle_exception() takes 2 positional arguments but 3 were given`
Impacted versions:
- 12.0
- 13.0
- 14.0
X-original-commit: 47d6fa4ff6e78a33691c22b08504ce03e6796c9a
Before this commit when a dynamic snippet was fully configured but
returned no data, the rendered section remained empty in edit mode.
After this commit when a dynamic snippet is fully configured but has no
data to display, some sample data is generated in edit mode to give a
feel of how the page will look like when data will be available.
task-2446024
https://github.com/odoo/odoo/pull/65176
in this commit, when activated 'Show # found' option in Customize menu,
the count of searched records for the manage your pages, event, and form page
displayed on the search button(#found).
task-2115526
closesodoo/odoo#40121
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, we write on each record the value, whatever the current value.
Now we check if it is necessary to avoid useless fork.
The first change on header was slowly.
closesodoo/odoo#62119
X-original-commit: e18c43d217be89b35213236038e72bc8298061a0
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Jeremy Kersten