* Split python file by classes
* Remove empty ir.model.access.csv file
* Correct name for views file
* Use setUpClass instead of setUp to avoid multiple setups during tests
Part-of: odoo/odoo#85001
When unbuilding a MO, if the latter has several lines (in its
components) for the same tracked product, it won't work.
To reproduce the issue:
1. Create two storable products P_compo and P_finished
- P_compo is tracked by USN
2. Update P_compo's quantity to 2
3. Create a MO:
- Product: Finished
- Quantity: 1
- Components:
- 1 x P_compo
- 1 x P_compo
4. Process the MO
5. Unbuild the MO
Error: a validation error is displayed while it should not "The serial
number has already been assigned: Product: P_Compo, Serial Number: C01"
The for-loop in `action_unbuild` do not handle the case where there are
several SMs for the same product. In the above case, there are two
component lines for P_compo, so there are two SM in `MO.move_raw_ids`.
When unbuilding the MO, the module creates and processes two SMs (SM01,
SM02) that "produce" two P_compo (stored in `produce_moves`).
When processing the first one in the for-loop, it takes the original
moves (so the `MO.move_raw_ids` with the same product) and uses them one
by one. Since SM01 needs one P_compo, it uses the first SM of
`MO.move_raw_ids` (and reuse the lot of that SM). Later on, when
processing SM02 in the for-loop, it does exactly the same thing: it
takes the original moves and uses the first one. Here is the issue: this
first SM has already been used and so does its lot, so this SM should
actually not be used again.
OPW-2715155
closesodoo/odoo#85354
X-original-commit: 8d2597965202a76ddeea8d8fed60b7ac014e2df8
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Currently in kanban view of the notes, if there is long content without space
(for example a very long URL), the content goes out of the kanban card.
This commit improves the behavior by breaking such content into multiple
lines and thus displaying full title on the kanban card.
taskID-2754915
closesodoo/odoo#84607
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
PURPOSE
Before this commit, the headers for the eLearning module were fixed
(Odoo purple gradient or images), and did not always fit with the color theme
chosen by the users. This commit enables the customization of these
website_slides headers for homepages as well as courses and lessons
(on a per-course basis).
SPECIFICATIONS
This commit replaces the channel and lesson headers with `Cover` snippet, so
that they are customizable (by channel) with the website editor. The
customization includes background, additional filter, text alignment, and text
alignment.
The banners for categories of channels ("All courses", "Certifications", and
"My courses") are now also customizable, and other website blocks can be added
above and below them.
Before this commit, the static header background for courses was updated to a
different color palette for certification tracks (`website_slides_survey`).
With this commit, the aspect of the header will no longer be different when
a survey is added but keep the customization (or default value for courses).
The `o_wslides_gradient` class is now obsolete and is renamed to different
labels depending on its remaining local purpose.
The default aspect of courses and lesson without images is therefore switched
from the Odoo purple to the theme background color.
LINKS
Task-2516830
closesodoo/odoo#78257
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Sometimes the refresh_token is not saved in the db because the code
after it fails (timeout). We also want to avoid 2 processes
trying to renew the token at the same time (=> avoid desynchronization
of the refresh_token)
So, we added a locking mechanism and do a commit after we refresh the
token.
- If we have very big invoices to receive, they do not get imported into
the database. At the moment we risk timeouts.
Our solution is to do a lot of intermediary commits and we link it
to a temporary account_move before doing the import logic and maybe
putting it into the definitive one.
closesodoo/odoo#85372
X-original-commit: ce47d09c05e4bcc91ee4de68db3a7a471bcb4df8
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
Fine tuning of commit 6acfb2e
It correctly merge the purchase.order in case of direct link and
avoid to relaunch the procurement.
It also correctly set the created_production_id if the demand come
from a SO
closesodoo/odoo#85301
X-original-commit: 9b6fa6c3db55daa3533c0d5cb13da7c98fc3e936
Signed-off-by: Arnold Moyaux <arm@odoo.com>
The query added by 6c207ed1027d9b39eecd19886932b17f1a79dccd is not
optimal. Avoid using `LEFT JOIN` and `OR` by doing 2 queries and adding
their results.
From local tests, a `search_read` on `project.project` is about 4x faster:
2400ms -> 600ms.
closesodoo/odoo#85365
X-original-commit: 0235f2ded8ef6478ed36e2d8ba1c46acef5f1dab
Signed-off-by: Christophe Simonis <chs@odoo.com>
Previous refactoring: odoo/odoo@3b06565 switched move_line.product_qty
to move_line.reserved_qty. This line was missed during the refactoring
so we fix it now.
closesodoo/odoo#85355
X-original-commit: 624c155e77ae1d3fa964a949f17b4d8c73e9b35d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
When checking if the powerbox should open, we check the selection but
that was done on the global document, which returns a wrong selection
for the editable if it's in an iframe. As a result, the powerbox never
opened in mass_mailing.
task-2778414
closesodoo/odoo#85352
X-original-commit: d5b8c26c46b1daf795a6b286af80bb4dad8072ff
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet <age@odoo.com>
*: website_sale_coupon, test_apikeys
The do_search_read method was only used in a single place: the
search_read controller, whose entire function body was just a function
call. The content of the do_search_read method has been moved to the
search_read controller.
The search_read controller is still pretty useless: it's basically
equivalent to making an RPC on a model and calling the method
web_search_read. As such, this controller should be removed, but lots of
code depends on it and adapting all the code that uses it is out of
scope for this PR. It will hopefully be removed alongside the legacy
views in the webclient (which are its main users).
The call_common method and /web/dataset/load route are completely
unused.
The /web/dataset/call controller is used in only two places and can
trivially be replaced with a call to /web/dataset/call_kw
The non-route methods were removed and the route methods now emit a
deprecation warning telling the user what to use instead.
closesodoo/odoo#84811
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
If a report contains a t-if with something like `field in ('a', 'b')`
as a condition, a crash occurs if you try to modify the 'Visible if'
field in the report editor because the domain editor doesn't support parenthesis.
This commit adds this compatibility based on the case of `[]` which is essentially the same thing
opw-2738343
closesodoo/odoo#85331
X-original-commit: bd76793397cb88e12fce4ffc886eefbce0b54975
Related: odoo/enterprise#24722
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Achraf <abz@odoo.com>
The issue here is to be able to change the type of bank account
on the bank journal, e.g. changing from type "Current Assets" to "Bank and Cash".
Previously, a ValidationError would be raised :
"This account is configured in %(journal_names)s journal(s) (ids %(journal_ids)s)
as payment debit or credit account.
This means that this account's type should be reconcilable."
But in some cases, the client might decided not to reconcile.
And the error did not take into account the case when the bank account
and the outstanding accounts are the same.
opw-2738777
closesodoo/odoo#85370
X-original-commit: fe379bc22e649c623dfb6ed8aefb106b4846d02e
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: John Laterre <jol@odoo.com>
Commit [1] introduced a cron that disables outdated js and scss snippets
assets. For example, if a new version of the masonry snippet is defined
with new assets: data-vcss="001" and data-vjs="001", the previous assets
have to be disabled (000.scss and 000.js).
That cron was not handling the scss variables files at all, so when
an outdated snippet was still used in the db and the cron was run, the
000.scss file was activated, but not the 000_variables.scss and it was
crashing the assets.
Now, the XXX_variables.scss assets files are handled alongside the
XXX.scss files.
Also, the regex used in the _is_snippet_used method was only returning
the first match of a snippet in an html field. So if a view had a
snippet up to date and then an outdated snippet of the same type, the
old assets were not activated. The 'g' flag was added to return all the
occurences of the snippet in an html field.
[1]: https://github.com/odoo/odoo/commit/fa1c05e7bb2959c6025a806a4348f69ed225b4ec
task-2775188
closesodoo/odoo#85360
X-original-commit: 644067e80d4ca3f41707cddd15ed8f2807a1e410
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Removes confusion in technical code. An instance of Thread is a thread, by
analogy a record should be an instance of Record.
closesodoo/odoo#85359
Related: odoo/enterprise#24731
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
* 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>
Victor Feyens