Reproduction:
1. Install Event, Sales, Webiste
2. Login as Admin, go to Website -> Go to website -> Events
3. Click the Open wood event, Register, buy one VIP ticket
4. In Address step, Edit the billing address, change the name to “Test
Name”, click next
5. The user name “Mitchell Admin” is changed to “Test Name”, we
shouldn’t be able to change the info
Reason: In the fix to block name change here: https://github.com/odoo/odoo/commit/d823033ad67702b1b92d27a3f66c7a4ec304c644
we use the can_edit_vat to check if we have existing invoice(s) or
SO(s). However, we should block the route that an employee changes the
billing address when placing an order. If they are placing an order for
external people, it should be done from the back end.
Fix: add an extra error case when it's an employee trying to change the
name or email address when editing billing address. This is the case
when an employee tries to order for external people. They should do it
from the back end. They can still buy for themselves without changing
the billing address. Also added translation in pot. Edited the test for
editing address of log in user, added tests for portal user. Reformat
the invoice exsits check for name change to have better readability
The adding of can_edit_vat:
https://github.com/odoo/odoo/commit/f8b05f52f5ea7f31135f700b0e240ff563204085
Related fix to block the name change:
https://github.com/odoo/odoo/commit/d823033ad67702b1b92d27a3f66c7a4ec304c644
A patch to not block the checkout process when name is not set:
https://github.com/odoo/odoo/commit/781dbeaccac76a6ec4f4b8cac1b607810697e394
opw-3126325
closesodoo/odoo#126261
X-original-commit: 972c55bf76f4c5f1b1bedec4a77ddaeac8be1483
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Jinjiu Liu (jili) <jili@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
Co-authored-by: Antoine Vandevenne (anv) <anv@odoo.com>
Maxmind offers multiple ip-geolocalization databases, historically we
have been using the City database which contains records on a
city-basis. Many years later it turns out we are primary using geoip to
know the country of the user. Geolocalization in the City database is
considered slow by our standard and we have been clever in order not to
geolocate each request by saving the info in the session.
On the other hand, the Country database that is offered by Maxmind is
much more lightweight and geoip using that country is considered a fast
operation by our standard.
In this work we make Odoo compatible with both the City and the Country
databases. Using multiple database at the same time, we can be smart and
only query each of the two on-demand. If a user ask for its country,
we'll use the fast Country db. If a user ask for its city/timezone we'll
use the slower City db.
By default it loads both database from the `/usr/share/GeoIP/` folder,
respectively the files `GeoLite2-City.mmdb` and `GeoLite2-Country.mmdb`,
you can provide alternative paths using the `--geoip-city-db` and
`--geoip-country-db` CLI options.
In the same mindset as #86015, geoip is still lazy. It is done on-demand
and the result is cached on the current request. The different with the
related PR is that as we know consider geoip to be fast, we no longer
cache the result in the session.
Task: 2848206
Part-of: odoo/odoo#91337
This commit avoid to have a dict by reference that will be global.
Now get_default_session return a new dict each time for the context key.
From this way the session.context['lang'] is not shared between several
users on the same worker.
To reproduce the bug, restart the server with 2 workers, make request in
lang A on these 2 workers. DEFAULT_SESSION['context']['lang'] now is set
to this lang A.
Now, make request to an url without lang in path and without cookies and
withtout session, you should be redirected to lang B (preferred lang
from the request header) but you will be redirect to lang A due to the
dict session.context that is shared for the worker...
When we initialize the new Session, we get the wrong lang A as value for
context.lang, so we don't recompute the expected lang for the end user.
X-original-commit: 62179de74862210fe2a055d15b367b1850c24263
fwd-port of #100102closesodoo/odoo#100910
X-original-commit: 42e46b2d89dde276f796b980f29e33cc216e7cb2
Signed-off-by: Jérémy Kersten <jke@odoo.com>
The history of this one is kind of tricky, to say the least.
A fix in the theme install process was done in 14.0 with [1].
It came with a `standalone` test in the `design-themes` with [2].
It had to be a `standalone` test since it is playing with module
operation, which is forbidden in the regular testing suite (sadly).
Since this new test was the first `standalone` test in the
`design-themes` repository, it actually wasn't even properly tested for
months before we realized it. It was missing some runbot configuration
in the nightly build to include the `design-themes` repository in the
standalone testing suite.
Once the runbot configuration was correctly fixed, the test wasn't
working anymore in 15.3 and later version because of some change in the
httpocalypse [3] which made the `MockRequest` not behaving as expected.
Indeed, with [3] the request's context had to be updated through
`update_context` which wasn't adapted/working with `MockRequest`.
Then, since [1] (merged in 14.0) was ported in saas-15.3 at [4] (where
[3] also exists) it was the first time a test using `MockRequest` was
ending up calling business code doing a request's context change.
The business code doing `update_context` and called through the test in
`MockRequest` was then not doing anything and not changing the
`context`. The test was then failing despite the behavior/normal code
base working properly.
This commit makes the request's context change working with
`MockRequest`.
Some people think `MockRequest` should disappear, but right now that's
how it is, we are still using it as this is really useful to be able to
test business code in a frontend context without going through a tour.
For what it's worth, multiple time the community asked us to move it
outside the website module, but also multiple other internal team in
odoo. So, while it might be better or not correct in some cases (mainly
python super), the tool is useful.
[1]: https://github.com/odoo/odoo/commit/b8a24efa71daea1f96465b780f4f0e384ce74703
[2]: https://github.com/odoo/design-themes/commit/4de16d85b7f7d69212576eede82e8a15190d357b
[3]: https://github.com/odoo/odoo/commit/f61aa39ff1190f66cebb8efb8432723214932161
[4]: https://github.com/odoo/odoo/commit/14387f36438b731753e2e7169f54865b123cdcfaclosesodoo/odoo#100070
X-original-commit: 885ce02a15dc093ff98822f80b22c4415fa9cceb
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Just a nice to have. It will prevent those errors to be replicated when
copy pasted and will help reading the files in the IDE.
closesodoo/odoo#97282
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
* im_livechat, test_event_full, website_blog, website_crm,
website_event, website_event_track, website_event_track_quiz,
webite_livechat, website_sale
There is 6 main changes in this commit:
1. Using raw SQL Upsert instead of the ORM methods. While raw SQL should
generally be avoided, it makes sense for such a low level behavior which
is impacting every flows.
Indeed, tracking visitors is a generic behavior done on all pages and
controllers. It is important to optimize it to reduce processing time
and SQL Queries.
Benchmark of that change alone:
> Rendering a tracked page improves from ~19.5ms to ~17ms (using `ab`
with 1000 loop) and the requests involved in the tracking process are
reduced from 8 SQL Queries to 3:
- 1 request to upsert the visitor
- 1 request to fetch the visitor data
- 1 request to add the tracking record
2. Adding in that upsert query the `visitor.track` insert, creating both
records in one go, bringing the query count from 3 to 2.
3. Refactoring of the `parent_id` behavior that was introduced in stable
with [1]. The purpose was to keep track of multiple visitor linked to a
same user to merge the tracking together. Especially useful for tracking
a same visitor on different devices (when logged in).
Only one visitor was kept as active, others would be archived and their
tracks would be set/moved to the main partner.
Removing those duplicate visitor was not possible because those archived
duplicated visitor were holding the devices notification push token.
Since [2], those token were moved to their own table, all related to the
main visitor.
We can then now safely remove those duplicate visitors after merging
their track to the main visitor. Thus, the `parent_id` field is no more
useful. Removing it removes a layer of complexity.
Note that thanks to this part, the `active` field can also be removed.
4. Deeper functionnal change, inspired from Plausible: The access_token
is no more stored in a cookie but is the result of a hashing method
based on <IP Adress, User Agent>.
The reason behind that change is that, in an upcoming refactoring,
sessions won't be stored anymore unless absolutely needed (login, add to
cart..). It will also ship a no cookies policy, trying to get rid of all
cookies.
This change is bringing some functional changes:
- Since the IP is included in the hash to generate the token, it means
that:
A. If an anonymous user switch IP (eg from 4G to wifi), it is
considered as a new visitor.
B. If 2 anonymous users with the exact same user agent (same browser,
same browser version, same exact os or phone) are on the same IP,
those will be considered as the same visitor.
- Since the request host is not included in the hash, it means that
visiting a DB from 2 differents URLs (domain and/or ip) on the same
device and same browser will result in a shared visitor.
It shouldn't imply any issue as this is A. not wrong and B. mostly
used for tests.
As all this is only related to non logged in user, it shouldn't be a
real issue as anonymous visitors are not supposed to be meant to be
business critical, even if we use them for "a bit more" than simple
analytics data.
5. The access_token is now replaced by the partner_id once the user logs
in, so:
- We don't need to either search on the partner_id field or the
access_token field (depending if the user is logged in or not), we can
only use the access_token row/field to do both.
- On logout, everything works out of the box as the access_token will be
regenerated since there is no partner_id anymore.
- On login, if an access_token matches the user's partner_id, that
visitor is returned.
If there is no such token, a new visitor is created for that partner_id.
In both 2 cases, tracks are moved to that visitor and the anonymous
visitor is removed.
- We can remove the code that was in charge of checking if the
access_token / visitor cookie was wrong (coming from another user eg,
different user login on same device). Indeed, such collision is not
possible anymore as the access_token automatically match the logged in
user.
- We can remove the code that was in charge of checking if the
access_token / visitor cookie was wrong (coming from a logged in user
while the current visitor is not loggedin). Such collision is not
possible anymore as the access_token is (re)generated as an anonymous
token (hash) when not logged in.
6. There is no more check to prevent a track to be created if there was
already a track for that URL in the last 30 minutes.
While this can easily be re-introduced (one CTE on the upsert), it was
adding ~100ms (from ~20 to ~110ms) to the request on a big database as
Odoo where there is ~100 millions tracks and ~100 millions visitors.
It has been validated that it was not a real issue as it is not
fundamentally wrong. If a visitor visited 20 times a product or a
specific page in that short amount of time, you might want to know that
because the user is most likely interested by it.
Changes (1+2), 3, (4+5) and 6 are all independant from each other and
could have existed on their own.
[1]: https://github.com/odoo/odoo/commit/c6b8a44b970a46dcd87a4e2cb1ad52fa340b209f
[2]: https://github.com/odoo/enterprise/pull/16781/commits/f75090fe8b42484e89e933976e8441d2f5eb9415
task-2867045
closesodoo/odoo#87857
Related: odoo/enterprise#28004
Related: odoo/upgrade#3566
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Current behavior:
When adding a "Heading" in the first 200 characters of a blog with
/Heading, the short description of the blog preview would have
unwanted stars (*) around the heading
Steps to reproduce:
- Create a blog article
- In the first 200 characters of the blog use a heading (e.g. /Heading1)
- Go back to the blog list, the description of the new article contains
unwanted stars (*)
opw-2798595
closesodoo/odoo#88352
X-original-commit: 6cb57d2f1ffb0adceaa3199cc0bf5140589d9328
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Every request comes with a session, a dictionary that is persisted on
the filesystem and that saves various information such as the user
cart on the ecommerce.
When a user simply visits the website, a default session is created and
saved on disk, this bloats the filestore with many sessions. Creating
the session on-the-fly is cheaper than loading it from the filesystem.
With this work the default session is not saved on disk anymore unless
explicitly asked via `session.touch()`.
An exception to the statement "creating the session on-the-fly is
cheaper" is geoip, the ip geolocalization is not cheap. In this work,
geoip have been moved from http_routing/request.session.geoip to a
lazy property core/request.geoip. When requested the info is persisted
on the session. Like other keys from the default session, geoip will not
be persisted unless there is non-default stuff in the session.
Because the CSRF-TOKEN is based on the session-id, it is important the
session-id stays the same across multiples requests even when the
session is not persisted on disk. Even when a session is not persisted
on disk, the session-id cookie is still set so that the next session
created on-the-fly uses the same session-id.
Technical note regarding the session, it has been decided to drop the
session-snapshot protocol and to reintroduce a "modified" flag. It has
been decided not to use werkzeug's session (which natively comes with a
"modified" flag) and to keep our own session object. We decided to
extend MutableMapping instead of dict; using MutableMapping we only
have to override __setitem__ and __detitem__; using dict we would had to
override update()/pop()/... too.
Task: 2789035
Part-of: odoo/odoo#86015
This commit is the 13th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
Here be dragons.
First and foremost, `http_routing` is a technical module that aim to
provide the minimum viable compatibility code between portal and
website. Its primary job is to take care of the lang inserted in the
path of URLs, e.g. `en` in `/en/my_blog`. Both when routing a request
with a lang in the URL and when rendering templates with multilang
support.
Next to `http_routing` is website, the module used by customers to
create pretty web page accessible online. Website uses a different
routing logic than the backend, webpages are **not** registered in the
routing map of werkzeug but instead delivered by website dedicated
code. It means that **all** request targeting a website page thrown at
the werkzeug router **fail** with a HTTP 404 error. The reality is that
website abuses the fallback mechanism (`_serve_fallback`) to deliver
its pages.
Using `_serve_fallback` as the standard way to deliver pages is broken
by design. It is the least crappy way to deliver content as long as
website page don't have a dedicated path prefix. Using a path prefix
(e.g. `p` in `/p/fr/mon_blog`) it would have been possible to route the
request to a dedicated endpoint using the same router as the backend and
with no change to the HTTP dispatching code. Sadly, the business does
not want such prefix so we have to stick with a broken design.
It is broken because prior to serving a page, website needs to setup A
LOT of stuff on the system. It needs to ensure a proper user is set on
the environment, it needs to setup the GeoIP database, it also needs
to determine the lang the user requested the page and it also needs to
save multiple attributes on the request objet itself (`is_frontend`,
`is_frontend_multilang`, `routing_iteration`, `website`, `lang`,
`rerouting` and `website_routing`). Since `base/ir.http@_match()` will
fail, everything must be set either prior to calling this method or in
`website/ir.http@_serve_fallback`.
---
The original implementation was overriding the `_dispatch` method which
was responsible to call the four `_match()`, `_authenticate()`,
`_postprocess_args` and finally `WebRequest._dispatch()`. The override
was very special, here is an attempt to explain it:
1) try to match an endpoint using the backend router, 404-errors are
ignored.
2) include the geoip stuff.
3) authenticate using the `auth` @route argument if an endpoint matched
in (1), otherwise authenticate with the public user.
4) if not endpoint matched or if a frontend endpoint matched in (1):
a) call `_add_dispatch_parameters` which sets many arguments on the
`request` object, including the lang found in the request cookies
b) try to extract a lang from the URL: abort with a redirection when
the lang is missing or wrong, remove the lang from the request
path when it is set (updating both `request.lang` and the cookie).
5) return the result of `super()._dispatch()`
Note that `_serve_fallback()` is called during `super()._dispatch()`
when the path still does not route to an endpoint. Thanks to the
`_dispatch` overrides in http_routing and website, it is garanteed that
the system is setup prior to calling `_serve_fallback`.
---
Because it is now `http.py@Request._serve_ir_http()` that is responsible
of calling the four`_match()`, `_authenticate()`, `_pre_dispatch` and
finally `_(http|json)_dispatch()` it is no more possible to override it
to take over the dispatching to perform the http_routing/website magic.
The prior implementation can not work with the new design thus is has
been refactored too.
To render a website page, there must be a user configured on the
environment (not None) and the various special attributes must be set on
the request object. The special `lang` attribute is popped from the
request path but backend endpoints must be delivered in priority.
Using the new design, it has been decided to override the `_match`
method to implement the lang-in-path logic, to override both
`_pre_dispatch` and `_serve_fallback` to call `_add_dispatch_parameters`
which have been renamed `_frontend_pre_dispatch` and to also grant the
public user in the `_serve_fallback` override.
The `_handle_error` override in website has similar needs, the function
is called upon error (4xx/5xx) in order to render a pretty
website-looking page. Because such error can occurs as early as in
`_match()` (page not found and no fallback), when nothing has been setup
yet, website is yet again responsible for setuping everything: request,
orm, frontend.
Many other small improvement are not described here. Hopefully the added
comments in the source code are enought.
PR: odoo#78857
Task: 2571224
*: web_editor, website_sale
This commit adds the abibility to get an image thumbnail based on the
video provider URL and to avoid duplicating the regexes. It also
improves those URL regexes.
All the regexes are kept in a python tools file and are called in JS
using an RPC.
task-2154812
closesodoo/odoo#44537
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: ras-odoo <ras@odoo.com>
Co-authored-by: bbh-odoo <bbh@odoo.com>
`website` added its own sql-compatible version of
`get_unaccent_wrapper` in order to use `psycopg2.sql` for safety.
That is very sad.
Add a condition in the "standard" unaccent wrapper which checks
whether the input type is a `Composable`, and in that case return an
`SQL`. This increases the cost of the wrapper a tad but probably not
to a really sensible amount.
Task 2634851
Part-of: odoo/odoo#76436
Before this commit searched terms were the ones entered by the end-user.
After this commit if the searched term is not found then the search is
performed on a resembling term.
The similarity is obtained from a Levenshtein distance combined with
ratios of common and different letters.
By default the dictionary against which the search term is matched is
based on the content of the search fields containing a word that starts
with the first letter of the search term.
If the `pg_trgm` Postgresql extension is installed the dictionary is
built from matches using the `<%%` operator (similar to the
`word_similarity` function).
Several approaches were benchmarked during development, those results
are available through the task record.
task-2379555
https://github.com/odoo/odoo/pull/65871
Part-of: odoo/odoo#65871
Coupons and promotion programs can now be shared by creating a link that can
directly be used by the customer.
Using the link, the system will try to apply the coupon/promotion to the
customer's order.
If this can't be done, the error will be shown to the user, for instance
"A minimum amount of 1000$ is required to get the free ipad".
That coupon/promotion will then be stored in session and the system will try
automatically reapply it when something is added to the cart.
task-2489749
closesodoo/odoo#69053
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
Co-authored-by: Tom De Caluwé <tdc@odoo.com>
This branch adds request.redirect on all requests.
In case of a front end request, we do an url_for to the location.
We removed redirect_with_hash that was only for retro compatibility
local_redirect has been renamed to redirect_query, and param keep_hash has been
removed and moved.
Default code for redirect is 303 now instead of 302.
Now redirect and redirect_query make local redirect by default, you need to
pass local=False to make external redirect.
All werkeug.utils.redirect has been replaced by request.redirect.
Http.redirect now use an http.Response type, and it become easy to add an
override like 'set_cookies' e.g.
Dispatch of a website.page return an http.response too, so we first need to
check if it is a cached version before to check if it is an Odoo Response.
Migrate your code:
http.redirect -> request.redirect(location, code, local)
http.local_redirect -> request.redirect_query(location, query, code, local)
http.redirect_with_hash -> request.redirect
Courtesy of odony for help and review ;)
closesodoo/odoo#72599
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The regex was updated in JS with [1] but its python counterpart was
forgotten during forward-port.
[1]: https://github.com/odoo/odoo/pull/46898closesodoo/odoo#65087
X-original-commit: 8d0b82683b95615267ff3acf84ebdd20456c595a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
We should push the request object on the request stack only in the
__enter__ method, in order to be symmetrical with the __exit__ method.
closesodoo/odoo#53613
X-original-commit: 30e94d305f9cffa816ddc213e0b9329c0263c145
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>
*= website, website_livechat, website_rating
///// Tracking Product /////
Now when a user browse products in eCommerce, we keep track of the
products he looked at. We use the website_visitor
to store the products viewed. A cookie is added with a TTl of 30 min it
will prevent the RPC for that time. We track the page only if the
product view is tracked.
The recently viewed products are displayed as a snippet but also
with the customize option in product pages of website_sale.
Products that are in cart will not be returned as recently viewed.
It is possible to add a recently viewed product to the cart directly
from the carousel, it will not redirect to the cart. If we are on the
cart page, the product is displayed in the cart.
The Visitor page in website now references products viewed
///// Tracking Page /////
Feature to track a view was remove in: https://github.com/odoo/enterprise/pull/4834
That feature is now reintroduced and will use website_track instead of
leads to be stored.
The track field is now on the view instead of the page.
url field is added to website.track, it will store the url for pages and
views
The Visitor page in website now references urls viewed
Add some tests
task-1984575
closesodoo/odoo#35810
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
With this commit it is now possible to change the lang displayed in the URL.
Eg, you could use `/fr` instead of `/fr_BE`, or even a fancier `/french`.
Task-32838
Courtesy of pla@odoo.comclosesodoo/odoo#35135
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
During checkout, the user can create a new billing (only for public user as it
will create a 'normal' `res.partner`), a new shipping, edit its billing (that
will edit himself) or edit its shipping address.
All those cases will go through the exact same methods, public user and logged
in user included.
This previously led to multiple issues and multiple fixes to correctly set
`company_id` and `website_id` on the address (res.partner).
See 44372471ef that fixed the `website_id` part.
See 3a0f05f33 that fixed the multi-company behavior, but needed 2ba71140 to not
modify the company of an already created partner, but was still incomplete as
after that fix a logged in user would still have the admin (sudo) company
instead of the website one as supposed.
This commit will fix that bug and add some tests for all mentionned issues.
Related to #28853 as we want to backport the mentionned commit but needed to be
fix first.
closesodoo/odoo#34596
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
We have multiple ways of simulating a frontend context while running python
tests (mainly during TransactionCase):
- `MockObject` class from 8557bcfa30
- `simulate_frontend_context` method from a5a5a57e48
- `DotDict` from f8efc9a957
This commit moves `MockObject` to misc to be reusable and adapt it to be
accessible by dot notation with `DotDict`.
Part of #34396
This commit adds a new file 'tools.py' that can contain
utility methods which can be used at more than one places.
For now it contains a method 'get_video_embed_url', that
will accept a URL for the video and return an iframe snippet
that can be embedded if the provided URL is valid (returns
False otherwise).
task-1945483
