This commit improves the service API to allow the service creator
to mark some methods of the service as 'async'. This is a very
important feature when we consider the fact that a component calling
such a method may be destroyed before the asynchronous work is
complete. In that case, we do not want any code from the component
to be executed. Such async method, when called in a component (i.e.
when the service was obtained with the useService hook), will be
wrapped in such a way that the returned promises will not be resolved
if the component is destroyed.
Note that it only impact method calls for services obtained from the
useService hook, not calls for the actual service obtained from the env.
closesodoo-dev/odoo#886
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
The present commit reintroduces several number parsers that were previously defined in web.field_utils:
parseFloatTime, parseInteger, parseMonetary, and parsePercentage. Some minor simplifications in their API
have been brought. Notably, the "field" parameter has been removed. Indeed, we expect those parsers
to be used in more specific contexts than before so that the advantage of having a common API (value, field, options)
has become less important.
This commit renames the DebugManager to "DebugMenu", changes the
structure of its registry and the signature of its hook (useDebugMenu).
In the previous DebugManager:
- the "debug" registry was flat;
- new items were declared and created with the "useDebugManager" hook;
- these items were arbitrary functions returning a set of items.
The problem with that system was its extensibility, meaning that no
external module could hook on these arbitrary functions passed to the
hook.
In the new DebugMenu:
- the "debug" registry has multiple levels:
> root: "global" items, found in most debug menus
> subcategories: each subcategory has a name corresponding to the
context it's instantiated in (e.g.: the "view" subcategory will only
contain views-related debug menu items)
- all items are pre-declared in their corresponding category, and either
return a debug menu item or null;
- the hook activates/deactivates categories, and passes a context which
will be used by the item factories (passed as argument).
This commit adds some error types to have more accurate errors.
These types can be more easily found as they have an other name
than Error.
closesodoo-dev/odoo#885
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Before this commit, error handlers checked the error name to know if
they should be executed.
Now, they check the instance type of the error to be more accurate on which
error an handler deals with.
This commit also changes `emptyRejectionErrorHandler` sequence number
because it had more priority than `rpcErrorHandler` and `lostConnectionHandler`.
This commit, refactor the dialog api (dialog.js), to easier the creation
of dialog subclasses; force the use of dialog subclass when calling the
dialog service; forbid the use of dialog itself and promotes the use of
dialog subclasses.
closesodoo-dev/odoo#871
Related: odoo-dev/enterprise#151
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adds the useEffect hook, inspired by React. This hook
replaces the onMounted, onWillPatch, onPatched and onWillUnmount hook.
The idea behind useEffect is to unify the way we add side-effects to the
components lifecycle, while also making it easier to clean up those side
effects when needed. A lot of the time, when you want to do something
once the component is mounted, there is also a good chance you would
like to do it again when the component's state or props changes, in that
case you may also want to clean up things that you did on the previous
render. useEffect covers all these use cases and more.
The API is like that of React, with an important difference: the
dependencies of the effects is a function returning an array instead of
a plain array. This is because in React, hooks will run on every render
while in OWL, hooks are only run once during the component setup phase.
This means that in React, dependencies are computed on every render, and
doing that in owl requires having a callback to recompute them. Because
computing your dependencies can be expensive, the dependencies computed
by the callback will be passed to the effect function so that it doesn't
have to recompute them. (In React, since you're writing in the render
function, the dependencies are already in the effect's closure).
This commit adds jsdoc and typings to the dropdown components
and also rearranges a bit the code so it is cleaner and simpler.
Most part of the diff is about the keynav feature.
closesodoo-dev/odoo#802
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
- file is now ordered by clean sections
- `confirm()` helper has been renamed to something more appropriate
- `strftimeToLuxonFormat()` was manually cached. It now uses `memoize()` from `core/utils/functions`
- memoization of `stripAlphaDupes()` because it is prone to get called really often with same arguments.
- no more export `parseSmartDateInput()` as it is never imported elsewhere.
- remove unecessary `setLocale` call in `luxon.DateTime.prototype.toJSON` patch
closesodoo-dev/odoo#867
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Popover services:
- move bus from file scope into the service scope
- add "specializeForComponent" to add some logics when component is
unmounted
- parameters passed to the manager isn't stored in state anymore to
prevent props to be proxified.
Popover tests:
- remove a todo comment
- prettify template strings
- fix "Recompute position" test
Popover services tests:
- extract PseudoWebClient creation to lighten tests
- add test related to "specializeForComponent"
Doc updated
Before this commit, the router service used in tests was almost
entirely mocked and some of the mocked features didn't correspond to
their original counterparts.
Now, the actual router service is used in tests and the browser object
is mocked instead, allowing to correctly test the routing features.
Style using as much as possible predefined variables rather than
arbitrary values. Review status arrow buttons design and increase
overall text's contrast.
Style using as much as possible predefined variables rather than
arbitrary values. Adjust cards ':focus' state to match other
components and avoid misleading shadows.
Drop custom 'bg-X-full' classes since we can now achieve the same visual
result using default 'bg-X' classes (it was not the case with prev.
bootstrap versions).
Ensure text readability for both 'bg-X-light' and 'btn-link' classes.
Prior to this commit, Bootstrap dropdowns, jQueryUI dropdowns and Odoo
dropdowns where styled independently leading to visual inconsistencies
and code repetition.
This commit will customize and improve the Bootstrap design using as
much as possible predefined variables. Then it will simply '@extend'
owl/jQueryUI classes in order to visually match the bootstrap ones.
Since dropdown classes are used in the top-menu (and its design is
partially shared with frontend apps), this commit provides the necessary
adaptations for this component as well.
Mirror web_enterprise variables declaration to ease enterprise's
overrides. Reorganize variables in order to keep a consistent assignment
structure across versions.
This commit will also add '!default' flags in boostrap_overidden.scss,
allowing enterprise to reuse customization already defined in community.
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>
To prepare the rewriting of the webclient in owl, we move all
current js files of web in a legacy/ folder. This folder will
eventually be removed, as soon as each file it contains will be
converted to owl and moved to the proper place in the new file
structure.
Scenario:
- Go to Contacts
- Open a contact
- In "Contacts & Addresses" tab, add a child and configure its image
- Once child form is saved, image of the child is not displayed in the
kanban view used for children
It will only appear once the main contact form is saved.
The same issue occurs when editing a child image.
The new image will only be shown once the main contact form is saved.
The issue at the creation is due to the fact the function retrieving
the URL of the image tries to generate the URL from record id, which
is not set. It should use raw data of image in this case.
For the edition, it is due to the fact that the child form is changing
image_1920 field while the kanban view used for children is displaying
image_128 field. image_128 is a related field to image_1920, but it
does not appear in the child form. It is therefore not recomputed (by
onchange) when image_1920 is modified. Adding it in the child form view
solves the issue.
opw-2516188
closesodoo/odoo#72375
X-original-commit: 7eac23573c77415c84cb9c234c8063d4c68be425
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Also make this a configurable value, from the server.
This is the limit of the SAAS servers.
closesodoo/odoo#72143
X-original-commit: bcd1c8aade6123dd20d7aebaae8a0f204f258604
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
This is a temporary fix, it needs to be fix properly in future.
It was working properly with HTML reports but when it is render with
wkhtmltopdf it does not apply padding on left. Due to which issue is occuring.
Task id: 2499504
X-original-commit: 2958c8d08f4bdab94ba55fc944db6d314fb3fa43
In this commit we have added new method name isHtmlEmpty in
kanban view. As we are convertting text field to html field,
we will need to check html field in if conditions.
As Html field will contain tags we cannot check it every time
perfectly. So, we need this method to make sure html field is
empty or not.
Task id: 2499504
X-original-commit: 2968dcea7fb58795eeb34949f4bbfc1029938cd1
The `Configuration > Odoo Payments > Account Configuration` menu entry
leads to an external page and must be blacklisted in the click_all test.
closesodoo/odoo#71651
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.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>
This commit adds tooling to profile performance and save execution by
saving stack traces and queries to a file/database in specific format.
----------
Collectors
----------
For now, three different profiling modes (aka Collectors) are available
even if a last once should be introduced by @Gorash to profile qweb
execution.
- SQLCollector (or 'sql'): Saves the current stack trace and the query
every time Cursor.execute() is called. Any query executed on the thread
will be collected, no matter the cursor.
- PeriodicCollector (or 'traces_async'): Saves the stack trace every
'interval' seconds using a parallel thread to profile the caller thread.
The python implementation was optimized to minimize impact on
performance while remaining portable and easy to enable/disable
inside a odoo execution. Higher the frequency (lower the interval),
more impactful the profiling will become on the execution and increase
memory usage. From last experiments, 1ms looks to be a good minimum for
short executions.
- SyncCollector (or 'traces_sync'): Saves the stack trace every function
call/return. This collector is obviously quite impactful on performance
and can quickly overload the memory for long executions, but this is
quite useful to understand the precise path followed by some short
executions. Any time related information will be almost irrelevant with this
collector.
A base Collector defining minimal collectors features can easily be
extended to create custom collectors if needed.
----------------
Profiler & Usage
----------------
Collectors are not supposed to be used by themselves, but should be
given to a Profiler. The Profiler will synchronize collectors starts and
stop, and manage saving them to a file of in a ir_profile in the
database.
Exemple of usage:
```
with Profiler():
do_stuff()
```
This simple example will use the default collectors (sql and
traces_async) and save them to the database. The database is defined
automatically from current_thread 'dbname' if available.
Example of usage:
```
with Profiler(collectors=['sql'], db=False, path=/home/user/logs/do_stuff_profile/{time}):
do_stuff()
```
This more complex example disable the default behavior consisting
to save to the database, gives a path where the profile will be saved
and specify to only use the 'sql' collector. Note that
collectors=[SQLCollector()] would have the same behavior since
Collectors can be either a Collector instance or a string describing the
desired collector. This allows to define custom params for the
collectors and use custom collectors if needed.
Note that it is always possible to get results after execution without
saving it since they are available on the profiler.
```
with Profiler(collectors=['sql'], db=False) as p:
do_stuff()
print(len([None for entry in p.collectors[0].entries if ...]))
```
Profiler will also save the stack below the profiler start point, and
collectors will only collect the part of the stack over this stack.
This is a good way to reduce collectors CPU and memory usage.
Collected entries will be saved as follows:
```
[{
'start': 2.0,
'context': {},
'stack': [
['path_to_file', lno, 'func_name', 'line_content'],
...
],
},
...
]
```
SQLCollector will add three additional keys on each entry:
- query (query without parameters)
- full_query (mogrified query with parameters)
- time (the 'exact' execution time of the query)
----------------
ExecutionContext
----------------
A last tool, ExecutionContext, allows to define some context on some block of code:
Example of usage:
```
def process_modules(modules)
for module in modules:
with ExecutionContext(module=module): # note the 'not linter frienldy but still convenient' 2 spaces indentation
do_stuff(module):
```
This context will automatically be added in the stack as a virtual frame between
process_modules and do_stuff in order to split do_stuff from one single frame to
one frame per module.
----------
Speedscope
----------
The saved data are in a simple json format easy to analyze, but can't be visualized in
speedscope as they are. A utility class `Speedscope` can be used to generate a format
readable by speedscope. The used format is actually the format defined by speedscope,
meaning that all features should be available using it.
The output format is evented, meaning that we need to transform a list of samples
(a list of stack) to a list of event (going in/out a frame).
This is the main task of the Speedscope, as well as combining samples from different
sources, to display SQLCollector and PeriodicCollector results mixed together.
When stored on an ir_profile, the default speedscope generation can easily be generated
with the speedscope computed field.
This class can be used as it is but will mainly be useful for the next commit.
Special thanks to @rco-odoo for the in depth review and @Gorash for support.
Description of the issue/feature this PR addresses:
It is currently quite difficult to differentiate users. Most of the time, people
don't take the time to upload an actual avatar so everybody looks the same. This
PR generates a custom avatar with the users initials and random color to
differentiate them. For res.users, res.partner and hr.employee, image fields now
hold the binary image and avatar are used to show the image or svg.
Current behavior before PR:
Avatar had only random colors and was being saved in database, being inefficient
Desired behavior after PR is merged:
A new mixin defines image fields and in case no image is set, it generates an
SVG image with the user's initials and random color.
closesodoo/odoo#69819
Task: 2404630
Related: odoo/enterprise#18199
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, the multi edition of a field using the daterange
widget wasn't really handled: only the field that was used for doing
the change (i.e. only the start or end date) was actually saved.
With this commit, the multi edit feature now supports the case where
editing a field actually triggers changes on other fields. All those
changes are displayed in the confirmation dialog.
Task 2555178
closesodoo/odoo#71545
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Géry Debongnie