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>
This commit fixes the 'og:site_name' metadata, which previously
defaulted to the company name (see [1]), causing issues for multi-site
setups. Now, the metadata actually uses the site name.
Steps to reproduce:
- Navigate to any page
- Right-click and select "View Page Source"
- In the <head> section, observe the meta property "og:site_name" set to
"MyCompany".
[1]: https://github.com/odoo/odoo/commit/156955de6b4e6288ac606d29b843081842154eff
opw-3791082
closesodoo/odoo#161123
X-original-commit: 24ea3ca4b12f8dd4103a650436a144e776b81d83
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>
Purpose
=======
Lots of tickets (e.g. 3775298) are created because the default menu has been deleted,
leading to the impossibility to install a new module, as the parent_id
for new menus like /shop or /event are directly referencing the
website.main_menu record, or to the impossibility to create a new
website.
Task-3802440
closesodoo/odoo#158879
X-original-commit: adb1dcfd0a150ab4706a09a29ae8921fb94fa463
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The attribute cache is mainly used from the Environment class. The
ormcache attribute using the same name leads to confusion.
Related task:
task-3818968
closesodoo/odoo#155264
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
[This other commit] introduced a method to serve Google fonts from the
local server. Then it has been back-ported to previous versions with
[this commit].
Unfortunately, the font was not identical when the user chose to load
the font from Google servers versus from the local server. This
discrepancy was due to a missing parameter when downloading the font
file to serve it from the local server. This commit fixes the issue by
adding the missing parameter.
Steps to reproduce the issue fixed by this commit:
- Drop a text block onto a website page.
- Make the text bold.
- Go to the theme tab.
- Change the font to https://fonts.google.com/specimen/Poppins
=> The text style changes depending on whether you checked the "Serve
font from Google servers" option or not.
[This other commit]: https://github.com/odoo/odoo/commit/b06ce21eba6388ce34bbffffadcb489f0e8557dd
[this commit]: https://github.com/odoo/odoo/commit/04ab4e255b7fef1608ee2c70a3a005f3064bc4f3
opw-3775683
closesodoo/odoo#157800
X-original-commit: be2d27e69d7928a46d49a7ef0a3c4b93932a36b8
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 prohibits the archival of a company if it is associated with
a website. Otherwise, the website wouldn't be accessible anymore by
public users (and so by all users if they need to login).
Step to reproduce:
- On website 2, change the company from SF to Chicago
- In the website list view (in debug mode), reorder the websites so
website 2 is the first one in the tree view
- Archive the Chicago company (from debug > companies and do it from the
list view)
- Try to access the website/runbot from an incognito tab
- It will show a raw 403 error
Note that the companies can only be archives since Odoo 16, thanks to
this commit: https://github.com/odoo/odoo/commit/7d0996bb151f68647b22719eee5ed4a4c35574bb
opw-3749772
closesodoo/odoo#156988
X-original-commit: d7456bf5376cf53670dbe8eaf1a2281aa254d521
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When QWeb templates became cached and compiled in [1], the list of
default cache key elements did not contain `inherit_branding_auto`
(but it included the old `inherit_branding`).
Because of this the cache was shared between restricted editors and
public users, which could lead to problems such as missing the branding
on edited fields.
Steps to reproduce:
- Use a single browser instance and do not log any user out.
- Start with `website_sale`.
- Make "demo" user a restricted editor and a sales administrator.
- Connect on 127.0.0.1 as "demo" and go to a product website page.
- Go to 127.0.0.2 as a visitor and go to the same product page.
=> The product name field of the visitor page was branded.
If you swap the last two steps, the "demo" user's page lacks the
branding.
[1]: https://github.com/odoo/odoo/commit/7ede9bcb2de9d52994b3a6fcb84edc3f81d60284
task-3482439
closesodoo/odoo#156146
X-original-commit: 821888023db462d522c5d6de84fcab80a81c2713
Signed-off-by: Romain Derie (rde) <rde@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>
In b69917e[1] the cron implementation was changed to unlink old visitors in
batches of 1000 records. This was meant to deal with memory/timeout
errors when dealing with large amounts of records.
However it still searches for records with no limit, which in high
record count scenarios and based on instance resources may still
generate memory/timeout errors.
Technically it could be considered "fine" for the cron to timeout since
every batch is committed, so previously unlinked records are not rolled
back and the cron should eventually delete them all.
However there are some edge cases where memory/time out errors would not
be fine, like the cron failing during the first batch, which means no
unlink operations would be committed to the database.
Errors that are "fine" also generate noise and leave administrators
wondering which errors they should ignore and which they should not. It
also alarms non-technical customers since after all, they are seeing
a reported error.
Therefore the search limit and batch size have been added as arguments
to the cron. This is completely opt-in since they have the previous
values as their defaults. This makes it easy to customize and tune the
performance of the job accordingly if required.
[1] https://github.com/odoo/odoo/commit/b69917ec0e508f8354d831525c5c48ee79b5967a
X-original-commit: e8a4b1f6a239753f66aa827e8e0d67ca4270dba3
Part-of: odoo/odoo#153707
Google has removed the feature that allowed sitemap submissions. Now,
it's standard practice for Google to crawl the /sitemap.xml. This commit
permits to show a notification message when the user clicks on the
button to submit a sitemap.
task-3323849
closesodoo/odoo#152700
X-original-commit: fb842f682bb8b2600d861a5e0bb92503857bd2de
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>
Issue:
Possible to reproduce in 17.0: when adding a new field to the website
form of the "Extra Info" page in the eCommerce, a traceback is raised
(`OwlError: Missing template: "website.form_field_json"`) when the user
selects "Delivery Point Address" (`sale.order.access_point_address`).
Explanation:
JSON fields (which exist since [1]) are not supported as selectable
types in website forms, and they should not be because customers would
not be able to properly fill them out.
Fix:
Filter out all JSON fields from the list of authorized fields in website
forms; they will not appear in the list of selectable types anymore.
[1]: https://github.com/odoo/odoo/commit/7eeba9d205d2dace571b5d0895ddba6290a512db
opw-3596713
closesodoo/odoo#152545
X-original-commit: 28c3eb5878ad6f3d40a096803f3ba4aef5ef7937
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <anv@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>
*: theme_default
Since [1] when installing a theme from the Website builder's Themes tab,
if that theme used other snippets than the default ones in their
configurator pages which were inherited, the import of the theme failed
because the primary template was not generated before the import of the
data files.
This commit relies on each theme calling
`_generate_primary_snippet_templates` before declaring templates that
require them.
In master, the early loading is removed altogether.
See the changes in `theme_default` for the approach that was adopted
through all themes.
Steps to reproduce in master:
- Start odoo-bin with `-i website`.
- Edit home page.
- Go to the "Theme" tab.
- Click on "Switch Theme".
- Pick "CORPORATE / Buzzy".
=> Fails because the `website.configurator_s_banner` template is not
defined.
[1]: https://github.com/odoo/odoo/commit/cfed4e391d11058b1b46417f0b630cdbc4070d7c
task-3670496
closesodoo/odoo#148443
Related: odoo/design-themes#755
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit is fixing a last minute error in commit [1] after a push
force which move its code above the existing line `vals['url'] = url`.
After the code move, `vals['url']` was not the updated url value (which
went through slugify and unique path functions).
- Create a /test page, publish it.
- Set /test as homepage url directly on the website (in the settings)
- Go to that page
- Open the page properties and change its URL from /test to /test_un
-> The page url is /test-un but the website homepage_url is still
/test_un (not slugified) in the website settings
[1]: https://github.com/odoo/odoo/commit/374a1b31f70a3209b1ae11db8e5886350579c7f9closesodoo/odoo#147641
X-original-commit: 3c8a58b654418fc2fc0dc9bc28420c7dcb1bafee
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
- Create a "/test" page, publish it
- Set "/test" as homepage url directly on the website (in the settings)
- Go to that page
- Open the page properties and change its URL from /test to /else
From there, the website setting (`homepage_url` field) was still set to
/test and not /else.
It means that the first "published" menu would then be used to avoid
serving a 404 as homepage to your visitors.
It is a bit confusing and people probably just expect to change that
website setting too when changing the page URL.
We had some feedback about similar flows (that couldn't be reproduced or
where people weren't sure) where people ended up writting on the wrong
page or losing their content.
Maybe this will mitigate the issue.
Kind of related: task-3476840
closesodoo/odoo#147086
X-original-commit: 374a1b31f70a3209b1ae11db8e5886350579c7f9
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Commit [1] removed the `email_from` field from the `project.task` model
but forgot to adapt/delete some field occurences.
One of those is related to the form in the website builder which allows
to create task when the form is sent.
Two errors were detected:
- Non critical:
The field is still passed to the form field whitelisting process.
Since the whitelisting is done in raw SQL, it didn't crash or log
anything even if the column did not exist anymore.
- Critical:
The field was still marked as model required in the form JS registry,
altering the form builder behaviors.
One of those is that when the form input related to this field was
re-created (eg when changing / hovering an option in the right panel),
it would lose it's "name" attribute.
Two possible issues from that point:
1. When a visitor submit the form, the "email_from" field value is not
set anymore in the task description and that information is just
lost. You then have no way to reach back to him.
2. (Minor) The auto-fill behavior of the form was not working anymore
Probably more issues were introduced but only those ones got detected as
of today.
Step to reproduce:
- Drop a website form, choose "Create a Task"
- Focus the default "Email" field
- Hover the mouse on the "eye" icon ("Invisible") next to the Position
attribute. If you inspect the DOM, the input has now lost the `name`
attribute.
- If you save, you will face the issues reported above.
- If you then reopen the editor and focus the email field again, the
tooltip will now say that the "null" field is required.
[1]: https://github.com/odoo/odoo/commit/a424cf481c676a230beeb6102fc67bedf472a882
opw-3626573
closesodoo/odoo#146170
X-original-commit: 6679fddbcaf7d9146ab242e0eed61ee0628f047f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
During upgrades, customization modules are defined in the database but
their codebase is not in the addons path.
Because of this, when running an upgrade the manifest of such modules
does not exist which makes `_generate_primary_snippet_templates` fail
because it cannot locate some default keys.
This commit adapts the access to the manifest in order to use a default
value in case the manifest is not available.
closesodoo/odoo#144222
Related: odoo/design-themes#751
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
If the first theme that generates configurator templates has the same
block used several times within a single page, a unique constraint is
violated because it tries to create several identical
`configurator_<pagename>_<s_snippet_name>` templates.
This commit avoids this by only considering unique snippet names.
The issue typically appears with `s_title` on `theme_monglia` and
`theme_real_estate` if they are installed by themselves.
Part-of: odoo/odoo#144222
When shapes were extracted to configurator snippets in [1], some
configurator-specific snippets were created that do not appear on pages
of the specific theme.
Because in [2] the call to `_generate_primary_snippet_templates` is done
on a full list of themes instead of only the installed ones, the problem
was not noticed: if any theme defines a block, it's website-side
configurator-specific template is generated.
This is not the case during an upgrade: the templates are generated only
for the installed themes. Because of this some "useless" configurator
templates trigger an error when importing their XML definition because
their parent template does not exist.
This is fixed in design-themes by adding those templates in a pseudo
page `_` in the `configurator_snippets` entry of each theme's manifest.
This commit makes sure to not consider that `_` page name as an actual
page name.
In master, the templates will be removed instead.
[1]: https://github.com/odoo/design-themes/commit/d206c119720d557c11320ebb3d7339890b8f9efa
[2]: https://github.com/odoo/odoo/commit/928eeca714a161f6bc03343e4dc8af9b050b9841#diff-f49a1e9eda23df9f1d48121ba376a5fabafe70ea18b29d4eab23d737e5d4eeb6R446
Part-of: odoo/odoo#144222
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>
The "reset password" feature does not take into account
multi-website.
steps to reproduce:
- create a website A
- uncheck 'Shared Customer Accounts' on website A
- create a portal user user@example.com on website A
- create a website B
- uncheck 'Shared Customer Accounts' on website B
- create a portal user user@example.com on website B
- reset password for user@example.com on any website
before this commit:
An error is raised "No account found for this login"
(which is false, actually 2 accounts are found)
after this commit:
Only the user linked to the current website is properly
selected
opw-3551540
closesodoo/odoo#142110
X-original-commit: a2196253d6cf90dca3042a777703e0679f74f542
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [1] when the generation of missing configurator templates and new
page templates was introduced, `_load_xmlid` was called for every
generated record so that `_process_end` does not delete them after a
module update.
Unfortunately, this trick does not work when using the "Upgrade" command
on the Website app in the Apps view. (or calling
```py
env['ir.module.module'].search([
('name', '=', 'website')
]).button_immediate_upgrade()`
```
from the shell): in that case, the `self.pool` onto which the xmlids
were registered was a different instance from the one accessed by
`_process_end`.
This commit avoids this problem by making the generated templates
`noupdate: True`, thus preventing `_process_end` from deleting them.
Steps to reproduce:
- Install website with -i
- Go to Apps, search Website, upgrade Website
=> In the logs you can see that some templates are deleted at the end of
the upgrade
- Website configurator: a business website, furniture store, get leads,
choose a palette, about us + services + pricing + privacy policy,
choose the center template (loftspace)
=> You see some crash in the logs
[1]: https://github.com/odoo/odoo/commit/a2f8e18b76e52e1a349b77691d0af18edc09a1beclosesodoo/odoo#140986
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>
Currently creating a record with 'is_published' being False (aka not published)
crashes when people can't publish. However 'is_published' being False is the
default value, and create should work in both cases.
It now correctly checks that published records could effectively be published.
This allows to remove a small workaround done in eLearning.
See odoo/odoo@4086f344d8 for ref.
Only failing use case would be having
def _default_is_published(self):
return True
def _compute_can_publish(self):
for record in self:
record.can_publish = self.env.user.has_group('something')
But this would not be a really valid use case: not being able to publish
but having default publish to True makes no sense: what matters is publishing
records as it gives more visibility to records, not the flag change itself.
Followup of odoo/odoo#70291
Task-3299702
closesodoo/odoo#137900
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Previously proposed formating was trying to normalize extra in one part
of the path. This means that no extra needed a placeholder.
The implementation was meant to be more generic and extendible since a
part of the logic has to be in website.
A suggestion was made to make it more restricted but explicite by
keeping the url simple in web/controllers/binary.py but adding a
controller in website to add this extra part.
The base extra direction is now in the extension, as the min part.
Initial urls:
/web/assets/{unique}/[{website_id}/][rtl/]{bundle_name}[.min].{extension}
New urls:
/web/assets/[{website_id}]/{unique}/{bundle_name}[.rtl][.min].{extension}
Managed by two routes:
/web/assets/<string:unique>/<string:filename>
/web/assets/<int:website_id>/<string:unique>/<string:filename>
Where filename is in the format {bundle_name}[.rtl][.min].{extension}
Multiple possibilities where proposed
- /web/assets/website/<int:website_id>/<string:unique>/<string:filename>
More explicit but prefixing by /website was considered
- /website/assets/<int:website_id>/<string:unique>/<string:filename>
This one is a litle painfull to match similar attachement, where
website is ignored.
- /website/<int:website_id>/assets/<string:unique>/<string:filename>
Almost accepted but subjective, and anyway two previous solution breaks
the cdn mecanism and would need a migration
- /web/assets/<int:website_id>/<string:unique>/<string:filename>
Almost accepted but subjective, and anyway two previous solution breaks
the cdn mecanism and would need a migration
This last solution was not ideal to match without unique
/web/assets/%/<string:filename> can match both
/web/assets/123456/<string:filename>
and
/web/assets/1/123456/<string:filename>
Anyway, matching without unique shouldn't be supported for al (even if
it is kind of supported with any right now) but it will work by changing
unique wildcard to a more specific one (_ * 7)
closesodoo/odoo#131353
Related: odoo/enterprise#47313
Related: odoo/design-themes#730
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The generation inside the rendering has some drawbacks:
- `commit_assetsbundle` is needed for reports rendering because the
template rendering may generate some assets that will be accessed by
another transaction before the transaction is committed. But this
solution is not ideal since the transaction is committed in the middle
of the request
- when the first rendered page is a 404, the assets are not committed
and the page is broken.
- when starting, deleting an attachment can create a concurrent update
error and the request is retried. This will occur once per attachment
and for all worker trying to access the same resource. The whole
transaction is rollbacked, even the previously created assets bundle.
- The cold page load is a slower since there is more work to do.
- Implementing a readonly request is difficult because it could be
transformed to read write and re-executed if the assets bundle does not
exist.
Generating assets when needed solves those issues. The concurrency
when deleting an assets could still occur but only once per bundle, and
in a smaller transaction. This could be solved with a lock now that we
have more control on the transaction. The commit_assetsbundle can be
removed and 404 page should have a correct layout. The cold page load
could be a little faster because the assets bundle can be generated in
parallel requests instead of sequentially when rendering the page.
Part-of: odoo/odoo#131353
The main motivation is to be able to generate assets bundle outside
the t-call-assets call.
The need of an id in the url makes it mandatory to have an attachment
when adding the url in the page. Without this restriction, we can guess
the url without generating the assets.
This can also have other useful side effect:
There are corner case when a worked could have an invalid url in
cache because, if the transaction is rollbacked or if another request
generates the same attachment at the same time. This should be
partially solved by removing the id: The url remains valid even if the
attachment does not exist.
Note that the extra part of the url was made explicit, always there and
taking one / to remove complexity and ambiguity.
Note that an additional query appeared in .test_50_perf_sql_web_assets
because of the search, this but two of them were in _find_record. One of
them was an `exist`, not making much sense since we are not getting the
id from the attachment url anymore but from a search, and the other one
was prefetch of the "public field" since the call to _find_record does
not go in other cases (xmlid, website published, access token, ....). A
attachment of a asset is always public, and this part of the security
was moved to the search domain. The final result is one less query:
- one query to search
- one query to read the fields (_get_stream_from) (the prefetch could
actually be set to avoid prefetching everything)
Part-of: odoo/odoo#131353
This commit implements a way to expose any model publicly on the website. Both manual and
existing models can create such pages called 'Model Pages'.
A manual model is a model that has been created by the user at runtime, via the technical menu,
via studio, or with an xml declaration.
The main interface to easily create such page is in Studio, in the tab Website Integration. But a
partner or developer could easily import those without studio installed. That's the reason most of
the code to handle the display of such pages is present in the website module directly.
The listing can handle two display modes (Grid or List). Once the user changes the display mode,
the latest value is set in the session to be remembered for the next visit of the page.
A default_layout can be set and is customizable in the website editor or from the backend of Website.
This value is linked to the page to display, so each listing page can use a different layout by default.
The route on which the models are exposed is:
"/model/<string:page_name_slugified>",
With the derived routes:
"/model/<string:page_name_slugified>/page/<int:page_number>",
"/model/<string:page_name_slugified>/<string:record_slug>"
task-id-3231144
Part-of: odoo/odoo#130544
Co-authored-by: Florent Dardenne (dafl) <dafl@odoo.com>
Co-authored-by: Luca Vitali (luvi) <luvi@odoo.com>
This commits add a signature to the website_form.
The purpose of this modification is to allow the controllers to be
able to verify that the form was originally generated from the view.
This prevent the end user to submit arbitrary values to the website_form
controller.
In this commit, email_cc and email_bcc are treated as the same fied as
it holds the same function
This does not offer protection against submission replay. Previous versions
of the form are not invalidated by editing the view.
If one need to completely reset that protection and invalidate the
previously generated website_form, the only solution is currently to
change the database secret.
closesodoo/odoo#139701
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
*: website_sale, website_sale_wishlist
This commit removes the following templates:
- template_header_image
- template_header_hamburger_full
- template_header_magazine
New templates were added by previous commits. Those old 3 do not have
an equivalent anymore and are simply removed.
task-3060986
Part-of: odoo/odoo#119650
*: website_sale, website_sale_wishlist
The new header is quite different from the old one, the xml_id of
the header will thus change. That new "sales_three" header will however
be the closest one to the "contact". A related upgrade script will be
made to treat this as a simple xml_id renaming.
task-3060986
Part-of: odoo/odoo#119650
*: website_sale, website_sale_wishlist
The new header is quite different from the old one, the xml_id of
the header will thus change. That new "sales_two" header will however be
the closest one to the "slogan". A related upgrade script will be made
to treat this as a simple xml_id renaming.
task-3060986
Part-of: odoo/odoo#119650
Romain Derie