If a user is not present in the request, he is in no group at all and
can not access any model, including the one available for public
users.
Avoid ambiguity by using sudo or add a user specifically.
Part-of: odoo/odoo#125216
When deleting a page, `search_url_dependencies` tries to trawl through
all models to see if they might have a link to the page being deleted.
However if the user invoking that function does not have access to a
model with an HTML field, it raises an error. Given pages are managed
by website designers which are *not administrators* there is no reason
to believe the current user has access to every model in the
database (not that even admins do these days). Since
`search_url_dependencies` is a best-effort search anyway, just ignore
any model to which the current user doesn't have access.
An alternative would be to do the search in sudo mode, but that
doesn't seem necessary, and could even be problematic if a match is
found:
- it might leak information the user should not access (because the
record name is returned, as well as the model & field names)
- it will trigger further access errors (because links to problematic
records are provided, on which the user might want to click)
closesodoo/odoo#127973
X-original-commit: 47a69a186bc415bf61a523da9686ca96c0beb74e
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This is a proposal to try to find a similar asset before generating one.
If get_attachments fails, the next step will be to generate the
attachments from scratch, a slow operations.
When creating a new website, all assetsbundle would actually be
similar to their version without website, but the url is different.
This can be visible because the first loading of /web is slow after
creating a new website: the website_id is forced in the session
and the assets_backend are regnerated, identical to the original ones.
This commit proposes to try to find an attachments with differents extra
but the same uniquifier when possible and copy it's content.
Note that just returning the other attachement url may work, but it
would be confusing to randomly have links to assets comming from another
website_id. This would also be a problem if the original attachment is
unlinked, forcing to recompute it for other websites.
Good to know, since the content is the same, no duplication of the
content should appear in the filestore, just an entry in the database.
Part-of: odoo/odoo#121376
Fix an issue where products with internal references containing point
or slash were not recognized as direct matches in the website searchbar.
Instead, fuzzy search was used to find similar words.
This commit addresses the problem by fixing the regular expression
used for matching words in Odoo's search functionality.
X-original-commit: dee84ff3b0ec56149780e6eefb8724f954918fd1
Part-of: odoo/odoo#124211
When generating a new page key, it was only made sure to not match
existing page keys. This leads to COW happening on existing views if the
key already existed in a view.
This commit ensures that new page keys are not existing view keys
either.
Steps to reproduce:
- Create a page named "snippets".
=> Notification was shown indicating that `website.snippets` is private.
task-3328827
closesodoo/odoo#123693
X-original-commit: e7ef9f0bfc59a468c9f883561c371367cc06c1b7
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
*: website, website_blog, website_event
This commit adds the TikTok social network to the other social networks
stored in DB. Thus, users of the Website application will be able to
reference their TikTok page on their websites. This commit also updates
the different templates and the social media block to integrate this new
social network.
task-3235451
Part-of: odoo/odoo#116837
Before this commit an ir_assets generated automaticaly by the web editor
will generate an url ending with ...custom.addon.bundle_name.ext
After this commit the url will start with /_custom/addon.bundle_name/...
This will make it easier to spot at immediately if it is a custom asset
and thus it is useless to apply the glob. Actually, it will fail on the
/_custom when trying to glob, making it faster.
This is mainly useful to clarify and debug but in a case with mainly
customised ir_asset for one bundle, it may have an impact on speed.
An upgrade script was created for this change.
closesodoo/odoo#120699
Related: odoo/upgrade#4636
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
== Issue ==
A business code error was detected by the internal team on our
production. The cache and assets where invalidated !WAY! too often for
the past months.
It was hard to figure but finally the error was tracked down to be
located in the assets retrieval stack of our code when a database is
accessed through multiple different domains.
In our production use case, whenever one was accessing `odoo.com/web`
after someone accessed `accounts.odoo.com/web`, the assets would be
invalidated and recomputed, again and again, whenever someone accessed
the backend on a domain after someone else did with another domain.
Obviously, on our production, this could be occuring multiple time per
minute.
Technically, this is because the "assets retrieval stack" had a mismatch
in multiple endpoint when trying to find if a current website was
involved (serving for the frontend).
Some business method were using `env.context.get('website_id')` while
others were using `env['website'].get_current_website(fallback=False)`.
From there, when the code was called without a `website_id` in the
context, `get_current_website()` would still return a `website_id` when
called from `http://odoo.com` as there is a website having its domain
set to it. `get_current_website()` is then finding it and returning it.
But it would not when the user is on `http://accounts.odoo.com`.
Since we have a custom scss override (done through our website builder,
basically an ir.asset linked to a "url type" attachment:
`/website/static/src/scss/options/colors/user_color_palette.scss`) for
our website to define the website colors which is shadowing the scss
file from disk.
So, depending of the host/domain, either the real file disk for this URL
or the ir.asset linked to our website for this URL would be fetched to
generate the bundle hash (which is basically the last modification date
of the files/attachments).
Obviously, the file on disk and the ir.assets have a different last
modification date.
The system would then consider the assets as outdated and would
regenerate it.
You can see it in the logs where the attachment id of the assets URL
would get higher and higher everytime you access the DB through another
domain.
Using `get_current_website(fallback=False)`:
- `_get_related_assets()` https://github.com/odoo/odoo/blame/30d3b97b5ece379d9ddcbceda9d12c03dc7f4a48/addons/website/models/ir_asset.py#L14
- `filter_duplicate()` https://github.com/odoo/odoo/blame/30d3b97b5ece379d9ddcbceda9d12c03dc7f4a48/addons/website/models/ir_asset.py#L41
- ..
Using `get_current_website()`:
- `_get_custom_attachment()` https://github.com/odoo/odoo/blame/30d3b97b5ece379d9ddcbceda9d12c03dc7f4a48/addons/website/models/assets.py#L162
- ..
Using `context.get('website_id')`:
- `_get_asset_url_values()` https://github.com/odoo/odoo/blame/30d3b97b5ece379d9ddcbceda9d12c03dc7f4a48/addons/website/models/ir_qweb.py#L23
- ..
== Fix ==
A fix could have been to aligned those to use the same way of retrieving
the website but it would be too fragile (definitely some other places
where the same bug is involved but not yet found).
What is done in this commit is something we wanted to do for a long time
(see [1]) but was based purely on guess and feeling rather than concrete
bug / use case, but now that we found a real use case, we will do it:
- It doesn't seems to make sense to consider the request host/domain
when we are in the backend
- Same for the forced session, those should only impact the frontend
calls.
But this seems to have too much impact in stable to be changed, as it
would require to check every caller to also check for the session if
it makes sense. This will be done in master as not really needed to
prevent the critical bug fixed here.
- When something wants to alter the backend with a website, it should
explicitely be passed in the context, which is still considered
regardless if it's a backend/frontend call.
- If something needs to consider the forced website in session in the
backend, it should explicitely check it, not relying on
`get_current_website()`.
== Step to reproduce ==
- Start a db with website installed
- Enter the website builder in edit mode and change the "Theme Colors"'s
first "Color Presets"'s background color (it is white by default).
- Set the website domain to `http://127.0.0.1:8069/`
- Go to `http://127.0.0.1:8069/web` and login
- Go to `http://127.0.0.2:8069/web` and login
- Now start refreshing those 2 pages one after each other.
Everytime you will refresh the page, it will take a very long time
(~5-10 seconds) before loading the page, and monitoring the logs will
show something about invalidating the cache and huge query count.
== Benchmark ==
For the explained "multiple domain access" case, the backend /web will
now be loaded in less than 10ms and with ~10 SQL Queries when website is
installed, while it was taking ~4 seconds and ~200 Sql Queries before
the fix.
Before the fix:
```
odoo.modules.registry: At least one model cache has been invalidated, signaling through the database
GET host1.com/web HTTP/1.1 200 - 222 0.135 3.840 <-- 222 Queries, ~4s
odoo.modules.registry: At least one model cache has been invalidated, signaling through the database
GET host2.com/web HTTP/1.1 200 - 181 0.101 3.692 <-- 181 Queries, ~4s
odoo.modules.registry: At least one model cache has been invalidated, signaling through the database
GET host1.com/web HTTP/1.1 200 - 215 0.121 3.704 <-- 215 Queries, ~4s
odoo.modules.registry: At least one model cache has been invalidated, signaling through the database
GET host2.com/web HTTP/1.1 200 - 181 0.100 3.616 <-- 181 Queries, ~4s
```
After the fix:
```
odoo.modules.registry: At least one model cache has been invalidated, signaling through the database
GET host1.com/web HTTP/1.1 200 - 101 0.043 0.353 <-- 101 Queries, ~0.3s
GET host2.com/web HTTP/1.1 200 - 11 0.004 0.007 <-- 11 Queries, ~10ms
GET host1.com/web HTTP/1.1 200 - 11 0.003 0.005 <-- 11 Queries, ~10ms
GET host2.com/web HTTP/1.1 200 - 11 0.003 0.008 <-- 11 Queries, ~10ms
```
[1]: https://github.com/odoo/odoo/pull/94161#discussion_r904780031 (Also other PR/task but couldn't find those.)
closesodoo/odoo#120364
X-original-commit: 28dd35eb3c681b630f0b3c109a7d8209f9fa42d8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
a new context `prefetch_langs=True` allows ORM to prefetch all translations of
translated fields while fetching.
For example
The activated languages are 'fr_FR' and 'nl_NL'
In the database the value is '{"en_US": "English", "fr_FR": "French"}'::jsonb
after fetch with `prefetch_langs=True` the raw cache value will become
{'en_US': 'English', 'fr_FR': 'French', 'nl_NL': 'English'}
closesodoo/odoo#116947
Signed-off-by: Raphael Collet <rco@odoo.com>
Many templates use the company logo that is set by default on
database creation. As that logo is clearly a placeholder and the user
isn't necesserely prompted to update it. It's possible for a user to
inadvertently start sending emails with "your logo" placeholders
plastered all over.
This removes the default logo of the company and removes it from
templates conditionally.
The logo isn't simply replaced with a transparent PNG as the templates
set a fixed height for the logo, which would look weird.
task-3067315
Part-of: odoo/odoo#106307
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Until now, if you search for /shop/Desk for a new link, you will not
have any result.
Now we search that it match *shop*desk* so /shop/custom-desk-12 will
match.
closesodoo/odoo#114357
X-original-commit: 84a407e744b7bacab43a0213ab52002a49c5d623
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Previously when we tried to delete default_website it was deleted.
In this commit we have fixed this issue by preventing user to unlink
default_website.Also we remvoe _unlink_except_last_remaining_website
method.
sentry-3874625419
closesodoo/odoo#113405
X-original-commit: 637af9f747bda0d6b4607d02a0e51d44cf889a89
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The first objective of this commit is to polish the website
configurator:
1) On page 1 of it: - The size of the text is increased.
2) On page 2 of it: - The font size inside dropdown is reduced.
- 30 results are displayed inside dropdown instead
of 15.
3) On page 3 of it: - The size of the text is increased.
3) On page 4: - The cards are refactored.
- The end line is removed.
- The "Build my website" button is moved to the left.
4) On page 5 : - It is now impossible for the user to click on a theme
preview before it is completely loaded.
5) On all pages, the size of the "Skip and start from scratch" button
has been increased.
On the second page of the website configurator, the user has to choose
an industry type. Sometimes, it happens that the user is searching for
an industry that is not known by the server. Before this commit, a
message of type "No result found" appeared and the user had to choose
an other industry among the existing ones. From this commit, the
"No result found" message is replaced by the name of the industry that
the user is writing. To choose its industry type, the user can click on
the displayed industry name or outside of the input area. This last
option calls the `_blurIndustrySelection` function and the written
industry is kept as the final industry choice. If the user chooses an
industry name that is not known by the server then the remaining of the
website configuration is done with the "abbey" industry. Moreover, this
unknown industry name as well as the language used by the user is sent
and stored to the IAP database. The goal of it is to regularly update
the industry list so that it becomes as most complete as possible.
IAP PR : https://github.com/odoo/iap-apps/pull/549
task-3062171
closesodoo/odoo#110187
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, when obtaining link URL suggestions, both the
specific and the matching generic page were suggested.
After this commit, only the most specific ones are kept in the suggested
list.
This commit also adapts the sitemap in the same way.
In stable, a condition on a dedicated context key is used in case those
methods were called with the goal of obtaining both generic and specific
pages.
In 16.0, those methods will always filter duplicates pages as it was
supposed at first.
Steps to reproduce:
- Edit Contact Us page (to create a specific view)
- Edit the Contact Us menu
- Type "/" in the URL
=> "/contactus" appeared twice.
task-2968292
closesodoo/odoo#112746
X-original-commit: c5a50362ef55ced373c53c7af069fd5534043ae2
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Commit [1] improved the url dependencies search behavior to include more
models to search in but also the multi record capability (needed for
multi delete in list view now that website is in the backend).
But a line of code was badly designed, making the perfs horrible.
That line code shouldn't have been part of the loop as it doesn't
depend of the loop.
This was drastically more impactful on the `/` page.
Benchmark: for the `/` page, searching in 1000 product template website
description will go from 29.74 seconds to 0.29 seconds.
See the speedscope result on the PR description.
For ~10.000 products, it will go from ~7 minutes to 1.35s.
[1]: https://github.com/odoo/odoo/commit/6ac17b93437868cbefbe13448a6fcbb29953f221
task-3169378
closesodoo/odoo#111933
X-original-commit: 9816b2ba6ee85dcba7b2f85e70c617994b7748c4
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Before this commit, this flow was broken:
- Install website
- Create a new website of your own (not using the one created
automatically from XML data)
- Choose another color palette for that website
- Uninstall the website app
- Reinstall the website app
- Try to choose another color palette for any website
=> It does not work
Indeed, after the uninstallation, the DB is left in an invalid state:
the SCSS customizations attachments of the website that was created by
the user are not removed, they just have their website_id field emptied.
Some code made at [1] was already there to remove those attachments. The
problem is that it only worked for websites which were created by XML
data (at website installation), not by the user. Indeed, the `unlink`
method is not called during uninstallation to remove records that were
created by the user, thus the `unlink` override was not called either.
See [2] for some details.
This fixes the issues by moving this attachment cleaning code in a
dedicated method, called in `unlink` but also in the `uninstall_hook` of
the website app.
This also takes the opportunity to refactor the code involved, in
particular to not even consider customized attachments which do not have
a website_id.
[1]: https://github.com/odoo/odoo/commit/2f361bec36dff09181b96d140d62c477cdf013a1
[2]: https://github.com/odoo/odoo/pull/97852#pullrequestreview-1067851656
opw-3127531
closesodoo/odoo#110338
X-original-commit: 988eafa03b57be3b3a7f110650c61ce8fda88e31
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, the behavior disabling the unused snippet assets
performed two checks:
1. It was looking for occurrences for its use in the snippet template
2. It was looking for occurrences for its use in the HTML fields
3. Checked on the occurrences of step 1 and 2 and return result.
In many cases there are already coincidences in the first step, making
the second step unnecessary since this second one is the slowest.
Matches are now checked between steps 1 and 2 to skip the second if
matches are already found.
closesodoo/odoo#109488
X-original-commit: 56100532dbcbdeb5487662d0cbf35ba6d62b15b5
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce the bug:
- Install the "Surveys" application.
- Go to the "Website" application.
- Go in the page manager ("Site" > "Pages").
- Select a page (typically "Home").
- Try to delete it.
- Error of type "'survey.survey' object has no attributes 'name'".
The error comes from the fact that records do not necessarily have the
attribute called "name". To fix this error, this commit uses
"display_name" that is defined in all models.
task-3082345
opw-3100483
opw-3111671
X-original-commit: d5aa5d7ebf9cd17a6df054252a1313ec8b85e83e
Part-of: odoo/odoo#109329
Before this commit, we have redundant loc in sitemap.
When we iter the rules from the routing map, the comparison between
two same endpoints are not equal since httpocalypse.
After this commit we compare the function of the endpoint to know if we
have already processed it or not.
X-original-commit: c408de398c6b4e59cd9a233df251147d8750b9f2
Part-of: odoo/odoo#108670
The main goal of this commit is to reduce the size of the registry by
removing the (almost) useless __last_update field.
Statistics # of fields with all modules installed:
before 30184 fields, 1299x last_update (4.30%)
Before this commit, the computed field __last_update was added on every model.
The idea behind this field was to have a computed field that had either
the write_date or the create_date if the write_date was empty. However,
the write_date is always written, even on creation, making it useless
to have the computed field __last_update
After this update, we completely remove from BaseModel:
* __last_update
* CONCURRENCY_CHECK_FIELD that was always defined as "__last_update"
* _compute_concurrency_field that was the compute function for __last_update
closesodoo/odoo#105739
Task-id: 3062140 (part of 3062137 improve registry load time)
Related: odoo/upgrade#4038
Related: odoo/enterprise#33939
Signed-off-by: Raphael Collet <rco@odoo.com>
This commit ensures that when searching on a `inherits` field of
a model (like `name` of `website.page`), it works properly when
`pg_trgm` is activated.
Indeed, `name` is a field of `website.page` record but only at the ORM
level, not in SQL, due to how `inherits` works.
So, when the `pg_trgm` extension is enabled, it will switch from ORM
queries to raw SQL query (to use the native SQL similarity feature and
not our custom python/orm one, as obviously the SQL one is better, more
powerfull/accurate and faster).
But this will actually make the code fail when searching on fields from
a model which has `inherits` and that you search on that `inherits`
model fields.
Note that in 15.2, the `pg_trgm` extension is auto installed when
possible thanks to [1] and [2].
[1]: https://github.com/odoo/odoo/commit/eedf37d6e286b995c47b946be1a6b66817094eff
[2]: https://github.com/odoo/odoo/commit/75e6b645acdc95aece506ce0249fd0760838281c
opw-3063592
closesodoo/odoo#107178
X-original-commit: 3d978caad9de2010603581687ee39a5240b74074
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: test_website, website, website_blog, website_event, website_forum,
website_sale, website_slides
Reverts this refactoring because it breaks multi-tenancy: if several
databases run on the same server and different modules are installed
in each database, the global variable becomes wrongly populated.
Steps to reproduce:
On runbot:
- Go to the `-base` URL or simply select the `base` DB
- Drag & Drop the search snippet (and let it set to "Search in
Everything")
- Try to use the snippet -> Crash on unknown model
On Odoo.com saas DB:
- Drag & Drop the search snippet (and let it set to "Search in
Everything")
- Try to use the snippet -> Crash on unknown model (unless you installed
each and every module related to the search snippet)
Locally:
- odoo-bin -d first -i website --stop-after-init
- odoo-bin -d second -i website_blog --stop-after-init
- odoo-bin -d first,second
- Try to use a search bar on "first" database (using "Search in
Everything") => it tries to access the blog models.
Revert of PR: #98423
opw-3045092
closesodoo/odoo#105077
X-original-commit: 5806f71af1b6f44aac063f7e504be736300f699d
Related: odoo/enterprise#33669
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
This fix allows generating the sitemap (via `website.search_pages`) via
RPC. The changes are necessary as since #99667 the `request` object is
no more available to RPC-executed functions.
See also: the `test_search` test case of `website.tests.test_page`.
closesodoo/odoo#104567
X-original-commit: 8f4e214417cfb1aed7e595b8d6ab71f33a347b29
Signed-off-by: Julien Castiaux <juc@odoo.com>
`is_view_active` relies on the `website` specified in the context.
This commit turns `is_view_active` to a model method, to avoid that its
callers think the `website` on which it is called is the one used.
closesodoo/odoo#103126
X-original-commit: 52d436706bf650bb14f2bc2a398d107ff99f81ea
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Previous commit adapted the URL dependencies screen following the
website frontend > backend merge done at [1] and [2].
It allowed to pass other records than website.page and also added the
multi record capability.
This commit is going a step further, by searching for the URL in all
HTML fields and not only views + pages + menu + blog.
It also let the XML take care of the wording instead of the python.
closesodoo/odoo#103136
X-original-commit: 6ac17b93437868cbefbe13448a6fcbb29953f221
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This is following the website frontend > backend merge done at [1] and
[2].
Before that improvement, the old page manager had a button to delete a
page which was behaving as the one in the page properties dialog: it was
showing the list of (possible) dependencies as a confirm step.
But since [2], that delete button was removed as the action menu of the
list view already has a delete button, which is better as:
- It is hidden and take no space, deleting a page is rare
- It is known by odoo users as all list views have that button
- It handles multi delete
So this commit basically just restore that delete warning step for that
list view delete button, and also make it possible to use that
dependencies warning dialog for multiple pages, not only one.
It also now handles records in a generic way, not only website pages.
It's needed because now, all the main Odoo frontend records are sharing
a list view mixin (see `js_class="PageListController"`).
It also fixes the fact that the text of the collapse were inside a font
awesome class, basically using a weird font.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/940f4ee875332dafa1f379970a7683be6b3ee606
X-original-commit: 11db2f6ed81419ac724ff27ac95a4438d670cbd5
Part-of: odoo/odoo#103136
This is basically reverting commit [1] which was done a few years ago
as improvement to [2], but it was a bit overkill IMHO.
Indeed, there is a sort of hack when creating a page with special
extension like "my-page.js" that will actually create a special page
with special arch. The goal is for such pages to be `t-call`ed later.
That's commit [2].
On top of that, when deleting such a special page, we introduced a
mechanism to show the views and pages that would possibly `t-call` the
that page which is requested to be deleted.
That's commit [1].
It basically is mimicking what was already done when you change the URL
of a normal page, we tell the user where that url is actually possibly
used.
But since the recent improvement in Odoo 16 done at [3], the page
manager is now a backend list view. It means that multi delete is now a
thing.
Thus, the page dependencies behaviors (key and url) need to be
refactored to handle multiple given URL/Key and not just one.
We choose to remove the key dependencies part (only used for those
special pages) instead of adapting it:
- That 'hack' is probably almost never used
- It's some code to maintain, eg now we need to refactor it
- We would need some extra code to make it only triggered for website
pages and not all records, unlike the url dependencies screen which
concerns all records
- That's an advanced feature (special pages), if you are using it, you
probably knows how to handle a website and you don't need us to remind
you where this special page's view is used.
[1]: https://github.com/odoo/odoo/commit/a91a3a563338e746d6d23cd57551af30e322e367
[2]: https://github.com/odoo/odoo/commit/727d461e1d2bcec4571665b90b6d1630f671a0a3
[3]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
X-original-commit: 77f03abc56b147171eeba66bc55df5ee92c8af1a
Part-of: odoo/odoo#103136
*: website_forum, website_hr_recruitment, website_sale
Before this commit, most of the backend redirections to the
WebsitePreview, introduced in [1], were using ir.actions.url with the
get_client_action_url util, which was not optimal.
This commit changes that to use a new get_client_action method, which
returns the ir.actions.client record. It will execute the action
directly, avoid to redirect the router before, and improve performances.
Also, it allows to solve bugs, as:
- The back navigation from the WebsitePreview to the ListViews.
Going through the /web controller would add an entry in the history, and
going back on it would reload the client action.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#102991
X-original-commit: 30fb11e479fb7b3db3649e55fcbdb06bfcdb398c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit the neutralize system introduced in v16 was using ORM
methods in order to change appropriate records. Although flexible, this approach
could lead to call some methods with side effects while neutralizing
(eg: overloads of write).
This patch converts the neutralize system to a safer "inert" SQL based approach
by migrating the generic method _neutralize to SQL files exposed in the
data folder.
Task id: 2961687closesodoo/odoo#102792
X-original-commit: e5dbded9bb363351feff7ca8a56c7f8a6860f492
Related: odoo/enterprise#32580
Signed-off-by: Fabien Meghazi <fme@odoo.com>
The /web loading was slow during test when some themes are installed.
This is because without any context and request, the assets are
generated for website 1 before this fix.
With this default website:
_get_active_addons_list returns only addons that are not themes
_get_asset_paths will return less assets
When loading /web, no website is found because the domain is not empty.
This means that the web.assets_backend will have less assets when
generated outside of a request than in a request not matching any
website.
There is normaly no assets for the backend in theme BUT a tour is added
in each theme
('/theme_anelusia/static/src/js/tour.js', 'theme_anelusia', 'website.assets_editor')
('/theme_artists/static/src/js/tour.js', 'theme_artists', 'website.assets_editor')
('/theme_avantgarde/static/src/js/tour.js', 'theme_avantgarde', 'website.assets_editor')
('/theme_aviato/static/src/js/tour.js', 'theme_aviato', 'website.assets_editor')
('/theme_beauty/static/src/js/tour.js', 'theme_beauty', 'website.assets_editor')
('/theme_bewise/static/src/js/tour.js', 'theme_bewise', 'website.assets_editor')
('/theme_bistro/static/src/js/tour.js', 'theme_bistro', 'website.assets_editor')
('/theme_bookstore/static/src/js/tour.js', 'theme_bookstore', 'website.assets_editor')
('/theme_buzzy/static/src/js/tour.js', 'theme_buzzy', 'website.assets_editor')
('/theme_clean/static/src/js/tour.js', 'theme_clean', 'website.assets_editor')
('/theme_cobalt/static/src/js/tour.js', 'theme_cobalt', 'website.assets_editor')
('/theme_enark/static/src/js/tour.js', 'theme_enark', 'website.assets_editor')
('/theme_graphene/static/src/js/tour.js', 'theme_graphene', 'website.assets_editor')
('/theme_kea/static/src/js/tour.js', 'theme_kea', 'website.assets_editor')
('/theme_kiddo/static/src/js/tour.js', 'theme_kiddo', 'website.assets_editor')
('/theme_loftspace/static/src/js/tour.js', 'theme_loftspace', 'website.assets_editor')
('/theme_monglia/static/src/js/tour.js', 'theme_monglia', 'website.assets_editor')
('/theme_nano/static/src/js/tour.js', 'theme_nano', 'website.assets_editor')
('/theme_notes/static/src/js/tour.js', 'theme_notes', 'website.assets_editor')
('/theme_odoo_experts/static/src/js/tour.js', 'theme_odoo_experts', 'website.assets_editor')
('/theme_orchid/static/src/js/tour.js', 'theme_orchid', 'website.assets_editor')
('/theme_paptic/static/src/js/tour.js', 'theme_paptic', 'website.assets_editor')
('/theme_real_estate/static/src/js/tour.js', 'theme_real_estate', 'website.assets_editor')
('/theme_treehouse/static/src/js/tour.js', 'theme_treehouse', 'website.assets_editor')
('/theme_vehicle/static/src/js/tour.js', 'theme_vehicle', 'website.assets_editor')
('/theme_yes/static/src/js/tour.js', 'theme_yes', 'website.assets_editor')
('/theme_zap/static/src/js/tour.js', 'theme_zap', 'website.assets_editor')
Making the bundles for /web different with or without theme, and with or
without website id.
The proposed fix wont return a website if not specified in context and
if not during a request and if not forced to fallback.
The side effect is that the frontend assets where generated with a
website id 1 before that and it won't be the case anymore. This may be
a problem that could slow down frontend call on website 1 when design
theme is installed.
closesodoo/odoo#102690
X-original-commit: a5ed957b37b966bc50ed1219b6af65ed818f04a0
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, when one would remove the favicon of a website in
the settings it would crash.
This is because since [1] the introduction of `base64.b64encode()` in
the `_handle_favicon()` method make it crash with `False` value.
Steps to reproduce:
- Settings > website
- Delete favicon
[1]: https://github.com/odoo/odoo/commit/6b8752604898bf2b583b7f5334e35f6a1583595e
opw-2958836
closesodoo/odoo#100399
X-original-commit: 35ce152d7e5c50cb363c0fa7adecf174fede9e46
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Website: the context install_filename='dummy' is used to prevent
arch_updated from becoming True while updating translations of
ir_ui_view.arch_db (if arch_update becomes True, test_inherit_specific
fails)
Fuzzy search for jsonb translated fields has been adapted in the case of
website. It may require some refactoring later.
Short summary:
- People can now use the snippets option to show/hide based on country
- We never use / test / maintain this feature, if it still works since
its introduction 4 years ago that's by luck
- It is probably barely used, we never got a single question or issue
about it
-----------
When we introduced the multi-website feature, it came with 2 main use
cases:
1. Multi website by domain -> Every website has its own domain and based
on that we serve the expected website
2. Multi website by geoip -> Multiple website can have the same domain
and based on GEOIP/country we serve the expected website
We never really supported, highlighted or promoted the geoip case.
We actually never use it ourselves when doing tests, and we don't
consider it when doing specs / improvements.
At most, only a very few people know about it in Odoo.
That GEOIP case is probably not useful at all, as displaying a whole new
website based on lang is not easy since nothing can be shared out of the
box -> Every website has its own COW records.
For instance, one could think of having its main website A and another
website B on which he just added 3 products specific to that website B
country.
But such a case won't even work properly, as any adaption on website A
won't be reflected on website B (design, theme etc).
closesodoo/odoo#99938
Related: odoo/upgrade#3892
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, only a website.page could be used as a custom
homepage ('custom' meaning other than '/').
But it is a real use case and requirement for our users to be able to
select a controller as homepage.
For instance, an ecommerce would want its homepage to be the shop and
not a regular page from where you then have to navigate to the shop.
Right now, this can (almost) be achieved by doing some technical
advanced operations:
- Move the 'Shop' menu first in the menu navbar of the website
- Delete the specific '/' website.page for the website
- Delete the generic '/' website.page (no website_id)
That way, the system will redirect `/` to `/shop`, which is not ideal as
it should remain `/` in the URL.
That's because, until now, the homepage (`/` controller) serve order
was:
- Serve the website.page set as homepage (`website.homepage_id`),
happens when one did select another page as homepage through the page
properties dialog
- Serve the website.page having `/` as URL (default)
- Serve the first accessible menu if there no `/` page or other page set
as homepage, it acts as a last resort attempt to not serve a 404 and
to try serving relevant content (the first menu of a website is most
likely always better than a 404)
- Serve 404
This commit allows to introduce an URL as homepage, instead of only a
website.page. It can be done through the website settings in the
backend.
There is 2 main points to keep in mind about serving the homepage:
- make sure we don't serve a 404 as the website homepage. This is the
website entry point, serving a 404 is terrible. That's why we have
some fallback mechanism like serving the first menu.
- We need to serve / before fallbacking to the first menu, as a lot of
site just remove the 'Home' first menu since it is a duplicate of the
logo, which also redirect to the homepage. In such cases, it doesn't
mean that the user want his first menu to be the homepage. We
shouldn't rely on such a behavior, it should just be used as a last
resort.
With this commit, the homepage serve order is now:
- If homepage URL is set (empty by default), serve the website.page
matching it
- If homepage URL is set (empty by default), serve the controller
matching it
- If homepage URL is not set, serve the `/` website.page
- Serve the first accessible menu as last resort. It should be relevant
content, at least better than a 404
- Serve 404
Most DBs will just have a website.page with '/' as URL and keep the
homepage_url setting empty.
task-2969683
closesodoo/odoo#99100
Related: odoo/upgrade#3876
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- use util method already used in regular theme selector screen
- theme_common is already in hidden category, no need to exclude it
- searching on theme category rather than `theme%` name
- move the uninstallable check in the util, no reason to show those in
the regular theme selector screen either
Fixes#92125closesodoo/odoo#99099
Related: odoo/design-themes#586
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* = test_website, website_blog, website_event, website_forum, website_sale,
website_slides
`_search_get_details` extension in other modules can now be performed with
fewer lines of code by updating a search type-to-model mapping, without the
need for method override.
This will also have the benefit of slightly reducing the call stack length,
avoiding some unnecessary `if` statements and list lookups at runtime.
Task-2957361
closesodoo/odoo#98423
Related: odoo/enterprise#30946
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* website_event, website_slides
Note that `restricted_editor` is the new technical name used instead of
`publisher`
Before this commit, the `is_restricted_editor()` method was actually
checking for `designer` rights and not `restricted editor` ones.
Indeed, a restricted editor (previously publisher) never had the write
right on ir.ui.view.
Despite the method name being wrong, it was still correctly used where
we actually checked for designer rights and not publisher/restricted
editor ones.
Also, the method was checking for write access on ir.ui.view instead of
checking directly if the user had the related group.
While it wasn't really wrong, it was also including people who would
have the write right on ir.ui.view but were not part of the designer
group.
This doesn't really makes sens, as we don't want someone which received
that write right on ir.ui.view from another module (not related to the
website) to be considered as a website admin -> we don't want to show
them website admin UI and stuff like that.
The method could have simply be renamed to `is_designer()` and could
have just checked for `has_group(designer)`, but having such an helper
seems overkill, we would end up with as many utils as there is groups.
At the end, this PR:
- removes the confusing util method
- replace it by has_group checks
Part-of: odoo/odoo#98200
* portal, web_unsplash, website_*
This commit renames the `website.group_website_publisher` into
`website.group_website_restricted_editor`.
While the change in itself might look unuseful, it will help the dev and
tech community figuring which group is related to which feature.
Even internally when we discuss specs, we always have to remind which
group is the restricted editor: the publisher one or the designer one?
While it is probably, after all those years, now anchored in some dev
mind, there is no easy way to directly figure which of those 2 groups is
the restricted editor one.
Note that I myself always got confused about it.
Now, the "Restricted Editor" right will be reflected in its technical
name `group_website_restricted_editor`.
Same as for the "Editor & Designer" which technical name is
`group_website_designer`.
As we would like to have a fully working and ready system in v17 for the
community to be able to build themes easily, removing that dubious part
is a nice to have.
Part-of: odoo/odoo#98200
Allow the user to select multiple languages in the website creation modal.
task-2745347
closesodoo/odoo#86541
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
For performance reasons, when fuzzy search was introduces it was
decided to limit the number of records used for finding fuzzy terms to
1000. Because of this, when a database contains more than 1000
products matching words that start with the same letter, further
products are not examined. This can lead to searches not finding an
existing exact match.
This commit introduces a fallback mechanism so that, if we are in a
situation where the maximum number of examined records was fetched, we
also explicitly check for a possible exact match across all records.
Steps to reproduce:
- Do not install the pg_trgm extension.
- Have more than 1000 products containing searchable words (name,
description...) starting with the same letter.
- Add one more such product (so that it is not in the 1000 first ones).
- Search for that last product by correctly typing the word.
=> Exact match was not returned.
task-2870947
closesodoo/odoo#97657
X-original-commit: 6d24ea28b236155d542e3d2be3da379b9f4e9ce6
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Just a nice to have. It will prevent those errors to be replicated when
copy pasted and will help reading the files in the IDE.
closesodoo/odoo#97282
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
==== Short version ====
Google is deprecating Universal Analytics in July 2023 and Google
Sign-In in March 2023. Google Analytics Embed API is based on Sign-In,
meaning it won't work anymore. It actually already doesn't work anymore
for accounts created somewhere after mid-2020 apparently.
There is no plan for now for Google to allow Analytics 4 dashboard to be
embed in external website.
We therefore can't do anything to keep the Google Analytics dashboard in
Odoo.
In previous stable version, it was kept but is displaying a warning
about it (as until mid 2023 old accounts can still embed it).
All this is about the embed dashboard, not the tracking in itself for
which Odoo is already adapted in Odoo 15.0 for Analytics 4.
==== Detailed version (following short version, read it first) ====
- Universal Analytics EOL July 2023, see [1].
- It will be replaced by Analytics 4 for which Odoo is already ready and
actually using it since version 15.0 with [2].
- Google Sign-In EOL March 2023, see [3]. Analytics Embed API was based
on it, it won't work anymore.
- There is no plan (for now) for Google to allow Analytics 4 to be able
to be embed in external websites. They seem to just have dropped the
"feature".
This was confirmed by Google here [4] and indirectly here [5] in the
DOC:
`Note: This API does not support Google Analytics 4 (GA4) properties`
- While the EOL is planed for 2023, the dashboard integration is already
not working anymore for new accounts.
- Old projects/keys/accounts can still embed their analytics dashboard.
The threshold seems to be somewhere mid-2020, according to [6].
It seems to be accurate as my own key from 2018 still works, while my
keys from 2021 do not.
==== Fix ====
- In stable, warn user about it in their Odoo Analytics dashboard (this
PR) and also add a warning about that on the doc.
- In master, simply drop the whole google analytics dashboard
integration and remove the doc about it, see [7].
==== Useful links ====
[1]: https://support.google.com/analytics/answer/11583528?hl=en
[2]: https://github.com/odoo/odoo/commit/78bc86cbeccfc5df16218aee2b0d7c501e5c05b5
[3]: https://developers.googleblog.com/2022/03/gis-jsweb-authz-migration.html
[4]: https://issuetracker.google.com/issues/233738709?pli=1
[5]: https://developers.google.com/analytics/devguides/reporting/embed/v1
[6]: https://support.google.com/analytics/answer/11583832
[7]: https://www.odoo.com/documentation/15.0/applications/websites/website/optimize/google_analytics_dashboard.html
Finally, note that it means that from July 2023 to Octobre 2023, while
Odoo 14.0 is still supported, Google Analytics won't work anymore in
that version as it will still be designed for Universal Analytics and
not Analytics 4.
opw-2710910
opw-2855405
opw-2881515
opw-2892370
task-2790245
task-2820890
closesodoo/odoo#96280
X-original-commit: d065595f77790fb5ab9480f6de5b88549352324b
Related: odoo/enterprise#29666
Related: odoo/upgrade#3698
Related: odoo/documentation#2499
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Install multiple langages, each time translating the website. In a
private browsing session access /contactus, show the page source, the
multiple alternate URL (`<link rel="alternative">` in the `<head>`) are
all pointing the canonical URL instead of the alternative.
closesodoo/odoo#95683
X-original-commit: 3d4b4d3dcff864613a9e7038137e21674425ed08
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Julien Castiaux <juc@odoo.com>
Martin Trigaux