*: tools
The ImageOptimizer option can now set shapes on images to use those
shapes as clip path and background. It uses a flexible path so that the
shape will always fit the image proportionally. We also added an html
file alongside a javascript file to semi-convert the shape from
illustrator into a usable shape for this usecase (the clip path must
have values between one and zero therefore we must do some computation
before the shape is ready to use).
Thanks to Samuel for this specific shape-converter tool and other
technical points about svgs and clip-paths.
Thanks to Mehdi for remaining development post-testing and post-reviews
and for the many fixes.
Thanks to Brieuc for the actual shape SVG files.
Part of https://github.com/odoo/odoo/pull/69179
task-2327045
closesodoo/odoo#69179
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: xO-Tx <mou@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Before this commit, menus in navbar and clickable elements on the home
menu were not openable in a new tab through a ctrl-click or through the
middlemouse button.
In order to achieve that, we now use default behavior of <a href/> elements.
As such default behaviour would conflict with <DropdownItem/> clicks,
a global click handler is added in the WebClient constructor which stops
the click event propagation under these specific circumstances
(ctrl-click inside an <a href/> element).
Besides this work, it has been found that the <Dropdown/> root element
should not always be a <div/> as it was, but sometimes it has to be
another HTML element in order to comply with the W3C specs. E.g. a
<Dropdown/> component as a first level child of an <ul/> element must
have a <li/> root element instead of a <div/> one.
Thus, a new prop is added to the <Dropdown/> component (`tag`) allowing
the developer to choose another root element: `<Dropdown tag="'li'"/>`.
closesodoo-dev/odoo#913
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Adapt breadcrumb 'current' entry color according to its context.
If other entries are visible and clickable, 'current' will be muted
(default). If 'current' it's the only entry, then it acts as view's
title and it will be styled more prominent.
This commit splits the 'getActionManagerTestConfig' helper into 2:
'setupWebClientServiceRegistry' and 'getActionManagerServerData'.
The first one is now automatically called by the 'createWebClient'
helper, as it properly setups the service registry with all services
required by the WebClient component.
The second one generates a few data (menus, actions, views...) that
can be used in tests. That helper is mainly useful for action tests
(formerly ActionManager tests) in web. With this refactoring, they
are no longer generated for each test in the whole codebase that
spawns a webclient, as before this commit.
closesodoo-dev/odoo#906
Related: odoo-dev/enterprise#161
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit adapts the community codebase to the rewriting of the
/web application in owl.
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>
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>
Provide an opt in js tooling system by adding a node env with prettier and eslint configured.
3 bash scripts are provided: enable.sh, disable.sh and reload.sh.
Enable.sh: add to the community root (and optionaly to the enterprise root) the env.
Disable.sh: remove the env.
Reload.sh: disable then enable.
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>
- Change an image option in mass mailing editor (e.g. Quality)
- save
- edit -> The option can't get the new applied value.
The body_arch's field used in mass mailing editor is
sanitizing attributes and as a consequence, option related data
attrs are removed on save.
task-2327045
closesodoo/odoo#72311
X-original-commit: 7c5666611363a73bc6fef070565039cf065a0176
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Until now, when you create a view of type qweb with a model, we use the model
as first part to generate the key. Since this model can contains dot, it is
wrong and we got some key like ir.ui.view.gen_key_xyz
This bug has been seen with commit ee8756b311
which make the installation of website & sale_timesheet impossible in dev mode.
File /home/odoo/addons/base/models/ir_ui_view.py, line 294, in _compute_arch
arch_fs = get_view_arch_from_file(fullpath, xml_id)
File /home/odoo/addons/base/models/ir_ui_view.py, line 166, in get_view_arch_from_file
module, view_id = xmlid.split('.')
Too many values to unpack
Now we never try to make key beautiful. At first view it doesn't bring any
advantage, but only bug.
closesodoo/odoo#72238
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
When computing the foreign key name,
`check_foreign_keys` didn't take into account the limit of 63 characters
for constraint names.
Because of this, some constraints were dropped and recreated
over and over while they were correct, during install and upgrades.
For instance, when installing `base`
when adding the foreign key for which the name was computed
`base_partner_merge_automatic_wizard_res_partner_rel_base_partner_merge_automatic_wizard_id_fkey`
Postgresql created the constraint under the name
`base_partner_merge_automatic__base_partner_merge_automatic_fkey`
and therefore, as the name did not match,
the constraint was dropped and re-created.
closesodoo/odoo#72234
X-original-commit: 43a4738ebf8a74a389b99f8f58330b3044beaa0c
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The commit e123aa2f30 optimizes the call
to fields_get() made in the NameManager to post-process the combined
arch of a view. The optimization consists in avoiding translations,
with the assumption that the result is only used for validations. It
turns out that the regular post-processing actually returns the field
descriptions as part of the result of fields_view_get().
We fix this mistake by keeping the optimization only when the flag
'validate' is true, so that the regular post-processing of a view
returns field descriptions with the expected translations.
closesodoo/odoo#72216
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When a view is created/modified, it is required to validate it, the
validation checks the syntax, the inheritances, the fields, etc. When a
view is rendered there are a few more steps to perform like to (dis)able
the `edit` button from a view form if the user only have `read`
accesses. Those postprocess are useless when the view is validated and
should only be performed when the view is rendered.
closesodoo/odoo#68469
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
This is a pure technical fix, computing `view.xml_id` is only needed
when there is a problem with the view. Computing the `xml_id` is not
free, as it needs to be retrieved from the database. During a regular
installation, there should be no problem, the view is validated without
errors or warnings.
By default, whatever is written on field 'arch' is handled by its
inverse method inverse_arch(), which writes on the low-level field
'arch_db'. When writing on 'arch_db', the cache is cleared, which leads
to performance loss because the arch needs to be re-fetched.
This optimization bypasses the inverse method on view creation, this is
safe as there is nothing wrong in the cache and makes view creation 20%
faster, and installation 7% faster.
The `mode` field in used in `_combine` to distinguish `primary` views
from `extension` ones. The field has been retrieved as part of the query
done in `_get_inheriting_views` and manually placed in the cache so the
ORM doesn't perform an extra query just to retrieve the mode.
Using our benchmark (render_all_views test tag, website_sale, mrp,
contacts, crm and timesheet installed), the reported time was 18.46s
with 17890 queries performed without this improvement, it is 17.82 with
17340 queries with.
Closes#72096closesodoo/odoo#72127
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
`NameManager`'s validation passes should not be language-dependent.
Fetching translated model and view information thus incurs additional
costs for no reason. Ensure translations are never enabled for
`NameManager`'s work.
In our benchmarch (py-spy with a rate of 200, render_all_view test-tag
and website_sale,mrp,contacts,crm,timesheet installated), 20% of the time
was spent in `NameManager.__init__` and thanks to this change it is
reduced to 11%. Queries count from 19995 to 17886. Total runtime from 24s
to 21.5s.
closesodoo/odoo#71419
Task: 2463632
Related: odoo/enterprise#18596
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
The post-processing of a view was implemented as a recursion, the
processing of every XML node recursively processing its children nodes.
Recursion inside flamegraphs scatters sub-calls at many call depths,
which makes their analysis less obvious. Transforming the recursion
into a loop with a stack makes the code more profiler-friendly.
Task: 2463632
The parsing of the values of attributes `attrs`, `states`, `invisible`,
`readonly` and `required` is done many times during the post-processing
of a view. The functions `ast.literal_eval` and `safe_eval`, although
being pretty cheap, are called so many times that they represent about
10% of the time spent in `field_view_get()`.
The variables of the function were poorly named, we take this commit
opportunity to rename them: `a` => `attr`, `v` => `value`.
After analysis of what was evaluated, it turned out that 95% of the
expressions safe-evaluated were '1', '0', 'True' and 'False'. We
introduced the special cases to quickly bypass the evaluation and speed
up the rendering.
Using our benchmark (render_all_view test-tag with website_sale, mrp,
contacts, crm and timesheet installed) the runtimes are 27.58s without
this commit and 27.45s with.
Task: 2495504
The view methods `get_inheriting_views_arch`, `apply_view_inheritance`,
`_apply_view_inheritance` and (previously `read_combined`)
`_get_combined_arch` were complicated and not optimal performance-wise.
The previous approach to retrieve views and combine them was to perform
it recursively, one primary view at a time. This new approach retrieves
in a single SQL query the whole tree of views to combine. The order of
view combination has been reproduced to be fully backward-compatible.
We also introduced various optimisations such as pre-fetching and
caching.
**get_inheriting_view_arch**
The method have been renamed `get_inheriting_views` as it returns a
recordset of views instead of the xml architecture of each view.
During an upgrade, only the views that have been fully upgrade already
are safe to be used. The views returned by the query are filtered to
remove any not-upgrade-yet view. Because this part is highly specific,
it has been isolated in a dedicated private method.
View extensions can be discarded according to user groups. The
retrieval of groups on views is also made by the same query. This
reduces the number of SQL queries, and makes the filtering faster.
**apply_view_inheritance**, **apply_view_inheritance**
The functions were responsible to build a hierarchy of views and to
iterate it to combine the views.
The hierarchy building have been moved to `_get_combined_view` and the
actual combination have been moved to a new method `_combine` and
documented.
Task: 2541579
Meta task: 2463632
Co-authored-by: Fabien Pinckaers <fp@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
The method read_combined() has been deprecated in favor of explicit
calls to read() and get_combined_arch().
There are places where we call _get_combined_arch() instead, in order to
avoid parsing the XML that has just been serialized. This saves useless
serialization-deserialization.
Task: 2541577
Meta task: 2463632
Co-authored-by: Fabien Pinckaers <fp@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Extract architecture combination out of `read_combined` to work on
`etree.Element` exclusively: since `read_combined` returns a serialized
`arch`, its own recursive calls as well as callers needing to
post-process the architecture have to re-parse the `arch` then serialize
it back.
This is wasteful and can be avoided by providing the `arch` as an
`Element`, which is what `_get_combined_arch` does.
The public method `get_combined_arch` is provided as convenience: it
basically wraps a call to `_get_combined_arch` and returns the result as
a string.
Task: 2541577
Meta task: 2463632
Co-authored-by: Fabien Pinckaers <fp@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
A test that calls fields_view_get() on all models while measuring its
performances. Use it along with py-spy and load the generated file in
<https://www.speedscope.app/>
py-spy record -F -r 200 --format speedscope -o speedscope.json -- \
python3 odoo-bin -d <db> --test-tags render_all_views --stop-after-init
Task: 2463632
Co-authored-by: Raphaël Collet <rco@odoo.com>
Currently, in My Profile all the users have access to language settings
even when the user does not have the rights to activate/deactivate
languages. Also, the language setting list is not user friendly which
needs to be imporved.
so in this commit hide "More Languages" button in My Profile for users
that does not have the rights and the language settings list is
improved by adding seperate buttons to "activate", "disable" and "update" a
language.
PS: groups does not work on My profile so added the compute field based
on group.
closesodoo/odoo#69292
Taskid: 2466771
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Replace text fields to html fields as we have our own 'OdooEditor'.
Indeed, it gives more options to users in the way they format their
content without weighting too much on the UI
(tools appear on demand and not by default).
In this commit we replace report_footer and report_header field of
"base.document.layout, res.config.settings" model as
they are related fields of res.company models field
report_footer, report_header.
Task Id: 2499504
X-original-commit: 4c474d0d2055efe81fdc21502aa5957fe80af7ef
Before this commit there were few cases in which
is_html_empty method was not working as our expectation.
In cases such as "<p class=""><br/></p>", "<p id=""><br/></p>"
and many other cases.
In this commit we improves regex of is_html_empty method.
Mow from this commit all kind of attributes will be consider
in this method.
In this commit we also have added is_html_empty in mail template, portal
values and in report values also for rendering templates.
Task id: 2499504
X-original-commit: fd0a05f2955b9f7e9ae7233afebfd6240c9244dd
Entry count can be useful to estimate the size on disk of a profile
file.
The entry count would be quite expensive to compute and thus should be
stored. It is impossible to use a compute stored in this case, since
ir.profile shouldn't have any "business" logic upon insert.
closesodoo/odoo#71673
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Even if only accessible when writing some custom code, the path option
of Profiler looked a little dangerous from a security point of view,
since this option allows to write the result of the collector anywhere.
This shouldn't be a problem, since Profiler shoudn't be accessible
inside a safe_eval() and the path param cannot be user defined, but this
is still a risk.
An alternative option would have been to give a file descriptor instead,
so that the user must have access to `open()`, which is unlikely inside
a server action. This alternative has some disadvantages, though,
because the file descriptor should be given when creating the profiler,
or at least before `__exit__()`, removing the possibility to add the
number of entries in the filename.
This commit proposes another solution: add a generic way to output the
profiler as a json text. The result can thus be saved the way the
developer chooses. A utility method format_path() will help to format
path the same way the profiler did before this change.
The usage of an additional optional context manager leads to the usage
of ExitStack. Unfortunately, this changes the initial format quite a
lot, decreasing readability and adding a loop on context managers, even
if there should be only one most of the time (request).
This commit proposes to a nesting utility for the profiler, allowing to
nest another context manager inside a profiler.
This solution allows an easier integration into http.py, avoids to
manage the "enter_context" case when recovering the init stack and can
be useful in other cases.
Improvement of get_dispatch_context_managers conditions and styling:
- Check profile expiration very first.
- Add an additional check for odoo.evented. Profiling will crash on an
evented server. Only longpolling should use evented servers, it but
this is more future proof.
The common mistake of method instead of method leads to the parameter being ignored.
Add a warning to ensure no other controllers are defined this way
closesodoo/odoo#71571
X-original-commit: d0048ef115985a24eec1e47ceb146f4a98f71b38
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Currently, to identify records based on state, in most of the list views we
use 'badge' widget on 'state' fields which can be decorated as needed.
However, for the list views, best approach would be to also add list
decoration along with 'badge' widget so that the whole line is colored
and it's easy for user to 'scan' the information
This commit improves the behavior adding decorations to several list-views.
To check the list of changes, kindly see the task specification
Apart from that, this commit also improves label of the module state from
'Not Installed' to 'Uninstalled'.
TaskID-2527119
closesodoo/odoo#71367
Related: odoo/enterprise#18587
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit add tests to ensure every dispatch flows redirect to a 301 if the
requested URL has a trailing slash.
It also ensures the URL params are not lost in the process.
- Basic controller: `/my/?a=b`
- Website Pages: `/my-page/?a=b`
- Basic controller with language: `/fr_BE/my/?a=b`
- Website Pages with language: `/fr_BE/my-page/?a=b`
- Homepage with language (special case/controller): `/fr_BE/?a=b`
opw-2505818
opw-2513575
closesodoo/odoo#71065
Community: https://github.com/odoo/odoo/pull/71065
Enterprise: https://github.com/odoo/enterprise/pull/18615
Related: odoo/enterprise#18615
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
What are the steps to reproduce your issue ?
1. Create new contact
2. Set compagnie type as Individual
3. Set address type as Contact
What is currently happening ?
Address label is shown as "Company Address"
What are you expecting to happen ?
Show "Address" in case of Individual company type
opw-2504878
closesodoo/odoo#71618
X-original-commit: 0248f1735c31d039446f2a7f25148dcb99c09153
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.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.
Before this commit, `get_base_url()` could not be called on an empty recordset.
It might be called on an empty recordset for instance when getting the paypal
payment endpoint URLs.
This commit allows that and returns the ICP value in that case.
The goal is to always use the util method `get_base_url()` instead of directly
accessing the ICP.
closesodoo/odoo#68201
Related: odoo/enterprise#17538
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
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>
In order to be able to add a button to activate contextual merge action on the
target model, the ir.model form view had to be adapted to add the header.
Task ID: 2459416
ENT PR: odoo/enterprise#16975
PURPOSE
Have an overview of the current status of a project and keep track of its progress. Share with other stakeholders where the project stands. Identify risks and opportunities and act on them accordingly.
SPECIFICATIONS
1) Status in controlpanel + access rights
- Indicate the status of the project next to its name in the controlpanel clicking on the status should open the updates kanban-list
by default, the status should be 'on track'
- users with the project > user access right level can see the status of the project
- users with the project > admin access right level can read, write, create, delete updates
2) Project Updates
- Project updates are defined with a name, Author, date, progress and description.
- The description is build based on project data, timesheet related to project and project profitability.
3) Project Updates Kanban View
- The kanban is a kanban list view with a right side panel.
- The right side panel displays various information about project
- It's possible to create milestone from the project update right side panel.
4) Project form view
- The milestone and update lists are accessible from the project form stat buttons
task-2393768
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#68899
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
This commit aims to add a button in the control panel to easily display
the current project update status.
This is done by extending ControlPanel Component and template.
We must add a context value `show_project_update` to enable the
button in the breadcrumb and it's done only once; e.g. when we click to
see all project tasks of an active project.
The button redirects to a kanban list view of the project_updates.
The activity rng is modified in order to accept js_class definition.
Following commits will add behaviour to handle those updates and
milestones in the various views. See PR for further information.
PR : #68899
task-2393768
When invoking onchange() on a line in a one2many field, the inverse
many2one field is given as a dict of values. Those values are the ones
of the "container" record in the form view, and they include the "id" of
the container record. The method onchange() instantiates the container
record as a new record with the given values. Fix the code to set the
expected "origin" of that record to the record with the given "id".
closesodoo/odoo#71491
X-original-commit: ebfb5d90fd4ff65ee1d2fc73faf8f9eaa18f4521
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
