* test_website
The `nocache` URL param was introduced with [1] which allows to bypass
the cache when serving a page.
Bypassing that cache, despite not being the most common flow, was done
in the perf tests since that commit. Ultimately, it was not testing
real use cases anymore (despite still being useful as it would still
prevent perf killer feature to be merged).
This commit ensures the perf tests are also tested with cache.
[1]: https://github.com/odoo/odoo/commit/cbf8d3b3047c94a2ff7fb197bbae92a402e0b58b
task-2774979
closesodoo/odoo#85261
X-original-commit: 5d44d890021cfc7767daa1f366e636288e84f1f6
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
If a picking is in a batch, the point is to process it as a whole. Yet,
it is possible to validate a single picking (putting it in a 'done'
state), inside of an 'in_progress' batch. This raises inconsistencies
between the state of the batch as a whole and the state of some of it
pickings.
Therefore, when a single batched picking is validated in a batch that
still contains other non-done pickings, the picking is removed from the
batch.
closesodoo/odoo#85324
X-original-commit: e9602d6b28331f68a83b5ce8a06a2ffc8ac3453d
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Usecase:
- Create a BoM with a product tracked by SN
- Create a MO with qty 5
- Mass produce
- Generate
-> All the `stock.move.line` in the move_raw_ids don't have
the qty done prefilled. The purpose of the feature is to create
and validate a lot of MO at once. Which is impossible if you have
to fill all the quantity manualy.
The choice of a new kwargs that directly set the qty_done is justified
by the performance.
-> For On a BoM with 10 components for a final product. For 1000 finished
product with SN
- If we do a loop on each `stock.move.line` to set
qty_done as the reserved quantity. It goes from 40s to 135s
- With the kwargs. It remaines 40s
closesodoo/odoo#83123
X-original-commit: 8ce5926b5a337dc97237f39492e094288b453743
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
In mass_mailing, the colorpicker is in an iframe. There was code to make
sure it was bound to its owner document but that code was faulty since
it was executed before the colorpicker was appended to the DOM. As a
result, all features of the colorpicker that relied on the position of
the mouse (eg, selecting a color in an xy selector by dragging a cursor)
were broken.
This fixes it by using the owner document of the parent class' editable
if defined, rather than that of the parent class' element.
task-2778415
closesodoo/odoo#85329
X-original-commit: a19d81bcab978150cf01f1ae85543adc5cb92e5e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When starting with an empty mailing, it was possible to click in the
document and start typing, while this should not be allowed since that
zone is not really editable. We want to only allow writing into
snippets.
task-2778412
closesodoo/odoo#85328
X-original-commit: c9ebe6996f61c24c2a67212beba5dcc95e9a7ed9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Currently, when event manager clicks on 'Configure Event Tickets'
link on the event registration front-end page, it redirects
manager to the form view of that event. However, the top menu items
are missing.
This commit adds the 'menu_id' in link of the button so that when
being redirected to back-end (form view), the menu items are loaded
correctly.
taskID-2727609
closesodoo/odoo#85302
X-original-commit: 851a149f69e67f2fc7cf7a14f5eb4c087897b002
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
`.modal.o_inactive_modal` (in modal.scss) had a z-index that was
superior to that of a fullscreen editor. As a result we could end up
with the editor being partially hidden by a modal.
task-2741872
closesodoo/odoo#85315
X-original-commit: 6ef3c1cf59ac66f00462468079500c449f189fae
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Whenever the user clicked on the fullscreen in mass_maliing, then
trying to show the media modal was not possible as the div that
contains it was hidden.
Task-2731907
closesodoo/odoo#85314
X-original-commit: 4026bc2075b7109dd18471aabf11ff3f76d6c57d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The commit 62ebc97bd8 introduces a bug
that makes it impossible to use the Command "Debug tools...". When this
Command is called, a crash happens.
closesodoo/odoo#85267
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In this commit we clean up the source code
by removing the PosComponents that have
only template code (.xml) but no code in
the corresponding js classes.
task-2774228
closesodoo/odoo#84317
Signed-off-by: Masereel Pierre <pim@odoo.com>
This commit is the 15th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
Enhance the new test_http module with more tests.
Pr: odoo#78857
Task: 2571224
Related: odoo/enterprise#21849
Related: odoo/design-themes#524
Signed-off-by: Julien Castiaux <juc@odoo.com>
This commit is the 14th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
* `request.uid = x` => `request.update_env(user=x)`.
* `request.context = x` => `request.update_env(context=x)`.
* `request.context = dict(request.context, x=y)`
=> `request.update_context(x=y)`.
* `request.cr = None` => `request.cr.close()`.
* `http.mono_db()` => `request.db`.
* `http.dispatch_rpc()` => `service.dispatch_rpc()`.
* `@service.model.check` => `service.model.retrying()`.
* `request.endpoint`
=> `env['ir.http']._match(request.httprequest.path)[0].endpoint`.
* `request.routing_iteration `=> `removed`.
* `request.jsonrequest` => `request.dispatcher.jsonrequest`.
Note that `request.params` is now set much later in the process. If you
are in a situation where you values from the query string or the
http body you can use `request.get_http_params()`.
Note that using the new `request.future_response`, it is possible to
add headers and cookies on the response object before the response
object is initialized. Please note that headers/cookies saved on
the future response will NOT be injected in case of error.
PR: odoo#78857
Task: 2571224
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
This commit is the 12th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
The web module is twofold, on one side there are many controllers: /,
/web, /web/login, /web/database/selector, /web/dataset/call_kw, etc, on
the other side there is `session_info`: the method responsible to create
the web client's environ.
This module is kinda an exception as it is (with base) a server wide
module. In the case of the HTTP framework, it means that the controllers
of web are always accessible, i.e. going to / or /web/login will never
return a 404 Not Found even if the user is not connected to a database.
This is both a blessing and a curse. It is a blessing because the
controllers are always accessible it means that a new users can freely
access those routes. It is a curse because *any* user can access them,
even user who don't have a session yet thus who are not connected to a
database yet. From a developer standpoint, we have to put extra care to
correct serve users with and without a database. An example is the
/web/login route, the login/password pair is stored in a database,
without database it is impossible to validate a user login but users can
still access this route without db.
To solve this problem, there is the `ensure_db` function. This function
attempts to find a database using various sources (?db= query-string,
session db, mono db) and to save it on the user session. In case no db
is found, the user is redirected to the database selector. In a way,
this function grants a database to the user in a seamingly experience.
In a way, this function brings a welcome differentiation between
`auth='none'` with a database and `auth='none'` without a database. Such
differentiation only matters for the server wide modules as "regular"
module controllers are only accessible via the ir.http routing map, i.e.
it is not possible to declare a nodb controller outside of server wide
modules.
An important changement is the `session.authenticate` method, before it
was possible to call the method when the cursor was not yet initialized,
authenticate would open a cursor against the given database, setup a
registry and an environment and ultimately save everything on the
current request. Because the cursor is now greedily created, it is no
more possible to update the request environment when authenticating on
another database.
PR: odoo#78857
Task: 2571224
This commit is the 11th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals. See also [REF] core: HTTPocalypse (9) ORM initialization.
Where `request._serve_db` is reponsible for initializing the ORM,
`request._serve_ir_http` is responsible to do the match -> authenticate
-> pre dispatch -> dispatch -> post dispatch sequence. This sequence is
very much similar to `_serve_nodb` with the notable addition of the
authenticate step.
Where `_serve_nodb` was working in a db-free environment, calling the
methods of (Http|Json)Dispatcher right away, `_serve_ir_http` delegates
to the `ir.http` abstract model which in turn use the dispatchers.
The ir.http model is crucial for several modules, web, portal and
website on top. They override the various methods to add advenced
capabilities to the http framework.
An important changement to the ir.http model in this work is regarding
the `_dispatch` method. Before this work it was that method that was
responsible of doing the sequence match -> pre dispatch -> ... . It was
decided to move the responsibility to http.py in order to prevent
modules from taking over the entire framework. One such take-over was
done in the `http_routing` addon and resulted in arguably very poor and
fragile code.
All modules must now carefully override the correct method. You need to
do smart stuff on the URL prior to matching an endpoint? You should
override `_match`. You need to save a special option from the query-
strings to the session before calling the controller? Override
`_pre_dispatch`.
PR: odoo#78857
Task: 2571224
This commit is the 10th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
One of the objectives of this comprehensive refactor was to simplify the
error reporting, to show developers shorter and more informative
traceback upon errors.
We argue that the current error reporting is too much bloated:
1. There is a "dual" traceback, one traceback for the frames more recent
than `/base:ir.http_dispatch` (`@route` wrappers + controller) and a
second traceback for the former frames (http framework + web server).
2. We trace too far back, we argue that it is useless to trace back to
the thread/worker creation, that we should only trace back until the
WSGI entry point.
3. There is too much noise, many frames are either implementation
details or useless information. e.g. middlewares, `_dispatch`
overrides, wrappers, "checks".
To solve the above problem we did the following:
1. All errors bubble up to `request.__call__` where it is logged, any
wrapper that catch an error must log it or re-raise it. By logging
exceptions in `__call__`, we ensure the traceback at that function.
2. When one raises an HTTP error, e.g. 404/NotFound, the object is at a
same time an exception and a response. We don't log it and use the
response right way.
3. When one raises an exception, e.g. ValueError, the exception is sent
to `handle_error`, its job is to return the HTTP error corresponding
to the given exception, e.g. 500/InternalError in case of ValueError.
The given exception's `__traceback__` and `__clause__` are not
modified, we log the real exception but use the http error as
response.
Minimalistic example showing a traceback before and after this work:
https://gist.github.com/Julien00859/d6a48d523cac42d0df2e3136f5ba3e54
PR: odoo#78857
Task: 2571224
This commit is the 9th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals. See also [REF] core: HTTPocalypse (11) ir.http base model.
This is a two-part commit with "(11) ir.http base model". In this commit
we focus on the initialization of the various ORM objects, namely: the
registry, the cursor, the environment, the user and the context. In the
other n°11 commit we focus on the ir.http model and its relation to the
current http.py module.
One of the objectives of this comprehensive refactor was to ease the
cognitive complexity of the http framework, in other words to make it
simplier. One of the problem identified quite early during the
preparation of this work is the way the various ORM objects are
initialized, modified and cleaned during the request lifetime.
Before this work, all the ORM internals were lazily initialized via
properties. It is the first time one uses `request.cr` that a cursor is
opened to `request.db` and stored on `request._cr`. It is the first time
one uses `request.env` that an environment is create with the current
`request.user` and `request.context`. Upon user or context modification,
the current environment is discarded, the next usage of `request.env`
will create yet another environment on the fly using the modified user
and/or context.
Using this model, no ressource is initialized if not necessary. It is
possible for nodb-compatible endpoint to be served via the db-compatible
router and ir.http without ever opening a cursor to the database.
But this model is harder to reason about and ultimately to maintain.
In this work we propose to drop the lazy approach for a greedy one. In
this work the first steps of `_serve_db`, the db-compatible counter-part
of `_serve_nodb`, are dedicated to setup a registry, open a cursor to
the database and create an environment using the session's user and
context. In this work, when one wants to change the environ's user or
context, he must call `request.update_env` or `request.update_context`,
both method will recreate the environment *now* with the given values.
The downside of this approach is that resources are always allocated
even when it is not necessary. We argue that, in general, the
controllers that do not use the ORM are rare thus it is rare we allocate
unecessary resources. We also argue that the cognitive benefits are more
than welcome and that the new APIs will help at writing more robust
applications.
PR: odoo#78857
Task: 2571224
This commit is the 8th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
PR: odoo#78857
Task: 2571224
See also: [REF] core: HTTPocalypse (6) serve db-free routes
This commit is the 7th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
PR: odoo#78857
Task: 2571224
See also: [REF] core: HTTPocalypse (6) serve db-free routes
This commit is the 6th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
There are some routes that must work even when the user is not connected
to a database yet. Two obvious examples are the index (/) and the
database selector (/web/database/selector). Accessing those routes
should be possible even when the user is not connected to a database yet,
the `nodb_routing_map` and the `_serve_nodb` method fulfill this need.
Along with the introduction of the `_serve_nodb` method, we also
introduce the match -> pre dispatch -> dispatch -> post dispatch
sequence. `match` matches an endpoint using the http path,
`pre_dispatch` prepares the system, `dispatch` is the actual endpoint
call, `post_dispatch` cleanups the system and add some http headers to
the http response.
At the beginning, when an endpoint is matched, we retrieve the `routing`
dictionnary that is attached to the endpoint method. This dictionnary
contains the information set by the `@route` decorator, among other
values is the routing type `http` or `json`. This routing type is used
to specialize the request via one of the dispatchers: HttpDispatcher for
http and JsonDispatcher for json. Via the dispatchers, it is possible to
add custom behavior in the form of (pre_|post_)dispatch override. One
example of such custom behavior is the way the request body will be
loaded: urllib.parse.parse_qs (http) vs json.loads (json).
Before this work, it was not possible for multiple dispatchers to be
compatible with a same request mimetype. Because `JsonRequest` was
implementing the support for `application/json` (and like) mimetypes,
all requests having a body's mimetype `application/json` were considered
JSON-RPC2 (the protocol implemented by `JsonRequest`) even if the
request was actually bare json data. With the introduction of the
`is_compatible_with` classmethod, multiple dispatchers can be compatible
with a same mimetype and it is up to the `@route(type=...)` param to
define which dispatcher should be used with this route.
PR: odoo#78857
Task: 2571224
This commit is the 5th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
A session is a file that contains user data that must be preserved
across several requests. It is a small (=at most a few kb) file that is
stored on the filesystem in the session store. Each filename is a random
sha-1 string, the same sha-1 is saved in the request's cookies. The
browser has no access to the session, it only possesses the random sha-1
cookie which the server use to retrieve the session upon each request.
It is in the session that the database that the user is connected to is
stored. The first time the user accesses the server the database is
determined using the HTTP Host header of the request plus the list of
available databases and is saved into the user's session. Later requests
merely ensure the database stored in the session is still enabled.
The session "feeling" is the same as before the httpocalypse. The
session is still a DotDict-like structure with methods such as
`authenticate` and `logout`. The difference is the implementation, in
master we were using the werkzeug session, with this work we decided to
get rid of those off-the-shelf sessions to implement our own object.
The major difference between the two implementations is the way we
determine when a session is "dirty", when the session should be written
back on the filesystem. In werkzeug it is a `modified` flag attribute
that is set as soon as `__setitem__` is called, in our implemention we
keep an immutable copy of the original session, at the end the of
request lifecycle we compare the live session to the copy to determine
if it was changed. The former was setting the `modified` flag even when
one was setting the same value as existing in the session. The later
approach is not affected by this limitation.
PR: odoo#78857
Task: 2571224
This commit is the 4th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
Complete refactor of the "registry" of controllers. The `ControllerType`
metaclass have been replaced by an abstract class with a py3.7
`__init_subclass__`. The `Endpoint` class is gone too, replaced by a
clever usage of `functools.partial`. This refactor is "pure", it doesn't
add any new feature, it only merely adds a few warnings.
The four `@route`, `Controller`, `_generate_routing_rule`, `routing_map`
work as follow:
1. A reference to each immediate child class of `Controller` (not grand-
children) is registered in a global list indexed by module (thus a
dictionnary) everytime the server starts. Remember that every first-
child (not grand-children) of `Controller` is the primary controller,
the one that can later be extended by other controllers (the grand-
children) in other modules. Remember that it is possible to get each
class's children via the `__subclasses__` dunder method.
2. Every controller method that is decorated with `@route` is granted an
attribute: `original_routing`, a dictionnary containing the `@route`
arguments. When a controller method has the `original_routing`
attribute, this method is called an `endpoint`.
3. `_generate_routing_rules` receives the list of installed module
names, this list is topologicaly sorted according to the modules
dependencies. That is `base` comes before `web` in this list. The
objectif of this function is to pair each route to an endpoint whoose
class's MRO respect the above-mentioned order. Whe achieve this by
carefully crafting classes at runtime, classes inheritating from the
correct "source code" controllers in accordance to the topology. This
method is also responsible of merging each method's `original_routing`
into one `routing` dictionnary, the very `rule.endpoint.routing` dict
that is used through the rest of the http framework.
4. Each route-endpoint pair is saved into a `routing_map`, an object
that bind each route to its endpoint. This object exposes a `match`
method used to find back the endpoint given its route (=http path).
In addition to this refactor, we added some new helpers in our tools,
among them `submap` that implement a kind of `dict() - set() -> dict()`
operator. Filtering a dict on a set of keys is a common operation but
the python standard library lacks a dedicated operator.
PR: odoo#78857
Task: 2571224
This commit is the 3rd commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
Static files were historically served thanks to a werkzeug middleware,
the usage of that middleware prevented easy modification of the response
headers. Using `http.send_file` and `request._serve_static` we achieve
the same result as the middleware with less code and less frames in the
callstack.
The historic `http.send_file` have been splitted in two. One to send
a file via its path on the filesystem (prefered function) and one to
send a file already open. It is preferred to use `http.send_filepath`.
During development we tried to remove the fallback from the
`_serve_static` function into the more capables (and resource hungry)
db-compatible router. The purpose was to quickly respond to all requests
requesting static files at the cost of reduced customization. We have
been prooved wrong, e.g. the website themes all depends on the fallback
mechanism to deliver static files.
PR: odoo#78857
Task: 2571224
This commit is the 2nd commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
This commit poses the global structure of the new HTTP framework. Major
classes are present (yet empty) with a minimal docstring explaining
their general purpose.
PR: odoo#78857
Task: 2571224
This commit is the 1st commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
Our application framework is quite complicated. There are a few explicit
middlewares: `ProxyFix`, `DisableCacheMiddleware`, `SharedDataMiddleware`.
There are many (13, in total) implicit ones in the form of
`ir.http._dispatch` overrides. There are a few frames that don't have
much values by themselves and are very much implementation details
there are: `application_unproxied`, `_call_function`, `checked_call` and
`EndPoint.__call__`.
The ORM initialisation is quite magical, the cursor, registry and
environment are all setup lazily thanks to class properties. The
context and uid of the environment are aliased on the request. The
abuse of properties makes it impossible to reason about where and when
the environment is actually instantiated and modified.
The dispatch of a request follow the next scheme:
`odoo.http/Root.dispatch` -> `odoo.addons.base.models/ir.http._dispatch`
-> `odoo.http/(Http|Json)Request.dispatch` -> `odoo.http/@route` ->
controller. Because the request becomes http or json specialized quite
late, the many ir.http override all need to parsimony try/except their
code in order to manually call `_handle_exception()` uppon error, they
cannot let the error bubble-up. This back-and-forth between odoo.http
and ir.http is source of some headaches.
Speaking about error, the `odoo.http/WebRequest._handle_exception`
implementation is quite complicated, it basically craft a new exception
out of the passed exception object in order to correct its traceback.
If the error had been bubbled-up instead of handled by
`_handle_exception()` such python hack would not have been necessary.
The objectives of this refactor are about refounding the technical dept:
* We want shorter error reporting;
* We want simpler request and ir.http APIs;
* We want better integration of all the ir.http extensions.
PR: odoo#78857
Task: 2571224
Since this commit [1], we considered that if a snippet contained a
modal, it is that the overlay had to cover the modal itself.
But that is not correct, because in some cases a snippet can contain
closed modals (e.g. the course page in the website slides module
contains modals).
After this commit, we avoid applying an overlay on a modal that is not
open.
[1]: https://github.com/odoo/odoo/commit/bc055e7822b9b2e7f8f9608e335456a71d7896a1
task-2710582
closesodoo/odoo#85240
X-original-commit: 9f3eac25b1806d13e270902848c6ead523c7e6bc
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
I create a method `_prepare_payment_display_name` for inherit.
When you want to set a new name for payment, you can extend this method.
Exp:
I create a new partner type is `employee` in payment for payment with
employee, but with your old code i can't add the key `outbound-employee`
or `inbound-employee`. So, the system will give an error message.
I think if you add this hook method, it will be good for customizers.
closesodoo/odoo#85251
X-original-commit: 6d129783b53115927f664499207c8c800d40bca2
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Current behavior:
In the PoS when you add an order the 2 terms "Settle the order" and "Apply down payment" where hardcoded in the code.
Steps to reproduce:
- Have PoS and Sale module installed
- Go in PoS
- Try to add an order sale
- The 2 terms are hardcoded and cannot be translated
opw-2754052
closesodoo/odoo#85168
X-original-commit: 440cd020cfce4147973d356fd714a5d78c315c70
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
1) Now report manager (user_id) (with Team Approver rights) can't see the report.
Here we grant him the same rights as the manager (on employee app)
of the employee will have. Moreover, he can approve the report as well.
2) Purpose: accountant, manager, should be able to edit expense_line_ids
for expense report not only in draft, but also for submitted and approved states.
On the other hand, employee can only edit his expense report only in draft state.
task - 2768700
closesodoo/odoo#84978
Related: odoo/upgrade#3274
Related: odoo/enterprise#24579
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Without ce342f42f21cad3 the new test fails because copying an
attachment requires write access to mail.template
closesodoo/odoo#85271
X-original-commit: d5ceaa13a36e86e97f14e870ade477f62234b304
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Currently, `Attachment.copy` has an *explicit* check for write access
on the underlying record.
This doesn't necessarily make sense e.g. a user copying an attachment
from a template to an email may not have write access to the template,
but that should not be an issue. And indeed if the copy is performed
"by hand" (read then create) things work fine[^1].
Since both `read` and `create` are checked, the explicit `copy` check
doesn't seem necessary. Drop it, and try to add some tests around
`copy`. Move `test_06_linked_record_permission` to its own `TestCase`
and split it for readability.
A secondary issue is that the `check` in `create` was performed in the
context of the `self` being copied, leading to the same issue as
`copy` being repeated (that is, `a.copy()` would call `a.create()`
which would call `a.check('write')`, even though we're semantically
creating a record from scratch). The behavior is really intended for
`write` where we want to check if we have `write` access to both the
"source" and the "destination" records.
Explicitly opt-out of having any source data in the `create` before
performing the `check` calls, this way we correctly and only check for
the writability of the destination, and only check for the readability
of the source.
issue 2746483
[^1] well not entirely true, see 4th paragraph
X-original-commit: 60723fb311ed7cc1cf901fe90e8745835cf4d54d
Part-of: odoo/odoo#85271
Since 15.0, the time off type can have different types of approval:
- No validation neededd
- Approved by Time Off Officer
- Set by Time Off Officer
This commit adds a tooltip on the allocation_validation_type to improve usability
task-2681288
closesodoo/odoo#85265
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This flag allows code to detect it's running on a neutralized database.
closesodoo/odoo#85259
X-original-commit: 892efa2c8b85b86155d50055dca568592569d411
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Raf Geens <raf@odoo.com>
In some cases like `fetchmail.server` and `calendar.alarm`, modifying
the record can result in the corresponding cron job being enabled as a
side effect through `ir.cron.toggle`, even if it was archived before. In
`fetchmail.server`'s case on a neutralized database, this can result in
the cron job unintentionally affecting a production mailbox.
Since `ir.cron.toggle` is inherently risky on a neutralized database,
this PR disables it when an `ir.config_parameter` indicates we are on
one.
This parameter can be set both by the neutralization API introduced in
Odoo 15.2 and by legacy neutralization tools for older Odoo versions.
closesodoo/odoo#85258
X-original-commit: 4fba314faa1c8f67ac1dd93351ebf8ce39c5caf7
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Raf Geens <raf@odoo.com>
For the moment we cannot star a product from the form of sales view
Steps:
-Sales/Quotation
- Create new quotation
- Add a new product in the order lines
- Open product form from External link
- Try to star product
Because of the quickedit the onClick is called when it shouldn't,
the solution would be to rename the onClick function so that it
doesn't interfere with the quickEdit.
opw-2759063
closesodoo/odoo#85242
X-original-commit: edafd9fe49b1e4c73ee1768efc3df26b463b2f14
Signed-off-by: Achraf <abz@odoo.com>
In neutralized databases, modifying records like `fetchmail.server`
re-activates the related archived cron job as a side effect, which
could impact production mailboxes. The initial solution to this was to
comment out the server action code linked to the cron job as an extra
precaution.
The impact of that solution is too broad, and it also means users have
to be aware of the need to uncomment the code if they do want a cron job
to run on a neutralized copy. It's been replaced by disabling
`ir.cron.toggle` instead:
https://github.com/odoo/odoo/pull/85192closesodoo/odoo#85260
X-original-commit: 6c950959e1f4bed82d62796f0d89d82784e556b6
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
In this commit we fix computation of likes and dislikes by splitting computation
by usage. Computation for likes and dislikes is improved to be done using a
read_group instead of browsing potentially a lot of slide.slide.partner records.
This should speedup computation, even if we have to do 2 read group instead of
a single big fetch. Indeed we have to take into account vote being 1 or -1 to
compute both values "like" and "dislike".
We also fix batch computation as it was sharing a dict. As frontend UI leads
to voting one slide at a time this should have few effect on stored values.
But now batch computation is correct.
User vote computation is now basically a related on user_membership_id.vote.
We keep the old compute method in case it was called but computation itself
is now done with the other field.
Task-2607416
closesodoo/odoo#85257
X-original-commit: c5b1283862264132d0c2bb1f172c25af5d74448c
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Munaf Bahelim <mub@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Recently with commit[1], we changed the sequence for partner grades and
partner activations at db level (from asc to desc) to see the records
created with data files in our chosen order (for example Gold, Silver,
Bronze instead of Bronze, Silver and Gold).
However, there are several drawbacks with this approach. For example
during db upgrade, all the existing records needs to be adapted to
keep up the order of records created by data files.
This commit reverts change of order at db level, and instead adapts the
sequence of the records being created with the data files in a way that
they are still in the same order we wanted. And it will also maintain the
order of the records manually created by users after db upgradation.
commit[1] - https://github.com/odoo/odoo/commit/b28aae2
taskID-2765577
closesodoo/odoo#85235
X-original-commit: 5cc309744de5c2d5713d6bd95d02a66c21aaf11e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Previously, when completing the last step of a tour by hand, the tour
manager attempts to make an RPC to consume the tour in the backend. This
used to crash with an error saying parent._trigger_up is not defined.
This was caused by the root.widget, which is the tour manager parent,
not being a real instance of ComponentAdapter, but an object created
with the ComponentAdapter as it's protorype. To give it access to
_trigger_up, it should be created with the ComponentAdapter's prototype
as its prototype, but this would still fail as it wouldn't have the
correct environment containing the rpc service.
The simple solution is to create a real instance of the ComponentAdapter
by hand. Although owl 2 does not support instanciating components by
hand and mounting them later, we will never mount this component or use
any of its owl features, we are simply using it to replace what used to
be the ServiceProvider in legacy.
closesodoo/odoo#85221
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: mail, mrp
Previously, to prevent images and iframes from making GET requests in
tests, we would listen for the DOMNodeInserted event. This event is
deprecated and should not be used. Additionally, we weren't listening
for attiribute changes for performance reasons, which would result in
some GET requests still being made when an src attribute was changed.
This commit changes the mechanism that is used to do this from mutation
events to a MutationObserver which is not deprecated, and now also
listens for attribute modifications as MutationObservers can be
configured to only listen for changes to certain attributes, greatly
alleviating the performance impact of listening for those.
This mechanism has also been enabled globally by doing it once in the
test setup code, instead of requiring one to call a specific helper, as
we never want to make real requests during tests.
Some tests have been adapted to this new behaviour.
closesodoo/odoo#85216
Related: odoo/enterprise#24665
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce the bug:
- Create new UOM categories
- Add a new reference UOM
- Add another line, for example:
- type: “Smaller than the reference”
- Ratio: 4
- Click outside the line
Problem:
The type is changed to “Bigger” and the ratio is reset to 0,
because we are trying to change the type and the factor based on the value of the current uom factor,
but as this factor has not yet been calculated in `set_ratio` the changes will be distorted.
This part of the code in the onchange is useful when for example we already have a UOM category saved,
and we change the reference, in this case all the UOM will have to be calculated again
Solution:
Don't change the factor and the type in the onchange if it's a new line
opw-2754303
closesodoo/odoo#85214
X-original-commit: daf0dd44345de9877e2e79035d05ddca6c19064b
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Romain Derie