The odoo.addons.web.controllers.main python module have been splitted
over multiple files on the basis 1 controller = 1 file. In this work we
adapt all modules to use the new imports.
A non-exhaustive list of where stuff have been moved:
* main.Home --> home.Home
* main.Session --> session.Session
* main.WebClient --> webclient.WebClient
* main.clean_action --> action.clean_action
* main.ensure_db --> home.ensure_db
The complete list is accessible in odoo.addons.web.controllers.main.
closesodoo/odoo#87571
Related: odoo/enterprise#25746
Signed-off-by: Raphael Collet <rco@odoo.com>
Install auth_signup, go to /web/login, 500 Internal Server Error.
auth_signup extends the /web/login template and in this extension calls
`keep_query()` which has been wrongly moved from base to http_routing in
commit 880954ebfc. Here, we restored `keep_query()` in the base module
but moved in ir_qweb.
closesodoo/odoo#87491
Related: odoo/enterprise#25754
Signed-off-by: Julien Castiaux <juc@odoo.com>
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
Before this commit: static XML templates could only be defined on the
file system, and called by manifest assets or ir.asset records.
Attachments were not taken into account when evaluating static
templates.
Now, if a given path does not match a file on the system, an
additional check is run on ir.attachment records instead of failing
directly.
Task 2715333
closesodoo/odoo#83438
X-original-commit: e022c4bfafa77f1a3433c3b980631510af696ade
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
On runbot database can be create concurently by other builds, meaning
that the teardown may fail randomly if a database is create between
setup and teardown. Filtering on the dbfilter in all case may miss some
errors but will be enough in this case.
closesodoo/odoo#83414
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When changing the background image with studio the image does not update.
It works in debug=assets mode.
This is due to the fact that the caching system is not aware of the presence of a possible background image
opw-2696786
closesodoo/odoo#83374
X-original-commit: 184029e3e1e8907e25dd712dd87afd65885695bb
Related: odoo/enterprise#23744
Signed-off-by: Achraf <abz@odoo.com>
Database manager may easily be broken since it wasn't tested and is a
special case (can be rendered without databases). This commit adds a
basic test to check that the database manager is rendered as expected.
Testing database rendering is not enough, in some cases the database
operations may be broken. Another test will be executed on runbot to
test basic create/duplicate/delete operations. The test is tagged as
"-standard" since it can be a risk to execute such operation
automatically with other tests.
closesodoo/odoo#82874
Signed-off-by: Raphael Collet <rco@odoo.com>
As this test is always red, notably because of the qunit asset bundle, the
threshold is raised for some bundles based on runbot builds
observations.
closesodoo/odoo#82972
X-original-commit: ab8350b5432a6a6d671bcc76413815274f7daaca
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
As JS is not taking the properties in the order they are written,
the order in the rendering was always following the property name
sorting order (=id).
Previous to this commit:
- The companies were ordered by their id in the company switcher as
JS is not tacking the object properties order into account.
After this commit:
- The companies will be sorted by their sequence prior to be used in the
rendering.
task-2722235
closesodoo/odoo#81893
X-original-commit: 39c678a1ccb50d3a1871a4049a8df26427b27a3c
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The http.addons_manifest is a map {module: manifest_dict} that is
populated upon the first http request. This map is basically a module
manifest cache with an extra `addons_path` key, the path of the module
on the file-system. This cache is eagerly populated upon the first http
request, the map is empty in non-http contextes (e.g. cron) which have
been a source of bugs (e.g. 50c8eb1).
A manifest cache is necessary because reading and parsing python files
from the file-system is not that cheap but there is no reason that cache
is located in `odoo.http`. A thin cache layer now wraps
`load_information_from_description_file()`/`load_manifest()` and is
lazily populated.
The `http.addons_manifest` have been removed. The extra `addons_path`
key is now present in the "normal" manifest. The `read_manifest()` was
hardly used so it has been deprecated. The only way to retrieve a
manifest is now `load_information_from_description_file()` which was
renamed `load_manifest()` (no cache) and `get_manifest()` (cache).
Side note about performances, the cache is necessary. Addons manifest
are read-only and reading + parsing python files from the file system is
not a cheap operation. Running the e-commerce tour
`@website_sale.test_04_admin_website_sale_tour` without cache on
`load_manifest()` requires 68,29 secs to complete on my laptop,
exceeding the default 1-minute time frame allowed in tests. Using a
cache the time is down to 36,53 secs. The performance impact is huge.
Part-of: odoo/odoo#79977
* remove `component_extension_tests`, that's a test from web and
already tested by web, no idea why it's rerunning in POS
* remove all failfast specs, after discussion with ged, seb, and
xdo it was considered not useful: it's mostly for the runbot but
turns out to be pretty minor as far as positives go, and it makes
fixing errors much harder
Part-of: odoo/odoo#77735
When using profiling on a fresh test database, it can be tedious to
access settings to enable the feature. This commit adds a wizard to help
enabling profiling without accessing the settings when trying to
activate profiling on a administrator session.
closesodoo/odoo#75967
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The value returned by the search_read in read_progress_bar when passing
a m2m field is a list of ids, which then read_progress_bar tries to use
in a dictionary, list is not a hashable type thus it crashes.
With this commit we convert the group_by_value from list to tuple,
which is hashable, if we're dealing with a many2many field.
task-2508608
Part-of: odoo/odoo#74985
Regarding previous commit, the option parameter can be removed
from _get_asset_content api, followed by a nice snowball effect.
Part-of: odoo/odoo#75248
The given time are currently quite high (arround 5 seconds for some
bundles) but it is difficult to know what kind of assets are taking so
much time. This commit will split js and css in order to track the
generation time separatelly.
closesodoo/odoo#75030
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
From time to time, the bundle generation duration may be unexpectedly
increased by assets modifications.
In order to avoid that, this commit adds two tests that generates all
the bundles. One of the test is only meant to log the duration in order
to monitor it. The other test is ensuring that a bundle generation does
not take more than 2 seconds.
Pay attention that the purpose is not to test the generation of the
bundle, any error during generation is logged as an information.
Also, warnings are silently ignored.
closesodoo/odoo#74746
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The method is used to get progress per column in kanban view
(green-yellow-red-red lines in Project, CRM etc). There are two main
usages:
1. get statistics for ``kanban_state`` (red/green circles)
2. get statistics for ``activity_state`` (colored clock icon for overdue/today/planned)
Before this commit all cases were handled by calling search_read and then
counting records per group in a python script. This is very inefficient,
especially for ``activity_state``.
This new implementation relies on ``read_group`` when possible, i.e.,
when both grouping fields (kanban column and progressbar field) are
stored (case 1). It then falls back on a naive implementation inside
``_read_progress_bar``. Cases like 2 above can be addressed by
overriding ``_read_progress_bar``.
We also added some minimal test to ensure that we don't break anything.
1. Performance test on 60 K project.task records (kanban_state):
With a filter for 6 records:
```
| measurement | before | after |
|--------------------+--------+-------|
| number of queries | 8 | 5 |
| query time, ms | 11 | 7 |
| remaining time, ms | 21 | 9 |
```
All records:
```
| measurement | before | after |
|--------------------+--------+-------|
| number of queries | 67 | 5 |
| query time, ms | 300 | 55 |
| remaining time, ms | 1780 | 12 |
```
---
opw-2346901
task-1915411
X-original-commit: 153621bdbab94a2a94a5bbfcabb4111cbc5970d8
Co-authored-by: Raphael Collet <rco@odoo.com>
Before this commit, the clickEverywhere test was run for the demo
user on all apps available for the admin. It thus crashed on the
apps that aren't available for the demo user.
closesodoo/odoo#72430
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
With the rewrite of the webclient in OWL 29731b404f, the load_menus
method now returns all menus instead of the root menu.
This commit adapts the click_everywhere tests to the change.
closesodoo/odoo#72405
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit is the first phase of the conversion of the web/ JS
codebase to the owl framework. The impact of this commit is two-fold.
First, it rewrites the framework part of web with a new system of
services and registries. Services allow to execute code (e.g. do rpcs,
setup things) before launching the application. They can also expose
an API to be used by other parts of the application (e.g. a notification
service would expose a function to display notifications). Services are
often a good extension point for external modules that want to execute
code at webclient startup. Registries offer another way to extend the
application. They provide well designed extension points to add
elements/behaviors from the outside (for instance, to add a systray item,
an error handler...).
Second, this commit initiates the conversion of the webclient to owl
with a top-down approach, around those notions of services and registries.
The root of the web application is now an owl application. Among others,
the WebClient, ActionManager, Navbar, UserMenu, DebugManager, Dialogs,
services (e.g. notification, ajax...) have been converted to the new
framework/architecture.
Legacy views and client actions are still supported (and used). They
will be converted in the next months, and at some point, the support
will be dropped.
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Owl 1 has some issues handling comments. So when people were in odoo
debug mode, inheriting in extension mode a t template, the comment
added from the server would throw a frontend error.
For now, we comment it, waiting for better comment handling in owl.
closesodoo/odoo#70227
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
The profiling tools can be useful to profile a test of some execution
point but this is not convenient to identify a problem on a running
instance.
With this commit, an option available in the debug menu allows to add a
flag on the user sessions to enable profiling of all requests. Each
request will be saved in a different 'ir.profile' entry, but will be
grouped under the same session.
The profiling can be activated on all sessions, even for a public user,
but only if profiling is enabled on the database globally.
This commits also adds a speedscope view to visualize saved results in
the web client.
closesodoo/odoo#66590
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Since the changing of assets (8cc066173d)
the /web/session/modules route returned a stringified set instead of a list
After this commit, the route returns a list
closesodoo/odoo#70545
X-original-commit: 54e4a48996826dd8ea16a84517b46a847d6daf3f
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
* IMPACTED VERSIONS
12.0+
* HOW TO REPRODUCE
locale : Locale is en_US (or other SUNDAY based)
view: CRM - My Pipeline - Kanban view
groupBy: date_deadline:week (Expected closing)
records: one record with a planned activity, on date_deadline = 2021-05-02 (SUNDAY)
one record with no planned activity, on date_deadline = 2021-05-09 (SUNDAY)
remark: don't keep any other record in MAY for better visibility
* PROBLEM
The progressbar of the week containing 2021-05-09 displays information about the record
from the week containing 2021-05-02
* CAUSE
1. PostgreSQL `date_trunc` function follows ISO8601 which essentially means that
the start of a WEEK is always MONDAY. There is no argument to change this.
2. _read_group_format_result
https://github.com/odoo/odoo/blob/27da86a138089c1838e4b94f8a6976995b9c1fff/odoo/models.py#L2210-L2219
- Computes a label for a group of records.
- Follows the locale for the label of the week, based on a date which is
always a MONDAY because of `date_trunc`.
3. read_progress_bar
https://github.com/odoo/odoo/blob/88957afca09662af7eaa19df1e40b3699e45e79e/addons/web/models/models.py#L167-L175
- Associates a group label to a record.
- Follows the locale for the label of the week, based on the date of a record
which can be any day of the week. If the record is related to a SUNDAY and
SUNDAY is the first day of the week, it would have been in a group with a
different label in (2.) than in (3.) prior to this change.
* FIX
In 3., before associating a label to a record, we truncate the date to the
ISO start of the period, so that the label is determined for a record in the
same conditions than in 2. The locale is still used to get language-dependent
outputs with babel, but the grouping will always follows ISO8601 (date_trunc).
* TEST
Added a test for this problem case
TASK-ID : 2517848
closesodoo/odoo#70498
X-original-commit: 4560925b26fa79740b9618fd9241d3517b64f43f
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* QWeb bodies should be markup-safe so `0` should always be
markup-safe.
* `head` is qweb-rendered so the same.
* The `json` pseudo-module in qweb templates is `json.scriptsafe`,
which should be markup-safe.
Rationale:
The majority of cases where an ir.asset is manually declared
outside of manifest files is to specifically add a single asset file.
This means developers are specifying a single asset *path*, and not a
glob expression. In this context, it seems better to name the filepath
field `path`, and document that it can be specified with a glob
expression when (seldom) needed, rather than making the exception appear
to be the norm - possibly puzzling many developers (What's a glob and
why do I need one?)
The doc is updated as well, and some spell-checking and wording
improvements were done too.
This required some adaptations to the existing `ir.asset` declarations:
- odoo/enterprise#17465
- odoo/design-themes#459closesodoo/odoo#68695
Related: odoo/upgrade#2348
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
On website app installation and on new website creation a configurator is launched.
The purpose of this configurator is to generate a website that meet the user's needs.
The configurator is composed of 4 steps:
1) Business description: the user is asked to describe its need with its website purpose (dropdown), its industry (autocomplete search) and its objective (dropdown).
2) Logo and palette selection: the user must select a color palette for its website. He can also upload its logo. In this case color palettes recommendations are generated based on the logo's colors.
3) Features selection: the user select the pages and applications he needs.
4) Theme selection: three themes are recommended to the user based on its industry. This screen display a preview of these three themes.
task-id: 2451965
ENT PR: odoo/enterprise#16949
UPG PR: odoo/upgrade#2316closesodoo/odoo#67537
Signed-off-by: Sébastien Mottet <smottet@users.noreply.github.com>
This commit changes the way assets are declared in Odoo modules.
Before: assets were declared in template files. Template bundles were
generated from primary templates, so technically any qweb template could
have been called as an asset bundle, with the 't-call-assets' directive.
Being standard qweb templates, they had access to standard HTML tags
(script, link, with or without raw scripts or style definition), qweb
directives (t-call, t-raw, etc.) and could be inherited by other
templates.
Now: assets are defined in the module's manifest and generated by the
't-call-assets' directive.
More information on the new system can be found on the updated user
documentation (see the "JavaScript Reference" section).
Task: 2352566
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
This commit fix a bug introduced in #66551 where a mismatch has been done between
session.user_context.allowed_company_ids and session.user_companies.allowed_companies.
This commit also adds the following tests:
- a JS test in order to prevent future unwanted issues regarding multi company
in BasicModel.
- a Python test in order to ensure that session_info['user_companies'] is not
involuntarily changed.
closesodoo/odoo#68025
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Disabled in odoo/odoo@b992619840
by mistake.
Also, restore the "failfast" for the QUnit tests (disabled in the same
commit...).
X-original-commit: 7f8e0fe4d2a47968bdcb136fd7e6d96a184f9eae
The unit test in `test_base_document_layout` does not pass with
version 7.0.0 of PIL, which is loaded by default on Ubuntu 20.04.
The reason is that the color obtained from the image is slightly
different. This fix slightly relaxes the test (in fact we don't care
about the exact color obtained in this test, we just want to make sure
that it doesn't crash)
opw-2342394 (original ticket)
closesodoo/odoo#60071
X-original-commit: 99b3f0be1b322ee469871f9496527e8dc3e778bb
Signed-off-by: Thomas Dieuzeide <tdi-odoo@users.noreply.github.com>
Signed-off-by: Nicolas Galler <nicocrm@users.noreply.github.com>
Behavior before the fix:
Uploading a grayscale image with transparency in the company logo field
of the document layout causes a crash:
```
File "/data/build/odoo/addons/web/models/base_document_layout.py", line 89, in _compute_logo_colors
wizard.logo_primary_color, wizard.logo_secondary_color = wizard_for_image._parse_logo_colors()
File "/data/build/odoo/addons/web/models/base_document_layout.py", line 191, in _parse_logo_colors
color[1][2] > white_threshold) and color[1][3] > 0:
Exception
...
IndexError: tuple index out of range
```
To reproduce, use the `logo_ci.png` image included in the unit test
data and load it in the document layout (under General Settings).
The system does not detect that the image does not have color
information and attempts to read the R,G,B values (but the image only
has 2 values per pixel: the grayscale value and the alpha)
Versions affected: 13, 14
Behavior after the fix:
The image is loaded correctly (arguably, there is not a lot of interest
in detecting the primary color of a grayscale image, but the script
still returns a (gray) value which is preferrable to a traceback)
opw-2352394
closesodoo/odoo#59498
X-original-commit: 6d6e48f34f850fa533ce00532ada0e3464c8144b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Galler <nicocrm@users.noreply.github.com>
Linearity is not always perfect, managing more template will sometimes lead to slighlty
more than a linear ratio randomly. The maximum observed ratio was 10.9.
12 seems a good value to catch non linear treatment while avoiding false positive.
closesodoo/odoo#59027
X-original-commit: 62610f7851f0994fc0864f2b95851ce8b5984ce7
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Was not super visible, especially without HR as the dialog immediately
closes (limitation of the web client), or when an administrator user
massively disables totp.
Show a toast notification indicating the success of the action.
Also fix the logging of `totp_disable` so it correctly handles being
called on more than one record, and change the logging data to
<browse_record> (<logins>) across the board.
Also add a way to provide an action to execute after a notification:
by default nothing happens, which leads to dialogs not closing and
forms not reloading, and there is no good way to show a notification
and/then do some other thing, which is inconvenient.
The document layout preview is a complete defferent simplified template
with its own css that replicates at best the different styles.
It does not have the external layout features and lack of fidelity.
The new preview actually use the real documents templates and put the
result in an iframe. It now has a high fidelity, though not perfect.
The goal is for a better onboarding, where clients see easely how
documents will look if they had an app to generate them. Of course, the
data on the document is a false invoice.
Refactor all this from base to web.
Task ID 2304177
closesodoo/odoo#56995
X-original-commit: c121a246f16899735306266a3a12b526e08e7620
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Assets bundle names have been changed in #48676 but QUnit.only uses check was
still using old names. This commit makes that check use the new names.
task-2274185
closesodoo/odoo#52687
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Before this commit and following the refactoring of the home menu and the control
panel to the Owl framework, some of the helpers of the 'clickEverywhere' test have
not been properly updated to the new classes/behaviours.
Now the selectors target the right elements and some actions that were previously
synchronous are now properly awaited (home menu toggling, filter menu interactions,
etc.).
Also slightly changed the behaviour of the clickAll functions:
- requesting a click on a null element will make the test crash (added some conditions
to avoid this in a standard flow).
- any error crashing the test at a deeper level will be displayed in the console
- an animation frame is awaited after clicking on an element. This is to comply
with the Owl rendering system.
closesodoo/odoo#47762
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Performances from a general point of view can be difficult to track.
This commit proposes to improve logs in two ways:
The current logs only use the sql_counter, wich will only be updated
when a cursor is closed. In a test-enable install, this counter
is actually the queries of the tests wince the install cursor is
open untill the end. The first fix is to use bot sql_counter and
sql_log_count to have total queries untill now on closed cursor,
but also the current number of queries of the current cursor.
This means that the new log format will be
{nb} modules loaded in {time}, {loading_querie} (+{test_cr_queries}) queries
instead of
{nb} modules loaded in {time}, {tests_cr__queries}queries
Nothe that in the current version, {nb} is actually the total number of
loaded modules until now.
This commit also add an equivalent end log by module and change the
loglevel of module start on install (mainly usefull if an error occurs
before anything else is logged hidding the module causing this error.)
A cleaner runbot logger is also added, in order to be abble to call
_logger.runbot( instead of _logger.log(25. This will clarify the purpose
of such a log level.
closesodoo/odoo#47283
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
The test clickEverywhere may last a very long time when all modules are
installed. For that reason, it's not a standard test and we run it at
night.
Unfortunately, it may happen that an App menu breaks and that this
failure is only spotted the next morning.
With this commit, a light mode is added to the clickEverywhere test. In
this mode, only the app menus are tested.
Also, two python tests are added that use this mode and are launched as
standard tests.
closesodoo/odoo#46934
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
A good practice is to always prefix the name of a template by
the name of the module it is defined in.
So in the case where a template
```xml
<t t-name="module.template" />
```
was inherited by another
Before this commit, one should have written
```xml
<t t-name="other" t-inherit="module.module.template" />
```
After this commit, it becomes more natural, and one should only write
```xml
<t t-name="other" t-inherit="module.template"/>
```
Before this commit, there were some tests checking
how long it took to compute a bunch of templates
Those asserted a time limit, which is undeterministic
After this commit, those performance tests
are not executed as standard anymore
Moreover, only asserts on ratios between computations is done
and deemed relevant.
closesodoo/odoo#43189
X-original-commit: 329fdf3961ea9e6eddbcba7a78d72102d2d08ac1
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, when doing a primary inheritance
the root node of the resulting template was the one of the inherited template
after this commit, the root node of the resulting template is the one defined
on the inheriting template
closesodoo/odoo#39452
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, when a template was inheriting from another
the template mentionned its t-inherit
This has been deemed overkill as the information is irrelevant to the caller
i.e. the caller just wants the template and doesn't care how they've been computed
After this commit, only t-name and attributes not related with inheritance
are disclosed
[FIX]: base: static inheritance propagates other attributes
When doing a inherit in primary mode, the original attributes on the root node of
the inheriting template were not propagated
After this commit they are
At the conception of this feature it has been intentionally thought that
the behavior for static templates should resemble
what is done for ir.ui.view
While keeping the general previous behavior (and this is important)
A little bit of context for ir.ui.view
They are defined as XML's, but end up as python objects
Their meta-data (id, name, inheritance specs...) are thus
present in their XML definition, but end up as part of python objects members
Hence, the final, business, usable arch is free of those meta-data
and is left only with business-relevant dom nodes
The static inheritance feature was backed with those ideas
but inherently encountered the issue that, for them,
the meta-data also end up in the business dom, since
they are at no point considered as plain objects.
Decision has been made, back then, to exclude the root node
that holds the metadata, to be at all targeted by any XPATH
This decision is now challenged as the specs of XPATH should be respected
This commit consequently introduces the root node as any other
It can be replaced, and will be targeted by
`expr="."` or `expr="//NODE_TAG"`
The few attributes that are necessary to define them are kept across
inheritance cycles though.
When loading a page on an existing starting database, registry is not
fully loaded causing potential error when trying to access model
existing in database (views, menitem, ...) since model added in last
loaded module does not exist in registry.
Thus, executing browser js test may lead to errors when executed during
an update on a database with other modules installed.
HTTPCase should be executed post_install to ensure that registry is
fully loaded to avoid this problem.
Since HTTPCase are slower than other test, it is also a good idea to
execute them at the end, in order to prioritize fast fail.
With this commit, a warning is isued if such a test class is tagged to
run at install time.
While at it, remove deprecated at_install and post_install helpers and
remove the deprecated phantom_js alias.
closesodoo/odoo#39462
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Have a parent template
Have a child, in extension inherit mode of the parent
The child has a xpath like
`<xpath expr="." position="replace" />`
Before this commit, there was a crash.
That was because the Comment
(which indicates which templates modified the parent)
was taken as the replacer node
instead of the actual content of the xpath
After this commit, there is no crash, and it works as expected
closesodoo/odoo#39453
X-original-commit: 02d790e1d21b78395e489f57bf30c82f728cbee6
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The nightly clickall runbot fail due to a crash of the underlying chrome
browser used to run the test suite. The problem is related to the
resources the browser is using. We leverage the problem by starting one
dedicated browser per app.
closesodoo/odoo#39190
X-original-commit: 228e57d980839bd2b4e9123bf26f8a64de2ae6ab
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Julien Castiaux