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>
Before this commit, some views appeared broken on mobile.
We don't consider this as a bug because Odoo is not supposed
to be responsive in Community edition. This feature is only
available on Enterprise.
This commit aims at clarifying this situation by clearly moving
the base requirements to support browsers' responsive to the
Enterprise edition and stating that the Community edition only
targets desktop.
It's important to note that, for technical reasons, some
responsive-related JS/CSS code may still be present in the
Community codebase but they are not meant to provide any
explicit or implicit support for responsive/mobile devices.
Technically speaking, this commit removes the viewport meta tag.
This change will then force the "desktop-like" rendering even on
small screens for the Community edition and will keep the current
behavior (scaling/zooming on small screens) for the Enterprise edition.
By doing this we do not let the users think that something is broken
and must be fixed.
So,
in Community edition, desktop is always displayed;
In Enterprise edition, Responsive Web Design is available.
We also had to adapt a test to be able to apply XPath adding
viewport meta tag in enterprise.
Task ID: 2090202
When exporting a grouped list view with some nested groups, the aggregate value
of parent groups are not correct. It always sums aggregated values of children
whether the group operator is 'sum' or not (could be 'max', 'avg', ...).
This behavior is wrong and can even lead to a crash if the aggregated field is a
date field (e.g. with group_operator='max'). (Try two sum two dates...)
The quick fix 85cf47f was merged just before OXP to avoid any crash. This fix
limited the support of aggregates to only int and float fields.
This commit remove this limitation.
This commit correclty implements the aggregation for parent group for all
field types and all group_operator.
This commit also improves the export feature tests.
X-original-commit: 5e7e4fa98698967e3c4fd0903f4aa8e91981a6cd
Purpose
=======
The commit 2849b5c introduces a new export mechanism of grouped
list views to xls files.
The issue with this development is mainly that the displayed records
are exported, instead of all the records that match the search
parameters.
To export all the records we cannot rely on the data from the web
client. This implies to revert 2849b5c, and implement it in a better
way.
Functional Spec
===============
Add the support of grouped exports.
Allow the user to export all records in one click from
the listview, without having to go through the export modal,
taking into account the domain, groupbys, and visible fields.
Technical Spec
==============
When exporting (whether it is from the modal or from the shortcut),
any groupby(s) set on the listview should be taken into account (all unfolded)
- UNLESS the export is import-compatible
- each subgroup header has an indentation compared to its parent
- the 'group headers' in the exported file should contain the
same info (label, field aggregates) as it has in the listview.
New secondary button on the tree view with label 'EXPORT' (to be confirmed...)
- the export shortcut disregard the selected records, it exports all records
according to the domain.
- the button is visible even if there is no selected records.
- essentially the export shortcut does the same thing as the following:
- select all records
- hit 'action' then 'export'
- hit 'export'
Define a boolean attribute on <tree> to specify whether or not the export
shortcut should be displayed
Task 2072910
closesodoo/odoo#37087
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
=======
Add the support of grouped exports.
Allow the user to export all records in one click from
the listview, without having to go through the export modal,
taking into account the domain, groupbys, and visible fields.
SPECIFICATION
=============
When exporting (whether it is from the modal or from the shortcut),
any groupby(s) set on the listview should be taken into account (all unfolded)
- UNLESS the export is import-compatible
- each subgroup header has an indentation compared to its parent
- the 'group headers' in the exported file should contain the
same info (label, field aggregates) as it has in the listview.
New secondary button on the tree view with label 'EXPORT' (to be confirmed...)
- the export shortcut disregard the selected records, it exports all records
according to the domain.
- the button is visible even if there is no selected records.
- essentially the export shortcut does the same thing as the following:
- select all records
- hit 'action' then 'export'
- hit 'export'
Define a boolean attribute on <tree> to specify whether or not the export shortcut should be displayed
Task 2072910
There are too many image sizes. Since they are stored resized this takes time to
generate when saving a new image, it's more rows on the attachment table, more
files on the disk, ...
64px is close enough to 128px that it can be removed without a big impact on
download size.
It will even reduce download and number of requests when both images are
displayed because now only one has to be downloaded and then benefit from cache.
The difference between the two is typically around 1.5kB which is negligible
these days, especially when the request overhead is around 0.5kB already, not
even taking into account other factors such as latency.
If a 64px image must absolutely be returned, it is still possible to pass the
size parameters to the image route. But the current guideline is to handle
resizing in the views when necessary.
Views
=====
- remove width and height attributes when existing CSS rules are overriding them
(eg. `.oe_kanban_avatar` in the right context)
- add CSS rules instead of width and height attributes when possible
- use `object-fit: cover;` where width and height are forced to avoid distortion
of non-square images
- for products, use `object-fit: contain;` instead, keep ratio but without crop
- add new CSS rules where the expected size was max 64px*64px before due to the
image size itself
- remove `img-fluid` where using size classes to avoid conflicting rules
task-2060865
closesodoo/odoo#36147
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose
=======
Have a quick export feature.
The current export wizard is quite complex.
We want to be able to quickly export a tree view,
with the group by correctly represented, depending on the fields
visible in the list view.
Specification
=============
Add an "EXPORT (XLS)" button in the list view (a little download icon)
- export only columns visible in list view
- export all the records
- while respecting the group by
This should be a generic feature but should be applied to all
the account.move.lines list views.
account.view_move_line_tree_grouped_sales_purchases
account.view_move_line_tree_grouped_bank_cash
account.view_move_line_tree_grouped_misc
Task 2031835
closesodoo/odoo#36943
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
image_original => image_1920 (now resized to 1920)
image_big => image_1024
image_large => image_256
image_medium => image_128
image_small => image_64
image replaced by image_1920 (when writing) or by image_1024 (when displaying
what was previously the big size)
+ add new intermediate format:
image_512
PR: #34925
QWeb templates that show up in the 'qweb' key of a module's manifest
now support server side inheritance and xpath evaluation
QWeb templates that show up in the xmlDependencies of a JS widget are not
impacted at all by theses changes, as they are served through the
Werkzeug sharedMiddleware
A similar syntax than ir.ui.view has been implemented in the QWeb templates
- each template must have a root node, whatever tag works
- the root node of a template must have a t-name containing the name of the template
The name -- without the module's name -- may contain dots pretty much anywhere
Though what is recommended is only underscores in template names
- if a template is to inherit from a parent, the root node has a t-inherit directive
containing either the full name of the template it inherits from which is module_name.template_name
or the name of the template, no module name necessary, if the parent template is in the same module
- there are 2 modes of inheriting
primary: copy the behavior of the parent into the template
extension: modifies the parent in place
Task: 1999528
closesodoo/odoo#33892
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Add the support to be able to specify exlicitely module, class and method name in test_tags
Before this commit, there is no distinction between module tag and test tag. Meaning
that --test-tag module_name will replace the default +standard tag and execute all test
of the module.
This commit tries to keep the initial behaviour, while addind new features, like explicit
modules tag with /module_name, as well as class (:class) and method (.method)
Some usage examples:
--test_tags /module will execute all standard test of module
--test_tags :class will execute all standard test with class name 'class'
--test_tags .method will execute all standard test with method name 'method'
--test_tags external/module will execute all external test of module
--test_tags */module will execute all tests of module,
--test_tags */module,-standard will execute all non standard tests of module,
--test_tags -/website:TestUiTranslate.test_admin_tour_rte_translator will disable only rte translator test
closesodoo/odoo#34756
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit, the No Change status wasn't properly set because
the `filehash` wasn't passed to `_binary_set_headers` and because
the status was not changed to 304 if it was already set to 200 earlier.
This commit fixes this issue and also prevents images to be processed
in `content_image` if the status is 304.
opw-2008426
closesodoo/odoo#34032
Signed-off-by: Christophe Simonis <chs@odoo.com>
* = website_partner, website_profile, website_sale, website_slides
Before
======
Since commit: 2e3848b394
The images that are resized have additional borders if the target ratio is
different than the image ratio. Those borders are transparent if the image
format supports it, and are white otherwise.
With that current solution, if the background where the image is displayed is
another color than white, it is looking really bad.
Moreover, most images are stored resized like this, so it is not even possible
to decide if it should have borders or not depending on the context, the
original image and ratio is forever lost.
It is also inconsistent because if the image is already smaller than the target
size then it doesn't include borders. In that case it keeps the original ratio
instead of the target ratio. So it isn't even guaranteed that the target
ratio is going to be respected.
After
=====
This commit will solve all of those problems by always keeping the ratio of the
original image.
This implies the views should be taking care of adding borders when necessary.
task-1958000
PR: #31811
