This commit adds the database ID to the IAP calls made to generate text.
It permits to prevent abuses of OpenAI calls.
task-3740440
closesodoo/odoo#154615
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
It should not be common, but through custo or in debug mode, one can
create a menu without an URL since it's not required on the model.
Through regular flows, it won't be possible since our UI won't let you
go through when creating a menu if you don't set a URL.
Followup of https://github.com/odoo/odoo/commit/948235079f002794f9837d3cf91e2d20e3254e20
X-original-commit: f2ac2ab72a190375c8116a11109191c0b7b970dc
Part-of: odoo/odoo#160588
[This commit] fixed an issue with the menu cache. Unfortunately, during
the forward port, we missed updating the cache key according to what has
been done in [this other commit]. This commit updates the cache key and
improves the test.
Steps to reproduce the bug fixed by this commit:
- Render a website without a record URL in the menu (to the cache)
- Edit the website's menu
- Add a link to a product page (e.g., customizable-desk)
- Add a link to another product (e.g., chair-floor-protection)
- Save the menu
- Click on the menu link to go to customizable-desk
=> At this point, the active menu element is correct
- Click on the menu link to go to chair-floor-protection
=> The active menu element does not update
This issue does not occur if there is a record like URL in the menu
before the first render.
[This commit]: https://github.com/odoo/odoo/commit/970c173530e5523d0e3242ad84dae6fe5e332d68
[this other commit]:https://github.com/odoo/odoo/commit/595aa248433246959a5fa9288e477091701c6a35
opw-3694651
opw-3750925
opw-3781668
closesodoo/odoo#159464
X-original-commit: 9b5647f2951cdd7bde214f860b5ea95d42d2a501
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Since [this other commit], the style indicating the active nav item
stopped working if the user added record pages to the navbar. This was
due to the cache system not being invalidated when switching from one
record page to another.
This commit fixes the issue by disabling the cache for the navbar if
there is a record page in the menu.
Other potential solutions were considered but ultimately rejected:
1. Using the record as a t-cache key. However, this would mean that if
you have 60,000 visible forum posts, you would end up with 60,000
different caches.
2. Activate the correct element using JavaScript. This would lead to a
duplicate logic in the JavaScript and the Python code, and it would
introduces a slight lag to add the active class on the correct nav item
(due to the time it takes to load and execute the JavaScript).
The chosen solution is the best compromise, as it maintains the cache
for most cases (website menu without records page links in it), nothing
change with this commit. For problematic cases (record pages in the
website menu), this commit disables the cache, which is a reasonable
trade-off.
Steps to reproduce the bug fixed by this commit:
- Edit a website's menu
- Add a link to a product page (e.g., customizable-desk)
- Add a link to another product (e.g., chair-floor-protection)
- Save the menu
- Click on the menu link to go to customizable-desk
=> At this point, the active menu element is correct
- Click on the menu link to go to chair-floor-protection
=> The active menu element does not update
This commit fixes the issue (a update of the website module is needed)
and adds a test to prevent regressions.
Notes:
- To see the issue locally, remove the --dev xml or --dev all arguments.
- The same issue was occurring with other record pages (blog posts, ..).
- We will introduce back the groups on menu and benefit from this new
method to also disable the menu cache if one of the menu is linked to
a group. See task-3800830
[this other commit]: https://github.com/odoo/odoo/commit/b0a2a41d78292cb8b9e53788d40c6dc5915a466d
opw-3694651
opw-3750925
opw-3781668
closesodoo/odoo#159006
X-original-commit: 43576cd424b6d0fc7da01142b5e6550e371ad1ff
Related: odoo/enterprise#59321
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
__Current behavior before commit:__
When the field `website_id` of a user is set, this user should only be
able to login via this website (cfr. [this method][1]). This means that
he can only login if [`get_current_website`][2] returns the same website
as `website_id`.
The issue is that when login with RPC, `dispatch_rpc` is making a
[`borrow_request`][3] which hides the `request` object from the RPC
layer. This has the consequence that `get_current_website` is not able
to retrieve the website based on the url of the request. Thus preventing
a user to login via RPC even if the domain used corresponds to the
website set in its `website_id` field.
__Description of the fix:__
Add the possibility to retrieve the current website via
`threading.current_thread().url` (which is set [here][4]). This way it
is possible to know the current website even if `borrow_request` has
been used.
__Steps tor reproduce:__
- Install `website`
- Go to Website > Configuration > Websites
- Set the domain of the first website (e.g. `http://localhost:8069/`)
- Go to Marc Demo" res.partner form view
- In Sales & Purchase tab set **Website** to "My Website"
Then run this script in another terminal:
```python
#!/usr/bin/env python3
import json
import urllib.request
url = "http://localhost:8069/jsonrpc"
dbname = "db-16.0"
def rpc_login_user_demo():
"""
Login with demo using JSON-RPC
:return: the user's id or False if login failed
"""
req = urllib.request.Request(url=url, data=json.dumps({
"params": {
"service": "common",
"method": "login",
"args": [dbname, 'demo', 'demo']
},
}).encode(), headers={"Content-Type": "application/json"})
response = json.loads(urllib.request.urlopen(req).read().decode('UTF-8'))
if response.get("error"):
raise Exception(response["error"])
return response['result']
uid = rpc_login_user_demo()
if uid:
print("Login success")
else:
print("Login failed")
```
The login will fail but it should succeed since we sent the request with
the same host than the website domain.
opw-3742591
[1]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/addons/website/models/res_users.py#L40
[2]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/addons/website/models/website.py#L944
[3]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/odoo/http.py#L361
[4]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/odoo/http.py#L2037closesodoo/odoo#157372
X-original-commit: b8bc400909012dd04d383287a1850bfc96dd0c5c
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Julien Launois (jula) <jula@odoo.com>
This commit prevents the sitemap from being translated when a website is
available in multiple languages. The sitemap should always be in the
default language of the website.
Steps to reproduce the bug:
- Set up a website in English and French
- Navigate to the French version of the website (/fr)
- Access the sitemap (/sitemap.xml)
=> The sitemap appears in French but should be in English.
Note: There is a cache for the sitemap. It is not regenerated if it has
been generated within the last 12 hours (see `SITEMAP_CACHE_TIME`).
task-3743970
closesodoo/odoo#155472
X-original-commit: 809854c5d10735fb280141f5291bdb84d8d36569
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
This shouldn't change anything regarding SEO, but is worth a try.
It will also impact the link suggestion when creating a link in the
editor, but having pages listed first also have sense there, or at least
it won't be worst.
The idea for the SEO part is that if the sitemap order (if too long)
would have some impact as crawlers might have a limited crawling budget
for your website and it will only crawl the first pages it finds.
Are those "first pages" impacted by the sitemap order? It's almost sure
it's not, as Google definitely knows how to crawl on its own, and is
even probably ignoring the sitemap most of the time.
Also, pages:
- Are probably always important content since you created manually a page to
write something, while (some) controllers might just be content you
care less about. Pages are probably always important while we can't
say that for controllers.
- Should be fewer in number than controllers most of the time
- Have a lastmod set, as opposed to controllers
- May be created at any time, meaning a new crawler visit is needed,
while controllers are almost never added in production, installing a
new module is something very rare. Exception is about record's
controllers which are "created" at any time like pages (eg a new
product controller page)
For all those reasons, this commit reverse the pages vs controllers
order in the sitemap.
This is coming from our prod where some pages are yet not indexed while
they have been published months ago.
closesodoo/odoo#152350
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Note: This fw-port commit cherry-picked and squashed commit [2] directly
as it was fixing this original commit before it had the chance to
be forward ported.
Since commit [1], which adapted the website pages list view to OWL, the
records listed on screen are filtered according to the active website
filter. However, the full list of records is still used behind the
scenes for all potential actions.
Steps to reproduce:
1. Go to the pages list view.
2. Select a specific website (if it's not already the case).
=> The total of records in the upper right corner does not match the
number of pages on that specific website.
3. Click on the "Select all" checkbox.
=> All the pages are selected, including those that do not appear on
screen.
This is because the records were just visually hidden with a `t-if`.
[1]: https://github.com/odoo/odoo/commit/940f4ee875332dafa1f379970a7683be6b3ee606
[2]: https://github.com/odoo/odoo/commit/db670f64f4c2190f1655f9077ea62885049a3c84
Courtesy of @robinlej and @detrouxdev
Related to task-3676124
opw-3554064
opw-3658648
closesodoo/odoo#149547
X-original-commit: 8d78a916dc8c0eca82e8a6a2c6f5541938709930
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit changes the timeout of the OLG call to 20s. We don't want
users to wait too long for the creation of a new website.
Related to task-3248852
closesodoo/odoo#137703
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
__Current behavior before commit:__
When searching for an **Internal Reference** of a product variant on the
website shop, the fuzzy search is likely to return a wrong result.
If the **Internal Reference** of a product template resembles the
searched term, it will take it as a fuzzy term and will not even search
for product variants internal references.
This is because the method `_basic_enumerate_words` only parses the
fields of the model considered but not the "subfields", in this case the
`product_variant_ids.default_code`.
__Description of the fix:__
Run `_search_exact` in any case and only then, if no result is found,
run a fuzzy search.
__To reproduce on runbot 15.0:__
In the website shop, search *FURN_0096*. Although there is a variant
of *Customizable Desk* that has this exact **Internal Reference**, the
search will only return *Office Chair Black* because this product
template has a **default_code** set (*FURN_0269*).
opw-3476643
closesodoo/odoo#143635
X-original-commit: 5887b4f7246dac734f192025404d65002fff6f20
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
This commit fixes a bug in page creation by the configurator. This only
happened with pages containing only one snippet, like the "Pricing" page
or the "Privacy Policy" page (default themes). Because of this bug, the
snippet that should be placed in the page had its parent element
"<section>" replaced with a "<div>", so the section options were no
longer available in edit mode, such as background options,
delete/duplicate/save the snippet, etc.
When there was multiple snippets, it worked by chance:
`<section></section><section></section>` was parsed as
`<div><section></section><section></section></div>` using the etree lib.
The web_editor `save` method then copied each children and put them in
the targeted oe_structure.
However, with only one snippet:
`<section><div class="container"></div></section>`
it was parsed as it is, then same: each children was copied and put in
the targeted oe_structure... but the only child here is the `container`.
Then the classes of the section were transferred on the oe_structure
element.
Steps to reproduce the bug:
- Create a new website using the configurator.
- Check the "Pricing" box in the list of features to create the
"Pricing" page.
- Once the website creation is complete, go to the "/pricing" page.
- In edit mode, click on the "comparisons" snippet.
- Bug: Some options are missing for the snippet, for example, it's not
possible to delete the snippet or change its background.
task-3570903
closesodoo/odoo#143049
X-original-commit: 68ffe065c6fa03874ee8c99b91ca317d1c2755a3
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When creating a new website through the configurator, the images that
will be used on the website will be the one specified by the selected
industry.
We recently introduced 2 new images with commit [1] for which the
industries have no images set as we did not have time to do it.
It would require going through the ~4000 industries and finding a
relevant image on Unsplash for it.
This commit is simply using another existing set image instead.
Indeed, if an industry hasn't set an image, the theme one will be used
instead, which is less ideal.
Step to reproduce:
- Create a new website
- Select "Garden furniture store"
- Select the Orchid theme (the one in the middle to this day)
- Drag & drop the Banner snippet, 2 out of the 3 images used in this
snippet will use the theme images (images about flowers) instead of
images of furniture (related to the selected industry)
[1]: https://github.com/odoo/odoo/commit/3cbdf754ff8fac8a77887c4307b658cb86b0be1dclosesodoo/odoo#141117
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit permits to check if the text theme is translated before
asking IAP for a text generation. We need the text to already be in the
target language to be able to generate the text in the target language.
task-3248852
closesodoo/odoo#136937
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit modifies the "New Page" dialog so that it displays a list
of page templates to pick from in addition to the possibility to create
a blank page.
task-3381714
Part-of: odoo/odoo#126719
Co-authored-by: stefanorigano (SRI) <sri@odoo.com>
This commit adapts the configurator so that the pages it generates are
composed of the primary templates generated from the manifest by the
previous commit.
task-3381714
Part-of: odoo/odoo#126719
Replace all the calls to get_resource_path to the better file_path or
directly use file_open when not needed
Doing both a get_resource_path and file_open means checking twice that
the file exists.
Doing a simple path concatenation before a file_open is safe.
If given to another method (e.g. etree.parse), calling file_path is
the prefered method.
Note that get_resource_path used to return False when the file does
not exists while file_path/file_open raises a FileNotFoundException
closesodoo/odoo#135607
Related: odoo/upgrade#5187
Related: odoo/enterprise#47475
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Issue:
Search on website has a big performance issue because the database has
too many product_template.
Analyze :
The website search mechanism has hardcoded sql query. And the generic
query don't have any filtering. Which lead to make a expensive search
(similarity) on the whole product_template even if the products are
not published and then displayed to the user.
Fix :
Filter the is_published field in the generic website method when the
model has a 'is_published' field and the request is not done by a user
(thus for customers or portal users).
Note:
The internal user is still able to search on unpublished product.Thus
have no performance improvement.
Benchmark:
| SQL Query | # Input data | Before PR | After PR |
|:---------:|:------------:|:---------:|:--------:|
|General best_similarity |700000 products (161 published) | 12.65 s | 0.12 s |
|FROM ir_translation|2,796,000 ir_translation | 6.338 s (586k hit) | 0.091 s (185 hit) |
Related task:
task-3473786
Related ticket:
opw-3418457
closesodoo/odoo#136080
X-original-commit: fcb968836a2d0e49516fe3ecb23dde61f4597749
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When building a website with the website configurator, you get pages
with a nice layout. However, the text inside is not adapted to your
company, industry or even, most of the time, language.
Using a LLM, we could easily get text much more relevant to customer
needs. The scope of this work is static pages generated with the website
configurator (homepage, about us, pricing, ...).
Later, in other tasks, we also want users to be able to generate text
inside the website builder.
This commit implement the bare minimum to generate and replace a website
content by AI generated sentences (based on the information provided by
the user).
Related IAP PR at https://github.com/odoo/iap-apps/pull/656
task-3248852
closesodoo/odoo#121021
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
During the rendering of website configurator pages, we check that the
rendering of each snippet is done for some reason. That check is useless
because:
- Either the rendering fails and in that case, there is a raised
exception that we catch (note that catching it could also be useless
actually: we will check that post 17.0 release).
- Either the rendering is empty (weird case to cover ?) and the
remaining code should work regardless anyway.
Note that in the original code, that `if` covered the case of trying to
render a non existing view... but was changed in [1] such that in that
case, an exception (that we catch) will be raised.
[1]: https://github.com/odoo/odoo/commit/880954ebfc1106411b7f7a7d60aee05dfae60893
Related to task-3248852
Part-of: odoo/odoo#121021
The configurator code organization should be reviewed. This is a first
step that will be needed for the integration of a new feature: this
removes the one-call inner functions inside that `configurator_apply`.
Related to task-3248852
Part-of: odoo/odoo#121021
Since #121376 a clear_cache was removed when unlinking an attachment
This clear_cache was not useful when restarting a server with new
sources, an other operation changing the content of an assets should
invalidate the cache manually. This is the case of ir.asset CUD
operations.
Unfortunately, a manual update was left missing in website, when
archiving ir.assets used for snippets.
This was discovered on runbot, with two workers, when the first workers
generates assets before the cron, and the second one after the cron.
The second worker unlinks attachments creating an inconsistency in the
cache of the first one.
This problem can be solved quickly by invalidating the assets cache in
the cron manually but this will be done in all cases. The proposed
solution will check the ir.asset that should change and only clear the
cache if the state changed.
Regarding performances, this should actually be a slight improvement in
query count since at the cost of one more select to prefetch the record
we can avoid multiple update, one per snippet. In most case no update at
all should be done, at most 2 can be done (one for archive, one for
unarchive).
Example with some assets to unarchive:
Before:
TOTAL ENTRIES: 277
SELECT: 158 (~0.16591858863830566s)
UNKWOW: 54 (~0.0202481746673584s)
UPDATE: 65 (~0.03202557563781738s)
After:
TOTAL ENTRIES: 214
SELECT: 159 (~0.1663439826965332s)
UNKWOW: 54 (~0.029229164123535156s)
UPDATE: 1 (~0.0002865791320800781s)
If the number of query is lowered, the python processing is slightly
higher. Locally the test time is similar, slightly longer since an
additional call to _disable_unused_snippets_assets was added to check
the cache invalidation
closesodoo/odoo#130973
X-original-commit: 3aeab51ff4379e6d76172614fd39f09d6c449ac6
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Since commit [1] (introduced in Odoo 15), when a published website page
has no URL set, the search snippet would crash when typing something
inside it.
I am not sure why was the page url not required at the model level, this
will be considered in master.
Note that to create a page without a URL, the only flow is to create a
new page in the backend.
Indeed, the `write` is overridden to add a trailing `/`, and the
frontend flows to create/write a page are also shielded against empty
URL.
Note that it's easy to create a page without a URL through legit flows.
Depending on the Odoo version, there is always a way to reach a website
page form view: either simply Website > Configuration > Pages or
Site > Pages > Debug mode > Click on Bug icon in tree view > Click on
page m2o.
Step to reproduce:
- Create a page with no URL (see above explanation how to do it)
- Make sure it's publish (you can do it in the form view)
- Drag & drop the Search snippet on a page
- Type something in the search snippet
-> TB
[1]: https://github.com/odoo/odoo/commit/9f9c4bb7e40233e633f97c60fb00ae191e9077af#diff-77bd6b19c39e211959885024bcad914655ff84cfc10c16633687d014e50aa69aR69
Fixes https://github.com/odoo/odoo/issues/129728closesodoo/odoo#129915
X-original-commit: f75ec6131eff9165b06d42d27a49dd756387f4a0
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [this commit], when the user configures a new website, he can
set an unknown industry. Unfortunately, if he does so, by default, we
set the industry to abbey, which is not very good for the default images
the user will see and for internal IAP stats. This commit permits to use
the new industry called Unknown, which is used for unidentified
industries. When the industry is unknown, we leave the default theme
images.
[this commit]: https://github.com/odoo/odoo/commit/e82a1cb2ef1bcb413d99e7eb7521405d1d2e88d2
IAP PR: https://github.com/odoo/iap-apps/pull/635
task-3337894
closesodoo/odoo#129154
X-original-commit: 17dd3a84d9d9d42b04fde9aac708c032a472b13b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
**Description of the issue/feature this PR addresses:**
- Increase user experience in creating website themes
- Eliminate redundant creation of 1 record leading to unnecessary model
`ir_model_data` contraints error
**Recreate the Situation**
- Install the website module
- Choose `a business website` in line 1, `fashion designer` in line 2,
`get lead` in line 3 on `configurator - step 2`
- Choose random paletee on `configurator - step 3`
- `Build my website` on `configurator - step 4`
- Suppose in this step that we have a bad connection to the api
`https://website.api.odoo.com`, the error `duplicate key value violates
unique constraint` will appear.
**Reason**
- When a user creates a website, the `configurator_apply` function is
called to the api `https://website.api.odoo.com`. If the connection time
exceeds 5s, the `configurator_apply` function will be called again.
Maximum of 3 times
- Each time `configurator_apply` function runs, will create records of
model `ir_model_data` at `set_images` function. This function will
create records with a name field like
`configurator_1_s_cover_default_image`.
- If this function runs again for the second time, it will also generate
a `configurator_1_s_cover_default_image` for the second time. This will
result in a `duplicate key value violates unique constraint` error.
**Before commit:**
- When creating a website theme by industry, if the user's connection to
odoo's api has a delay, it will cause an api contraints error of model
`ir_model_data`
**After commit:**
- Check if the record of model `ir_model_data` has been created before,
if created then skip
closesodoo/odoo#128959
X-original-commit: 56ccf4efeb946e2e0b6ef54b977b6d8b070306ee
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
One of the main issue with ormcache is that the invalidation clears
everything, meaning that some value, slow to compute but with a long
lifetime, can be removed from the cache because an easy to invalidate
value is cleared, like after writting or creating a product has an
example.
Most example in the code will try to invalidate the cache of the models
doing something like `env['ir.qweb'].clear_caches()` but it is
finally equivalent to `env.registry.clear_cache()`, and cross worker.
The idea is to have multiple cache, maybe with specific sizes for a
specific purpose.
Having one per model is maybe a bad idea because it will be difficult
to size the LRU correcly, and it is too dynamic. Checking invalidation
may be expensive.
The proposed solution is closed allow a limited number of named caches,
using onse sequence per cache. This is actually close to the
cache_longterm.
We want to discourage using a specific cache for one use case in
the buisness code. Adding a cache shouldn't be something easy, doable
in stable.
Note that we could also change the invalisation mecanism using an
insert only table. We an check the sequence of this table, but also
fetch all invalidation messages.
Another possible improvement, especially if we have more than x cache is
to have a global sequence, checking signaling would mean to check the
main sequence, and only the other ones if the main one changed.
Note that this poc is inspired from the long term cache but not all
use case where applie yet.
Part-of: odoo/odoo#119813
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>
Romain Derie