Before this commit, user would be redirect to / instead of /my after signup.
That error was detected with task-1829827 which has a tour ensuring user is
correctly redirected to /my after signup on the checkout summary after payment.
Since 0229ef4c4a, the `web_login()` super call order has been changed when
called from the `/web/signup` route.
See the commit for more details but basically, before the fix, it went only
through:
1. web.web_login
2. portal._login_redirect
Where now, it goes through:
1. website.web_login
2. auth_signup.web_login
3. web.web_login
4.portal._login_redirect
Thus, portal._login_redirect is not returning `/my` as redirect anymore.
Indeed, website.web_login will ignore its super() and force redirect to `/`
With this commit, website's user are redirected to /my as expected.
Side effect: website's user will also be redirected to /my on login instead of
`/`, which is also prefered.
closesodoo/odoo#33865
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, aboutus contactus and homepage would be flag as noupdate.
If not modified, those view would not get modification on module update, which
is not logic.
Now, those view will benefit from any update. It makes even more sense since
multi-website, as those views will never get modified directly (it will COW).
closesodoo/odoo#33919
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
On a eCommerce page were there was no SEO optimization change:
- Customize > Activate "eCommerce categories"
- Customize > Activate "Colapsible category list"
- Promote > Optimize SEO > Change description > Save
Nothing happens.
Actually, an SQL error is raised because of the `ondelete='restrict'`
set at:
https://github.com/odoo/odoo/blob/897feb553e6ef75af9434cb77436b26abde3a761/odoo/addons/base/models/ir_ui_view.py#L212
In this case, we have the following structure:
```
View 1
|
---> View 2 (Website-specific)
|
---> View 3 (Website-specific)
```
For example:
```
Products
|
---> eCommerce Categories (Website-specific)
|
---> Collapsible Category List (Website-specific)
```
Since the inherited view (View 2) is website-specific, we duplicate it
and try to unlink it. However, this view has children, which raises the
error.
To solve the issue, we re-attach the children of the inherited view to
its copy. In a realistic situation, the children of a website-specific
view should also be website-specific, so there is no need to apply the
'copy or re-attach' logic recursively.
We end up with:
```
View 1 (Website-specific, duplicated)
|
---> View 2 (Website-specific, duplicated)
|
---> View 3 (Website-specific)
```
opw-1997946
closesodoo/odoo#33787
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When opening the pdf at the end of an order Chrome tries to load
/favicon.ico which returns 404 before this patch. We provide the
favicon from the current website.
closesodoo/odoo#33746
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
If destroy is called before start, there will be a crash before this commit.
At the time of this commit, this can be reproduced in master by dropping the
image gallery snippet, clicking on add images (double click, which opens the
media dialog twice for some reason), selecting 2 images to add on the
media dialog, and clicking on add. The error will be in the JS console.
closesodoo/odoo#33440
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the object used by Optimize SEO 'wizard' was always the
main object, without any possibility to change that (except by changing the
main object but that would cause a lot of other issue, eg edit in backend).
This commit add the possibility to explicitly set a seo object on the html data
attribute.
If set, this one will be used instead of the main object.
This is useful for event.event where all the event pages (with website menu
enabled) would share the same SEO since the main object would be the
event.event.
With this commit, the seo object is now the website.page, thus giving the
possibility to have a separate SEO for every event pages.
(Required for Odoo.com website for OXP)
closesodoo/odoo#33194
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Facebook API does not accept float values for height and width
parameters anymore.
closesodoo/odoo#32970
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The rte_translator tour that test translation on the frontend could not
be started from the "[debug menu]" > "Start Tour" for two reasons:
- the start URL is not specified, so the test was started on current
backend page wich is wrong (in python the start url is "/")
- the backend original state (params after #) does not work with ?k=v
inside argument value, so `#return_url=/?debug=true`.
To solve this issue, we encode the return_url value and add a start url
when rte_translator is started manually.
opw-1998623
closes#33443
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- Create 2 companies A & B
- For each company, create a website linked to a different URL and
activate 'Free sign up' and 'Specific User Account'.
- As a public user, go to website of company B
- Go to 'Sign in > Don't have an account?' and create an account
The user is created in company A (the company of the user template)
instead of company B (the company of the website).
We set the company of the user based on the company of the website.
opw-1962197
closesodoo/odoo#32823
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The UTM graph data in Website > Dasboard > Analytics is not getting
properly filtered on the basis of values of date_from and date_to on
website_sale dashboard.
The field confirmation date which is of type datetime while date_from
and date_to are of date string in local browser timezone.
Hence date_domain is not perfect as shown below on local date 29th april
2019, we would send:
('confirmation_date', '>=', '2019-04-22'),
('confirmation_date', '<=', '2019-04-29')
But in reality we could want a from midnight of week before the current
UTC day, and to current UTC now or 23:59:59 of current UTC day.
This way, the data sent back matches more what is expected, instead of
the preceding domain, we would then have the following:
- if UTC now corresponding to local now is on '2019-04-29'
('confirmation_date', '>=', '2019-04-22 00:00:00'),
('confirmation_date', '<=', '2019-04-29 23:59:59')
- if UTC now corresponding to local now is on '2019-04-28':
('confirmation_date', '>=', '2019-04-21 00:00:00'),
('confirmation_date', '<=', '2019-04-28 23:59:59')
- if UTC now corresponding to local now is on '2019-04-30':
('confirmation_date', '>=', '2019-04-23 00:00:00'),
('confirmation_date', '<=', '2019-04-30 23:59:59')
And each one will be displayed as days 22 up to 29 in line chart (with
local today 29 being the last day of the chart and contening orders of
the current UTC day).
With these change in the UTM pie chart:
- a local date that is before a UTC date => we see the sales from up to
today UTC instead of from up to before yesterday UTC
- a local date that is the same as an UTC date => we see the sale from
up to today UTC instead of yesterday UTC
And in the line chart (that already had half of the fix in f6fc7c2319):
- a local date that is before a UTC date => we see the sales from up to
today UTC instead of from up to yesterday UTC
- a local date that is after a UTC date => we see the sales of current
UTC day + range of days (eg. for a week 7) instead of current UTC day +
range of days minus 1 (eg. for a week 6).
opw-1971539
closes#33041
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Nicolas Lempereur <nle-odoo@users.noreply.github.com>
The basic font-family offered on Odoo do not support a large set of characters
and rely on the system fonts for non-latin languages
On a system without specific fonts installed, the characters were replaced by �
For Hebrew, the system sans-serif font (at least on Windows pc) was too small.
Rely on the unicode-range range CSS descriptor to load a font only for a
specific range of unicode code.
https://developer.mozilla.org/en-US/docs/Web/CSS/%40font-face/unicode-range
This way, the fonts are ignored for English text (and you don't have to load
the fonts of every possible language).
Add Noto fonts that covers many charsets.
There is an heavy version for many charset and lighter ones for Arabic and Hebrew
More ranges can be added later
Serve the fonts on our CDN to avoid shipping several MB of fonts for everyone
but lazyload it when needed.
Fixesodoo/odoo#32228Fixesodoo/odoo#21781
Example where the issue occurs:
- Publish an event
- Go to the website, register for that event
- At confirmation, when the email address is requested, click quickly
several times on the 'Continue' button
Several registrations are created since nothing prevents multi-clicks.
The stateful button feature of the `button.js` jQuery plugin has been
dropped in Bootstrap 4 (see [1]).
[1] https://getbootstrap.com/docs/4.1/migration/#buttons
opw-1958580
closesodoo/odoo#32571
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Since b5a12b4aac the website_id was not set anymore.
Indeed, before this commit website_id was the field from the inherits, thus
when writing on website_id from res.user, we would write on the partner field.
But with b5a12b4aac the website_id was explicitely overrided on res.users as a
related to res.partner (its inherits) with readonly=True.
Thus, writting website_id on res.users was not working anymore.
closesodoo/odoo#33521
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Christophe Simonis