When serving a page, fetch the requested page and the menu's pages in
one go.
This will only impact pages that do not have a menu entry, which is the
most common form of pages.
So, instead of:
- read page
- read page's view
and later:
- read menu pages
- read menu pages' views
Fetch everything together:
- read served page + menu pages
- read served page's menu + menu pages' views
task-2774979
closesodoo/odoo#85456
X-original-commit: 16bf7cca8e8d452ce9131d9d86ff5b23789da4e1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
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
Install the website_sale and open '/shop/whatever-9999' in your browser,
the response is a 500 Internal Error instead of a 404 Page not Found.
Because `request.endpoint` has been murdered by the httpocalypse, we
must re-match to get the endpoint later used to re-build the URL. When
an URL contains a record-id but that record does not exists, matching
the URL will raise a `odoo.exceptions.MissingError`.
Part-of: odoo/odoo#85340
Commit [1] introduced a cron that disables outdated js and scss snippets
assets. For example, if a new version of the masonry snippet is defined
with new assets: data-vcss="001" and data-vjs="001", the previous assets
have to be disabled (000.scss and 000.js).
That cron was not handling the scss variables files at all, so when
an outdated snippet was still used in the db and the cron was run, the
000.scss file was activated, but not the 000_variables.scss and it was
crashing the assets.
Now, the XXX_variables.scss assets files are handled alongside the
XXX.scss files.
Also, the regex used in the _is_snippet_used method was only returning
the first match of a snippet in an html field. So if a view had a
snippet up to date and then an outdated snippet of the same type, the
old assets were not activated. The 'g' flag was added to return all the
occurences of the snippet in an html field.
[1]: https://github.com/odoo/odoo/commit/fa1c05e7bb2959c6025a806a4348f69ed225b4ec
task-2775188
closesodoo/odoo#85360
X-original-commit: 644067e80d4ca3f41707cddd15ed8f2807a1e410
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit is the 13th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
Here be dragons.
First and foremost, `http_routing` is a technical module that aim to
provide the minimum viable compatibility code between portal and
website. Its primary job is to take care of the lang inserted in the
path of URLs, e.g. `en` in `/en/my_blog`. Both when routing a request
with a lang in the URL and when rendering templates with multilang
support.
Next to `http_routing` is website, the module used by customers to
create pretty web page accessible online. Website uses a different
routing logic than the backend, webpages are **not** registered in the
routing map of werkzeug but instead delivered by website dedicated
code. It means that **all** request targeting a website page thrown at
the werkzeug router **fail** with a HTTP 404 error. The reality is that
website abuses the fallback mechanism (`_serve_fallback`) to deliver
its pages.
Using `_serve_fallback` as the standard way to deliver pages is broken
by design. It is the least crappy way to deliver content as long as
website page don't have a dedicated path prefix. Using a path prefix
(e.g. `p` in `/p/fr/mon_blog`) it would have been possible to route the
request to a dedicated endpoint using the same router as the backend and
with no change to the HTTP dispatching code. Sadly, the business does
not want such prefix so we have to stick with a broken design.
It is broken because prior to serving a page, website needs to setup A
LOT of stuff on the system. It needs to ensure a proper user is set on
the environment, it needs to setup the GeoIP database, it also needs
to determine the lang the user requested the page and it also needs to
save multiple attributes on the request objet itself (`is_frontend`,
`is_frontend_multilang`, `routing_iteration`, `website`, `lang`,
`rerouting` and `website_routing`). Since `base/ir.http@_match()` will
fail, everything must be set either prior to calling this method or in
`website/ir.http@_serve_fallback`.
---
The original implementation was overriding the `_dispatch` method which
was responsible to call the four `_match()`, `_authenticate()`,
`_postprocess_args` and finally `WebRequest._dispatch()`. The override
was very special, here is an attempt to explain it:
1) try to match an endpoint using the backend router, 404-errors are
ignored.
2) include the geoip stuff.
3) authenticate using the `auth` @route argument if an endpoint matched
in (1), otherwise authenticate with the public user.
4) if not endpoint matched or if a frontend endpoint matched in (1):
a) call `_add_dispatch_parameters` which sets many arguments on the
`request` object, including the lang found in the request cookies
b) try to extract a lang from the URL: abort with a redirection when
the lang is missing or wrong, remove the lang from the request
path when it is set (updating both `request.lang` and the cookie).
5) return the result of `super()._dispatch()`
Note that `_serve_fallback()` is called during `super()._dispatch()`
when the path still does not route to an endpoint. Thanks to the
`_dispatch` overrides in http_routing and website, it is garanteed that
the system is setup prior to calling `_serve_fallback`.
---
Because it is now `http.py@Request._serve_ir_http()` that is responsible
of calling the four`_match()`, `_authenticate()`, `_pre_dispatch` and
finally `_(http|json)_dispatch()` it is no more possible to override it
to take over the dispatching to perform the http_routing/website magic.
The prior implementation can not work with the new design thus is has
been refactored too.
To render a website page, there must be a user configured on the
environment (not None) and the various special attributes must be set on
the request object. The special `lang` attribute is popped from the
request path but backend endpoints must be delivered in priority.
Using the new design, it has been decided to override the `_match`
method to implement the lang-in-path logic, to override both
`_pre_dispatch` and `_serve_fallback` to call `_add_dispatch_parameters`
which have been renamed `_frontend_pre_dispatch` and to also grant the
public user in the `_serve_fallback` override.
The `_handle_error` override in website has similar needs, the function
is called upon error (4xx/5xx) in order to render a pretty
website-looking page. Because such error can occurs as early as in
`_match()` (page not found and no fallback), when nothing has been setup
yet, website is yet again responsible for setuping everything: request,
orm, frontend.
Many other small improvement are not described here. Hopefully the added
comments in the source code are enought.
PR: odoo#78857
Task: 2571224
Commit [1] introduced an automatic start of edit mode when
selecting a theme but didn't take into account wether the frontend lang
of the user was matching that of the website that is supposed to enter
in edit mode.
Steps to reproduce:
- Create an empty database and install website.
- Add an extra lang on website (e.g FR) and visit the website in that
lang.
- Go in settings an create a new website, skiper the configurator,
select a theme.
- Redirect is with enable_editor but nothing happens.
The editor isn't started if not in the source's lang.
This commit redirect the user to the default_lang of the website
so that editor can always be started. It also introduces a tour
to test out the flow.
[1]: https://github.com/odoo/odoo/commit/f474eac4543712ae5b1c7d614f9eff9367445107
task-2687416
closesodoo/odoo#85058
X-original-commit: 02e08af7278cd66d768fe6a4f23aa17eb816be3c
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [1] when fuzzy search was introduced, fuzzy search was also used
when the search term contained numbers.
This is a problem for companies where the shop search is used on
references: the fuzzy search does not match against the whole database
and therefore the exact match might not be found.
After this commit the exact search is used whenever the search term is
made of 80% of numbers or more - because it is very likely to be a
reference or an identifier.
[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986
opw-2715647
closesodoo/odoo#84943
X-original-commit: 7b44907c322a7b78ef4a5cb46627df4f72b21240
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
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>
Prior to this commit, when a user searches with an upper case search
term of more than 3 characters, the search was considered as a fuzzy
search even if the result was an exact match.
Since the search is always lowered when there are more than 3
characters, the search is considered as fuzzy only when the search and
fuzzy term are case insensitively distinct.
closesodoo/odoo#84593
X-original-commit: 34362a7c07a2868103b24d16a83a97356ad1f60d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
As an overridable _neutralize model method was added in a previous
commit, the method is now implemented for various models.
closesodoo/odoo#67825
Related: odoo/enterprise#19042
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Avoid to base64 encode, then decode to process assets and images for a ~25% speed improvement.
Change image processing tool to work on images, rather than base64 encoded strings.
Performance is ~25% faster on assets & images:
/web/assets/...frontend.min.css: 13ms to 7ms, base64 enc/dec: 2 -> 0
/web/image/XML_ID: 10ms to 8ms, base64 enc/dec: 3 -> 0
/web/image/res.users/2/avatar_128: 40ms to 20ms, base64 enc/dec: 6 -> 2
closesodoo/odoo#82851
Related: odoo/enterprise#23537
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Those were not accounted for, leading to fstrings passing through
unflagged.
Also update the SQL checker to be stricter but smarter:
The previous version would "fail open", unknown nodes would be allowed
through hence f-strings not being flagged when they started appearing
in arg0 position, should now fail-closed, anything that's not allowed
is forbidden.
This flags a few more cases, all of which seem acceptable upon review.
However the previous version would also only resolve arg0 (in case it
had a `NAME`, to see if that resolved to an acceptable form of
query-building). The new version performs resolution during
`_check_concatenation` and should thus allow e.g. format strings to be
separate variables (though not e.g. module-level constants, yet
anyway).
In resolution, replace the ad-hoc process by astroid's built-in
`lookup` which seems to provide the same information. Slightly more in
fact, as it yields every assignment in case of e.g. conditionals, but
making use of that would require a lot more changes in the checker so
leaving the behaviour as-is for now.
It's important to *not* use `ilookup` here, because ilookup is not
"iterable" but "inferring", and we don't want values, we want
expression ASTs for analysis.
NOTE: previous improvements as well as fixes to existing code were
only implemented in 14.0, hence this being merged in 14.0 not 13.0
despite 13.0 still being supported.
closesodoo/odoo#81721
X-original-commit: 376ccf0944dae1bc53ae9c5385977c4e6b23e083
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The http.addons_manifest is a map {module: manifest_dict} that is
populated upon the first http request. This map is basically a module
manifest cache with an extra `addons_path` key, the path of the module
on the file-system. This cache is eagerly populated upon the first http
request, the map is empty in non-http contextes (e.g. cron) which have
been a source of bugs (e.g. 50c8eb1).
A manifest cache is necessary because reading and parsing python files
from the file-system is not that cheap but there is no reason that cache
is located in `odoo.http`. A thin cache layer now wraps
`load_information_from_description_file()`/`load_manifest()` and is
lazily populated.
The `http.addons_manifest` have been removed. The extra `addons_path`
key is now present in the "normal" manifest. The `read_manifest()` was
hardly used so it has been deprecated. The only way to retrieve a
manifest is now `load_information_from_description_file()` which was
renamed `load_manifest()` (no cache) and `get_manifest()` (cache).
Side note about performances, the cache is necessary. Addons manifest
are read-only and reading + parsing python files from the file system is
not a cheap operation. Running the e-commerce tour
`@website_sale.test_04_admin_website_sale_tour` without cache on
`load_manifest()` requires 68,29 secs to complete on my laptop,
exceeding the default 1-minute time frame allowed in tests. Using a
cache the time is down to 36,53 secs. The performance impact is huge.
Part-of: odoo/odoo#79977
Generic search bar was introduced with #65871.
But the trigram search would fail if it encounters a (SQL) NULL text
from the database. This is because when word_similarity() receives NULL
as a parameter it returns NULL, and NULL not being a number cannot be
compared with the similarity threshold.
After this commit the trigram search will exclude matches returning a
NULL similarity.
Step to reproduce:
- Enable trigram in the DB, run `CREATE EXTENSION pg_trgm;` in psql
- Create a product, name it `myproduct`
- Insert NULL values inside the translation table (not sure how the
user did it):
`update ir_translation set value = NULL where src = 'myproduct';`
- Search 'mypro' in the eshop search bar
-> Traceback
opw-2680659
closesodoo/odoo#80426
X-original-commit: ef17edc32d4646c93e31e730249be83469951241
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, the behavior disabling the unused snippet assets was put
directly in the autovacuum CRON instead of its own CRON.
That behavior is leading to some perf-issue running the autovacuum cron since
it would take too much time.
Indeed, the code will loop inside as many snippet as it exists, and every time
then perform an SQL Query to get the HTML fields using the snippet.
An improvement will come later to not loop on every snippet anymore.
task-2694120
closesodoo/odoo#79981
X-original-commit: 96ab95d37c9b442a4ccb737fd867ca91ec1c11b6
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.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>
When using the configurator the user can upload its logo to
generate a color palette. In this case we select the base-1
palette as default palette instead of the theme's default palette.
Doing so avoids the potential customizations the theme palette
may introduces.
task-2665885
closesodoo/odoo#78251
X-original-commit: 50019c8f68b89968615f87c365095c94caeef46c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
On theme switch default images of the previous theme are replaced
by the one of the new theme. For website where default images
come from the configurator we don't want them to be replaced by
the theme's images.
task-2614840
closesodoo/odoo#77648
X-original-commit: c25f80c70930f65a928b44d4fe91775c37bc4268
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Initialize the savepoint semi-lazily (on-demand) as cycling a savepoint
generates 4~5 queries (depending whether the savepoint is explicitly
released on COMMIT or not):
SAVEPOINT
-- < do stuff>
-- commit
RELEASE SAVEPOINT -- or not
SAVEPOINT
-- close
ROLLBACK TO SAVEPOINT
RELEASE SAVEPOINT
With a lazy savepoint, this is just 0-1 queries (`SAVEPOINT` at the
first explicit query only, creating a cursor and then closing it
immediately is a no-op).
For reliability use a semi-lazy savepoint: always immediately emit a
`SAVEPOINT` on cursor creation, but don't automatically create one
after each `commit`. That limits the issues of overlapping (but
non-nested) savepoints.
Also fix the `generate` API to not use the request: when `website` was
converted to the new API, `cr`, `uid`, and `context` were dropped as
if it were a model... but it's not. So in order to recover an
execution environment, that was looked up on the session.
That, then, turns out to be an issue when `generate` is triggered from
an RPC call: the RPC layer creates its own cursor and environment
separate from the request's which may not have one at
all. Problematically during testing we're in `mono_db` mode, so the
request's cursor/env can be accessed and will be lazily initialized.
This then causes an issue with the `TestCursor`'s savepoints: rather
than be nested, the lifetimes of the request's and RPC's savepoints
only overlap[0]:
|-- rpc --|
|-- request --|
As a result, when the RPC's cursor is committed and released it
automatically released the request's, and the request's explicit
release then fails. This would break `/website:WithContext.test_search`.
By fixing the API of `generate`, it stops triggering the creation of a
request cursor, and therefore the overlap and resulting error.
[0] the laziness or eagerness of the savepointing in the test cursor
has no impact on this issue, as multiple requests have already been
issued on the RPC's test cursor before the request's is even
created
Part-of: odoo/odoo#76243
Previously the configurator retrieved the snippet lists
needed to build the website pages from IAP. These lists
have been put in the theme manifests and can be accessed
from it.
odoo/design-themes#505odoo/iap-apps#411closesodoo/odoo#77550
X-original-commit: 01c97c697aa0c5cae79952f1d3ac8de69bf2ad1a
Related: odoo/design-themes#510
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Now, iap only return images urls needed to process the svg.
We don't need to 'download' svg preprocess, we use the svg locally and make
the substitution ourself.
It simplify the maintenance:
Preview of theme are in theme repository
It make it blazing fast:
Response contains a list of string, and not more a big string, the svg.
closesodoo/odoo#77199
X-original-commit: 103ec4debb539b04b1783be20f1ccf3e18ab377e
Related: odoo/design-themes#503
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
`website` added its own sql-compatible version of
`get_unaccent_wrapper` in order to use `psycopg2.sql` for safety.
That is very sad.
Add a condition in the "standard" unaccent wrapper which checks
whether the input type is a `Composable`, and in that case return an
`SQL`. This increases the cost of the wrapper a tad but probably not
to a really sensible amount.
Task 2634851
Part-of: odoo/odoo#76436
The configurator's palette selection screen didn't support
SVG logo. On SVG upload primary and secondary colors couldn't
be extracted and no palette was recommended. It comes from the
fact that Python PIL library does not support SVG. We therefore
had to convert SVG to PNG before trying to extract primary and
secondary colors. A file format checking has been added. If the
uplodad file is not an image, a notification is displayed to
the user.
task-2602521
closesodoo/odoo#76400
X-original-commit: 33f43618f727bdc1239c52c66b73f0f436035774
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Refactor the Environments object into a Transaction object, which is
bound to one cursor, and is no longer shared among several cursors.
The following methods/properties have been changed:
- Environment.envs no longer works (because of the design change);
- Environment.manage() is deprecated (no longer useful);
- Environment.reset() is now an instance method;
- env.clear_upon_failure() is deprecated in favor of cr.savepoint().
closesodoo/odoo#75598
Related: odoo/enterprise#20451
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Xavier Dollé <xdo@odoo.com>
Before this commit the search on pages was only done in the main
language.
After this commit the search on pages is based on the translated "arch"
field.
task-2379555
https://github.com/odoo/odoo/pull/65871
Part-of: odoo/odoo#65871
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
Before this commit searched terms were the ones entered by the end-user.
After this commit if the searched term is not found then the search is
performed on a resembling term.
The similarity is obtained from a Levenshtein distance combined with
ratios of common and different letters.
By default the dictionary against which the search term is matched is
based on the content of the search fields containing a word that starts
with the first letter of the search term.
If the `pg_trgm` Postgresql extension is installed the dictionary is
built from matches using the `<%%` operator (similar to the
`word_similarity` function).
Several approaches were benchmarked during development, those results
are available through the task record.
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
Based on their path, we retrieve snippets assets, assuming that it will
be in the form : /snippets/{snippet_id}/{version}.{scss|js}
Then we check the template definition uses that version, or if any views
or html fields contains a snippet with such version exist.
If not, the asset is deactivated.
For that, we are looking for the data-snippet attribute in snippets
already dropped. For the template definition, we look at the first class
definition if a data version attribute is also defined.
task-2212216
closesodoo/odoo#73005
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
The saas version of the client is added in each call to
website.api.odoo.com. This allows the server to return
different results based on the client's saas version
task-2602521
closesodoo/odoo#75617
X-original-commit: 6e1ae856584048912cb5eaf53c0aa027b2342b5c
Signed-off-by: Sébastien Mottet <smottet@users.noreply.github.com>
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
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>
The configurator takes care of the organization of the links to the different
pages. Some links are put in the menu and some are put in the footer. The order
is predefined. If too many links are present in the menu then a sub-menu 'Company'
is created and some links are put in it. For the 'News' and 'Succes Stories' features
a website specific blog is created.
Links have the following order in the menu and are present only if their corresponding
website.configurator.feature has been selected in the configurator excepted for the 'Home'
and 'Contact us' links which are default links:
- 'Home'
- 'Shop'
- 'Event'
- 'Courses'
- 'Services'
- 'Pricing'
- 'Company': if more than 8 links in menu and more than 1 item in this submenu
otherwise the three following links are in the top menu.
- 'News'
- 'Success Stories'
- 'About us'
- 'Appointment'
- 'Contact us'
Links in footer:
- 'Privacy Policy'
- 'Help': if website_helpdesk installed. This is not a website.configurator.feature.
- 'Forum'
Community: https://github.com/odoo/odoo/pull/71993
Enterprise: https://github.com/odoo/enterprise/pull/18930
task-2518565
Co-authored-by: Sébastien Mottet (oms) <oms@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
Before this commit, if the configurator was applied without a module to install
it would still go through `_button_immediate_function()` which does
```
self._cr.commit()
api.Environment.reset()
modules.registry.Registry.new(self._cr.dbname, update_module=True)
```
for no reason, even if `self` is an empty module recordset.
This code is taking ~5 seconds.
This flow will occur when you either:
- Create a new website when selecting only page feature
- Create a new website when some modules feature are already installed
Community: https://github.com/odoo/odoo/pull/71993
Enterprise: https://github.com/odoo/enterprise/pull/18930
task-2518565
Before this commit, some snippets that contains special charactere like –
was wrongly displayed, since we removed the call to pycompat that did a
decode('utf-8') in previous version.
closesodoo/odoo#74041
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, overrided images was not visible if not logged in.
How to reproduce
----------------
Install a theme with configurator to have custom image of industries.
Log out
You have original image instead of industries
closesodoo/odoo#73921
X-original-commit: d1241379a7c5f999b7a82ca290dd8b5f212a0997
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
`_render('<h1> quick & flupke </h1>') `=>` '<h1> quick & flupke </h1>'`
what cannot be parsed in xml after.
Before this commit, if you try to install a page that contains a '&' via
the configurator, you had a traceback:
xmlParseEntityRef: no name, line 1, column 13
closesodoo/odoo#73509
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Rename field website_type_preselection to website_config_preselection since feature
preselection is not only based on website type anymore but also on website purpose.
task-2518565
closesodoo/odoo#73377
Related: odoo/enterprise#19498
Related: odoo/upgrade#2625
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Purpose is to have more detailed information given back when calling new_page.
Now each new record adds its entry in returned result:
* view_id: new ir.ui.view created. As there is always a view (based on a
template) it is now always set, and not only when creating a page;
* page_id: set if ispage is true, ID of website.page created;
* menu_id: set if add_menu is true, ID of website.menu created;
Previously only view_id was returned when creating a page which can be a
limitation notably in website_event.
Task-2577079
PR odoo/odoo#72411
If user selects 'schedule appointments' as main objective in the configurator
and if the website_calendar module is installed then the Call To Action of
snippets s_banner, s_cover and s_call_to_action is changed to 'Schedule an
appointment' and redirect user to '/calendar' on click.
task-2518565
closesodoo/odoo#71162
Related: odoo/enterprise#18690
Related: odoo/design-themes#5
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Creating a website through the configurator activated the configurator tour.
This tour was active for every websites even the ones not created using the
configurator. Theme tours were overridden by the configurator tour when they
should have been the active tour for website not created using the configurator.
Now the configurator tour is an asset specific to each website. This asset is
deactivated by default and activated for a website only if it is created using
the configurator.
- Some actions of the website tour were also visible when we were not in edit
mode. extra_trigger has been added on these actions to ensure they are visible
only in edit mode.
task-2518565
closesodoo/odoo#72827
X-original-commit: 5799410ec257fc7f756722579d3d0141b0ce7de4
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- The selection of cards corresponding to already installed modules
is disabled. A disabled style has been applied to these cards and an
info icon added. On hover on this icon the user is informed that the
module is already installed on its DB.
- Modules that were preselected based on website type can now be
unselected by the user.
- Correct typo in description of feature_module_career.
task-2518565
closesodoo/odoo#72688
X-original-commit: ab364b06dbb20cce90c7caa8ca15d034e2dcb25e
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Sébastien Mottet <smottet@users.noreply.github.com>
Introduced with 7fb016f9966b
[0] access could crash, recordset could be empty after `filtered`.
Step to reproduce:
- Add admin group to website top level menu (Website > Debug > Menu)
- Try to access frontend as non admin
opw-2573763
task-2574346
closesodoo/odoo#72535
X-original-commit: 759d920d799d332220d86467d83aeb9334b61ce2
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
A shape is made of different colors which are mapped to user color
combination colors (e.g. if a shape use the #3AADAA color, it is by
default mapped to color combination background color n°4). We allow
to add other arbitrary mappings for each shape should a theme want it,
thanks to another created class. This is especially useful for header
and footer connections in default generated pages where the combination
of classes "o_web_editor_Airy_12 o_footer_extra_shape_mapping" will
use a color mapping using the footer color if the theme configured the
Airy 12 shape to do so.
This commit also modifies the generation of pages made by the website
configurator to automatically add the header and footer respective
classes on first and last shape if one is found (if one is found but
should not have a specific color mapping, this is not a problem as the
class has only an effect if the theme declares it).
Part of https://github.com/odoo/odoo/pull/68336
task-2491890
X-original-commit: 232224ff8c54c5027ec20dd9ddd5c0afc121a092
Before, get_http_domain make the job,
now we force website.domain to be valid
closesodoo/odoo#71161
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit improves the mechanism to find the best URL given a record.
To find the best suited URL, the following heuristic will be done:
- If record has a website_id, use that website's domain
- Else if a record has a company_id, use the company's website's domain [1]
- Else use the `web.base.url` ICP
The following commit will replace (almost) every occurence of ICP by the
`get_base_url()` helper method.
[1] Before this commit, there was no way to know which website was the one from
a company, has a company could have no website but could also have multiple
websites.
We now consider the first found website for a company as the company's
website. The use of a new sequence on `website` will allow user to chose
which website to use.
Community: https://github.com/odoo/odoo/pull/68201
Enterprise: https://github.com/odoo/enterprise/pull/17538
Upgrade: https://github.com/odoo/upgrade/pull/2372
task-2476101
Romain Derie