This commit adds a new attribute mode for position 'replace' to the xpath feature.
This mode can take 2 values:
- 'outer' (default mode if not provided) that will replace the sibling target
- 'inner' that will preserve the sibling target
If base arch is:
```html
<p>
<field name='x'>yyy</field>
</p>
```
`<field name='x' position="replace" (mode="outer")>zzz</field>`
```html
<p>
zzz
</p>
```
`<field name='x' position="replace" mode="inner">zzz</field>`
```html
<p>
<field name='x'>
zzz
</field>
</p>
```
Mode inner is useful for theme or render flat content, but not recommanded to
be used in page editable since we ignore the inherit-branding part until now.
task-2172208
closesodoo/odoo#48679
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Okan SUMER (osu) <osu@odoo.com>
Co-authored-by: Jérémy Kersten <jke@odoo.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this commit branding was removed only from nodes using t-esc and
t-raw.
This caused problems such as the ribbon preview rendering being
propagated across all products because the oe-model/id/xpath fields were
referencing the product card view itself.
This appeared because of the conversion from t-esc/t-raw to t-out.
The branding used to be removed from nodes using t-esc and t-raw, but it
was not removed for t-out.
After this commit the branding is also removed from nodes using t-out.
This restores the old way the ribbon preview was rendered, and therefore
also fixes the issue described in the related task.
task-2527056
closesodoo/odoo#74145
X-original-commit: 9e83dd83a39b542ec0e0d3045bcffcf24406c94b
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
PURPOSE
This commit aims to improve the 'Contact Tags' sections of the 'Contact'
module by adding a color picker (on the list and the form view).
SPECS
- Add a color picker on the 'Contact Tags' sections (i.e: list and form view)
- Add a placeholder for the 'name' field of the form view.
- Update the label of the 'color' field.
LINKS
Task id: 2608410
closesodoo/odoo#74033
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
makes raw a bit more expensive than necessary on creation
closesodoo/odoo#74132
X-original-commit: f9b12a59ea618fa598f0ffb6869f027c6a39bc2d
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
`load_views` calls `get_bindings` to render Action and Print menu. Before this
update, it read all action fields, including heavy computed fields
like `search_view` (which calls fields_view_get). But in fact just few fields
are used.
This slighly improves response time and data size.
closesodoo/odoo#73983
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Define `data-hotkey` on most used action buttons.
For the modals, the following keys are dedicated for "special"
actions:
- Alt+G: add
- Alt+V: save
- Alt+Z: cancel
closesodoo/odoo#73275
Taskid: 2588233
Related: odoo/enterprise#19464
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This field was only used by thinking it was the banks owned by the
company, and not the banks registered for all partners by that
company.[1]
It has always been like that, since 7eab8e26d3
even though the field didn't exist on `res.company` before that
refactoring.
[1]: checked with the following regex `compan((y(_ids?)?)|ies)\.bank_ids`
closesodoo/odoo#73229
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Requires markup every markup-using tip content as Markup. Would be a
nice occasion to migrate everything to a markup-safe markdown I think,
especially if we could migrate the translations so we don't lose them.
Before this commit, the implementation crashes when the ancestors of a
record contain non-accessible records. This fixes the code to avoid it
to crash.
We also make the semantics of hierarchical searches more consistent in
this case: searching with operators 'child_of' and 'parent_of' returns
the subset of accessible records that satisfy the hierarchy operator.
We actually make it coincide with the results of the search when using
the "_parent_store" optimization.
closesodoo/odoo#73962
X-original-commit: 3e1b960acf3f6a726338476ba9e62e5ef5c84ef9
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit, some tests were indirectly using demo data.
For example `env['res.partner'].search([])` would return demo data in
addition to the partners created for the tests.
This commit changes that by ensuring that the records used are limited
to the records made for the tests. Some values have been adjusted to
account for the lower amount of available records.
closesodoo/odoo#72553
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit, if a related field's path definition contained a
non-existing field (either because of a typo or field removal) the ORM
would simply send a generic Python KeyError that didn't really help in
debugging.
With this commit, we raise our own KeyError stating which related field
has the wrong path definition and exactly which field within the path is
incorrect.
See test for an example.
closesodoo/odoo#31889
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Assigning to const variable is always a programming error, and we almost
never want to have a debugger in production code (for those cases, an
ignore comment can be added).
closesodoo/odoo#73821
Related: odoo/enterprise#19694
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adds a sanity check to the part of the ORM that uninstalls
module data, as a recap, here's how module uninstallation works:
- We fetch all data (ir.model.data) that corresponds to the module being
uninstalled (`WHERE module='my_module'`)
- We divide this data according to its type (ir.model, ir.model.field,
constraints, etc.)
- We fetch the corresponding records to each type, we delete them in a
certain order (e.g. ir.model.field before ir.model) and then finally we
delete the ir.model.data as a last step
The data is deleted in batch for maximum performance, if one of the data
cannot be deleted however, we perform a binary search until we find the
culprit(s) and we store these culprits in a list of undeletable_ids.
At the end of the process, we delete all ir.model.data **except** for
the ones that are undeletable, however, it is possible that because of
the multiple-step procedure, an undeletable ir.model.data could have
become deletable.
Imagine that an ir.model.field cannot be deleted, its module data id is
added to the list of undeletable_ids, however if later on its ir.model
is deleted successfully, the ir.model.field is dropped because its table
is dropped, in this case the ir.model.data becomes deletable, but since
we simply ignore it at the end of the process, we potentially end up
with orphaned xmlids.
This can be problematic when we reinstall the module and uninstall it
again, as the system does not expect an orphaned xmlid, will completely
crash and prevent the 2nd uninstallation of the module.
This is the case with CRM and its
crm.lead.scoring.frequency.field.field_id field, its ir.model.field
cannot be deleted because the name field (and display_name) of the same
model depend on it, so it is left as is, then further down the process
the entire model is deleted and as a result so is all of its remaining
fields, however the ir.module.data for the field that could not be
deleted remains.
opw-2575592
closesodoo/odoo#73668
X-original-commit: 75697934b34df882ec03595b876a8a6dadcef4c5
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
This branch adds request.redirect on all requests.
In case of a front end request, we do an url_for to the location.
We removed redirect_with_hash that was only for retro compatibility
local_redirect has been renamed to redirect_query, and param keep_hash has been
removed and moved.
Default code for redirect is 303 now instead of 302.
Now redirect and redirect_query make local redirect by default, you need to
pass local=False to make external redirect.
All werkeug.utils.redirect has been replaced by request.redirect.
Http.redirect now use an http.Response type, and it become easy to add an
override like 'set_cookies' e.g.
Dispatch of a website.page return an http.response too, so we first need to
check if it is a cached version before to check if it is an Odoo Response.
Migrate your code:
http.redirect -> request.redirect(location, code, local)
http.local_redirect -> request.redirect_query(location, query, code, local)
http.redirect_with_hash -> request.redirect
Courtesy of odony for help and review ;)
closesodoo/odoo#72599
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The use-case is when a "parent" field is put on the form view, as a
readonly field, and we create a new record. Before the fix, the fields
that depend on the parent record are always False, until the record is
actually created.
closesodoo/odoo#73446
X-original-commit: ff2af932c3b73dc59620a4ce17da3a13cab12cbe
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This allows onchange to recompute fields that depend on the inherited
field that has changed. The use-case we have is a model that inherits
from 'account.move'. On its form view, setting the (inherited) journal
field does not recompute the (inherited) company field.
When the field 'journal_id' is modified, the onchange should:
- assign the new value to move_id.journal_id (*)
- recompute move_id.company_id (related='journal_id.company_id')
- recompute company_id
This commit adds the missing part (*).
X-original-commit: 2e05d0a361aa06a34eecf64613821f2e92295298
The timesheet_grid icon changes when enterprise is present. This changes
the icon from base to the one from enterprise.
Closes: odoo/odoo#72336
Task ID: 2531317
It seems quite easy to have a void content in the currently new editor
that actually holds a lot of undesired information, notably a font
tag. This is annoying when having behavior based on an html field
being empty or not. In this commit we therefore improve definition
of an 'empty' html field.
Task ID-2532529
PR odoo/odoo#71793
This commit changes the warning log for Selection fields that states
that the hook could not go through the ORM for the deletion at uninstall
(because of some business error) and that it had to bypass the ORM (aka
pure sql delete) and turns it into a runbot-level log, meaning that it's
technically a warning but the runbot won't fail because of it.
This is done because for the install/uninstall tests it shows up as an
actual failure but it is not as it is non-blocking, and 99.9% of devs
won't ever see this warning on runbot since it triggers on module
uninstall anyway.
closesodoo/odoo#73332
X-original-commit: c140f545d150da05bd47f2c2dabc28c53cefe912
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
before this commit: create_text was passed in node options and due to which it
was not parsed by translate.py, pass add-label as attribute on field so that
translate.py parse it and it is translated.
after this commit: create_text will be passed as field attribute instead of
node options.
task-1923433
closesodoo/odoo#59713
Related: odoo/enterprise#19418
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
When an installed module is not installable, we don't want
to check its dependencies because they may not be available.
Erroring out on such dependencies is not needed because
the module will not be loaded anyway. On the contrary, such
errors prevent starting a database which would otherwise
function normally.
Such errors occur when doing incremental migrations where
it happen that addons are installed (from the previous version)
but not migrated yet and therefore not installable.
When we migrate lower level dependencies Odoo marks
higher level addons as "to upgrade" even if they are not installable.
That is usually harmless, except when such addons have
dependencies that are themselve not available.
This PR fixes that.
closesodoo/odoo#73206
X-original-commit: a11e8a32883b0d0deaeb2497daa585eb3d3c686e
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
This commit updates the res.currency data files to be compliant with
the ISO 4217 standard:
Add existing currencies missing from Odoo.
Remove currencies deprecated since at least 10 years.
Update incorrect currency names and rounding values.
task-2501384
closesodoo/odoo#69356
Related: odoo/upgrade#2400
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Domain terms of the form `('field', 'not in', [...])` generate incorrect
queries for translated fields, example (model `res.country`, field `name`):
```
psycopg2.errors.SyntaxError: syntax error at or near "ARRAY"
LINE 1: ...M "res_country" WHERE "res_country"."name" not in ARRAY['No ...
```
The root cause is that the right part of the term is not converted to
tuple.
Observed during the upgrade request 16639
opw-2525553
closesodoo/odoo#73030
X-original-commit: 7c4db97e21f74a429e56f6cae4d4786ee74f7e22
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
With commit odoo/odoo@83ffe8b we ensured that while creating a child contact, it
takes language from its parent by default if any, otherwise falls back to DB
lang.
The fix was done with help of `default_get` method. However after merge of
odoo/odoo#55995 `default_get` is now called through the onchange for o2m
fields. Now we don't get the default value of `parent_id` here which
re-introduced the bug.
This commit fixes the behavior by setting the language from onchange
while creating the child contact and thus (once again) making the
language from parent contact prevail on DB lang.
We also re-use default_lang coming from parent in form view, which partially
reverts odoo/odoo@83ffe8b .
TaskID-2416922
closesodoo/odoo#72960
X-original-commit: 4d9b85bd07e487e7843dc458332dede36c2889c2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* Objectives:
- Allow the generation of empty date/datetime groups outside the bounds
defined by the existing data during a read_group, with the fill_temporal
context key.
{[Jan - empty]->[Feb]->[Mar - empty]->[Apr]->[May - empty]}
This will allow to get a guaranteed amount of groups regardless of the
existing data.
- Request contiguous date/datetime groups between custom bounds which do not
cover the entire domain of existence (existing data)
[Jan] {[Jul]->[Aug - empty]->[Sep]} [Dec]
If some records were "forgotten" before the desired "interesting" period, we
won't have to display "many" undesired empty groups to show them.
* Implementation:
Modify the fill_temporal context key to accept a dictionary format,
with 3 keys, to be used in _read_group_fill_temporal:
1. fill_from
2. fill_to
3. min_groups
- (1., 2.) offer a way to guarantee that at least a certain date range will
be returned as groups. They are also the bounds to fill. Any group outside
those bounds will not be removed, but there will be no empty group added. If
any of those keys is omitted, existing bounds are used, if applicable. If
fill_from and fill_to are not specified, and there is no data, no group is
returned.
edge case example:
existing dates: [Jan, Sep]
fill_from: [Apr]
fill_to: [Jul]
interval: 1 month
result: [Jan, |Apr, May, Jun, Jul|, Sep]
general usage examples:
a. We have a Forecast in a Kanban view. We are in April and we want the
forecast to cover the [Apr - Jul] period.
- domain: [(>= Apr), (<= Jul)] (limit the read_group to
the forecast)
- fill_from: Apr (current month)
- fill_to: Jul
The result would be [Apr, May, Jun, Jul]
b. We want the same Forecast [Apr - Jul], but there is a chance that some
records were forgotten in Jan, and we want to be able to reschedule
them, but we don't need the fill_temporal to take effect from Jan.
- domain: [(<= Jul)] (we removed the first bound)
- fill_from: Apr (current month)
- fill_to: Jul
The result would be [Jan, |Apr, May, Jun, Jul|]. We have the forecast
with the fill_temporal, and every month preceding the forecast as long
as there is at least one record in it (no empty month before the
forecast).
- (3.) Will be used as a way to guarantee a certain amount of returned groups
for a read_group grouped on a {date, datetime} field. This will only work
if there is at least one group to be used as reference (starting point) to
create supplementary groups if necessary.
example :
existing dates: [Mar, Apr]
min_groups: 4
interval: 1 month
result: [Mar, Apr, May, Jun]
- fill_temporal: {} will be considered as True (backend & frontend)
- The new key options are independant from each other (do not require the
others to be set in order to function properly)
Task-ID: 2243913
PR odoo/odoo#69380
1. Objective
- We are in a Kanban view, and we group by a "date/datetime" field.
- In order to "quick create" a record in a group, or to "drag & drop" a
record between 2 groups, we need a default value for this date field.
- In this case, a group represents a "range" of dates. A default value could
be the last date of this range.
- Prior to this commit, the view had only access to a display string for this
date range. We want to have access to the concrete bounds (start/end dates)
- Since some date/datetime fields have backend constraints, it would be
difficult to generate a compliant global default value. As such, the use of
the default value should be disabled by default and activated on a field by
field basis.
2. Usage
- Use the last day (for dates), or second (for datetimes) of the range to set
a default value in kanban "quick create" and "drag & drop"
- Use the end of the range of the last group from a read_group to be able to
request the next group (chronological order) in subsequent read_group calls
3. What are the changes in this commit
- read_group from the "core" "models.py", with the added __range for
date(time) fields, a dictionary for each group. The keys are the field
names and the values are a dictionary with the following keys: value:
- from: starting date(time) of the range (inclusive)
- to: ending date(time) of the range (exclusive)
- XML changes:
- with a new xml attribute on <field> tag allow_group_range_value (for the
kanban view):
- we allow (or disallow) supported non-readonly fields to be:
- draggable
- quick created
- this attribute can be used only on date(time) fields, and if not set,
the default behavior is false
- the naming is subject to contention because it relates to
different features. The relation comes from the constraint:
To perform a drag&drop or a quickCreate, we must be able to get the
value from the group containing the record.
- JS changes:
- we add "group.range" after a read_group for date fields, which is a
dictionary: {field_name: {from, to}}, for each date(time) groupby field
- since date(time) fields can use the format "date_field:granularity" when
used in a groupby, we have to properly split out the granularity to ensure
compatibility with the code previously in place (drag&drop procedures)
- update mock_server and sample_server to make use of the date range.
Adding support for datetime grouping to both mock and sample servers, for
tests and previews.
- the default value for kanban drag&drop and quickCreate features is the
last day/second of the range for date/datetime fields
4. Why can't this range be computed from the original display value with
moment.js
The Babel python library that we use for date(time) formatting (2.6.0) is kept
at the same version as the package in stable Debian Linux. This version has
some issues with displaying weeks consistently around the new year in certain
locales.
We cannot reverse compute a date(time) label with moment.js to get a range since
nothing guarantees that the range will be the same one that Babel used to
output it.
5. read_group return format discussion
Prior to this commit, the format of the value for the groupBy field was
either :
- String : used as a display value for the group.
Most notably, for date and datetime, this value cannot be used as a field
value in most cases. It would be more practical to also return the date
range along with the display value, so that Drag&Drop and QuickCreate
functionalities can be properly enabled in views
example :
"March 2021" has the range ['&', (field, '>=', 2021-03-01),
(field, '<', 2021-04-01)]
This information is lost at the end of the read_group.
- Array : used to indicate a res_id in case of a many2one field
res_id = array[0]
field_diplay_value = array[1]
Since we cannot use the array format to send the date(time)s of the period range
because it could be confused with the many2one format, this commit introduces
the use of a new `__range` key which is a dictionary with specific related
keys to be used to defer usable data to the web client.
Task-ID: 2243913
PR odoo/odoo#69380
Before this commit
------------------
Since https://github.com/odoo/odoo/commit/4b28f1162a85d03f9dbe0338b06758ad151ea6a8
It's not possible to override _process_job on ir.cron and
have the new method called by _process_jobs because
_process_jobs calls _proccess_job directly from the class
and do not user the registry anymore
After this commit
-----------------
Use the registry and get ir.cron model to call _process_job
closesodoo/odoo#72897
X-original-commit: b732ebfac934c8fa38a8eb55cfdb59833611c175
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit: when partner is only created with name(i.e. without
address) and when 'address_inline' is passed in context then partner name shows
with unnecessary commas.
After this commit: partner name will not have unncessary commas, as we removes
unncessary '\n' in case of 'address_inline' passed in context.
task-2502597
closesodoo/odoo#72869
X-original-commit: c08082d89782b7675e8e649cba15ca9e03e40077
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
This commit implements improvements in the layout designer, such as addition of a new custom background, adds custom report footer and company details.
task-2355704
closesodoo/odoo#66860
Related: odoo/upgrade#2275
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
closesodoo/odoo#72548
X-original-commit: bfa7c9e78037cd0abda3e8f0a9a519a600988e9c
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce the bug:
- Go to settings > create a new company :
- Choose the country : `Mexico`
- fill in the VAT field : ESA2005273X1
- save
- Validation error is triggered
Problem:
The Mexican VAT can be on the format: "MXESA2005273X1" or "ESA2005273X1".
But only the "MX .." format is accepted for the moment,
and it fails in the case of "ES.." because the function checks if it is a valid Espganol VAT number.
In the case of failure, we use the `partner.commercial_partner_id.country_id` to get the country code.
The problem is when creating the res.company, we also create a res.partner
with a few fields within `VAT` except `country_id` field
while we use it in the `check_vat` function : https://github.com/odoo/odoo/blob/7a7aacedde81998ec0f1a7f3283337236e56de42/addons/base_vat/models/res_partner.py#L167
Opw-2573557
closesodoo/odoo#72633
X-original-commit: a6a46c95e4947997892b21f407132574da1c7ff1
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
The import logging (ish) assumes that if an exception has at least 2
args the second arg is metadata added by the callee.
As it turns out, `UnicodeEncodeError` has *five* arguments, none of
which is added by us. So if encoding something fails during the
process (e.g. because the file contains a lone surrogate, which leads
to the database insert failing when psycopg2 tries to encode the query
to UTF8), then the `_log` function itself will fail, yielding a very
unhelpful error of:
dictionary update sequence element #0 has length 1; 2 is required
(because we tried to update a dict using a string).
This issue occurs only during *field conversion* and most fields have
no need to interact with the database (so don't need to encode the
value, which is what fails), however it is a problem when the invalid
string is used as a record name to look for (e.g. an m2o).
Further improve the experience by converting the UnicodeEncodeError to
a ValueError using the stringified UEE: `_log` assumes the first
argument to the exception is an error message of some sort, but for
UnicodeError subclasses it's just the encoding involved in the
error (here `utf-8`), which doesn't really serve as an error message.
Stringifying the exception generates a complete error message which is
quite a bit more helpful.
Specific update notes:
* avoid modifying the exception in-place, doesn't seem useful
* not sure why `field_name` was added as part of the augmentation
rather than up-front when `record` is created
Issue 2480064
closesodoo/odoo#72517
X-original-commit: 6c3c500929cd463cd3a1749f4ede8f3a8afd5748
Signed-off-by: Xavier Morel (xmo) <xmo@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>
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>
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>
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>
Samuel Degueldre