This commit adapts the x2many as first notebook tab's child selector to
the DOM of its OWL implementation, restoring the correct padding in this
case.
Steps to reproduce:
- Open Product form view
- Select the Variants notebook's tab
- Tab shouldn't have padding when the first child is a one2many
closesodoo/odoo#100912
X-original-commit: 74875dcc0b84236c0911b117666fc6deb41ed432
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Steps to reproduce:
- in Barcode > Inventory Adjustment
In the quantities add a decimal numpad
Issue:
Traceback
Cause:
The field is from type=number. This kind of field does not accept methods such `selectionStart()` or `selectionEnd` which causes an error: https://html.spec.whatwg.org/multipage/input.html#do-not-apply
Solution:
When of type=number, just return.
On Chrome, numpad won't be possible for regions such as Portugese - BR. They would have to use the keyboard key `period`, code '.' in order to be able to put a decimal via the keyboard.
In Firefox, HTML is parsing the input correctly if the browser settings are set to the right localization. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input#localization
opw-2956481
closesodoo/odoo#100953
X-original-commit: d95fbd80f63efbb47c9635e299f6ac417c5cb4c2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Currently the web.ReportAction component instantiates an iframe with 100vh of
height, while it should be instantiating the iframe with h-100. It assumed the
only component that would be rendered was the iframe, but we also need to take
into account the control panel and etc.
Also, the ReportAction component wasn't taking into account the height of the
control panel to set the height of the `.o_content` div. This also caused the
iframe to be rendered with the wrong height. This commit fixes this by adding
a flexbox column wrapper before the layout component.
closesodoo/odoo#100938
X-original-commit: 26cb2e1f659597311a06e46a84d7a0a9c3df6f74
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
Since commit odoo/odoo@0afe6fbda5
the `$card-cap-bg` was set to `white` to avoid inconsistencies in the
design. But the original value is `rgba($black, .03)` (3% of opacity of
black, almost transparent), this allows to customize the card color
using the utilities classes (e.g. `bg-danger`) but since the header of
the card is not more transparent, this behaviour is not working anymore.
This fix restore the original behaviour to avoid to break Bootstrap.
Steps to reproduce:
* Make an Odoo database without demo data
* Install an app
* Go to Settings
* Click on "Load demo data"
* A modal is open with a Bootstrap Card
* The title of the card has a withe background, not a reddish one => BUG
closesodoo/odoo#100932
X-original-commit: a1c7e3ac1b42beeb5de94307fb1bb5f09c869167
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
In mass mailing, a button allows you to see selected records. In some case the
displayed view of selected records allows to alter records (ex.: cancel
attendee in event) which then affects the number of selected records. This fix
forces the recompute of the number of selected record when closing the view so
that it takes into account the potential modification done in the selected
record view.
In mass mailing, in the selected records view, the button is called "cancel"
but any action performed in the modal will still be applied. This fix renames
that button to "close".
Task-2921762
closesodoo/odoo#100933
X-original-commit: be4e409ec1c23f64e11796b05643e424a93aba9e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit avoid to have a dict by reference that will be global.
Now get_default_session return a new dict each time for the context key.
From this way the session.context['lang'] is not shared between several
users on the same worker.
To reproduce the bug, restart the server with 2 workers, make request in
lang A on these 2 workers. DEFAULT_SESSION['context']['lang'] now is set
to this lang A.
Now, make request to an url without lang in path and without cookies and
withtout session, you should be redirected to lang B (preferred lang
from the request header) but you will be redirect to lang A due to the
dict session.context that is shared for the worker...
When we initialize the new Session, we get the wrong lang A as value for
context.lang, so we don't recompute the expected lang for the end user.
X-original-commit: 62179de74862210fe2a055d15b367b1850c24263
fwd-port of #100102closesodoo/odoo#100910
X-original-commit: 42e46b2d89dde276f796b980f29e33cc216e7cb2
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Replace the old "shortcuts" cheat sheet with opening the command
palette, which displays these shortcuts (and all of them, not just the
common ones) and also will display a tip regarding how to make the
shortcuts overlay appear.
closesodoo/odoo#100941
X-original-commit: e2625d7bc0c10d7b96912e06bcffe7074cfe6962
Signed-off-by: Géry Debongnie <ged@odoo.com>
This commit simply exports the 'X2ManyFieldDialog' component from its
definition file.
That way it can be properly extended / patched when necessary.
Task-2981969
X-original-commit: 881d8ef998b8a98b89ccbab93dcf1ed76ca1193b
Part-of: odoo/odoo#100940
The useChildRef (used with the useForwardRefToParent hook) allows
to retrieve, from a parent component, a t-ref from a child.
Consider the following scenario:
- have a parent calling useChildRef
- have a conditional (with t-if) child calling useForwardRefToParent
- in the initial rendering, the child is displayed
-> ref.el points to the correct html element
- re-render s.t. the child is no longer displayed
-> ref.el is null, because the referenced element doesn't exist
- re-render s.t. the child is displayed again
Before this commit, at this point, ref.el will always be null,
even though the corresponding element comes back into the DOM. This
commit fixes the issue by correctly updating the ref, each time the
useForwardRefToParent hook is called.
closesodoo/odoo#100937
X-original-commit: 78d39c79993d1d63c189164f8104e5a3c90f2efd
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The purpose of the task is twofold:
1. Remove empty lines in the company address.
Until now, the address format was fixed, which could
lead to empty lines if one or more field(s) were missing.
We are now removing empty fields to avoid that.
2. Make sure the external report layout is configured
before generating the PDF.
This will ensure that the company data will appear
in the file. If no layout is defined,
it would not be shown.
task-2834517
closesodoo/odoo#100936
X-original-commit: f36bb6acdacaaba26afdd8f62c48fd2c8784d1e1
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
This commit restores the almost-full (aka. 90%) width for the grouped
kanban's column (which use .o_kanban_small_column) on smaller screens.
As a reminder, to goal of this specific size is to give as much space as
possible for the column's cards *but* also showing a hint to the
previous/next columns.
Steps to reproduce:
- Open CRM grouped kanban on a mobile-like screen size
- Columns' width is not properly set (too small)
closesodoo/odoo#100911
X-original-commit: 6b60d332a0207342fec0a3a32af8ed30a8a73d91
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
- Take them out of `legacy` codebase.
- Group them in a generic `static/src/scss` folder, as those files are
used in webclient but also in public livechat, portal...
X-original-commit: ca2e4fea92b5a26078a412072275a969508358c7
Part-of: odoo/odoo#100759
Before this commit, in grouped kanban, when the "switch view" dropdown
(on smaller screens) is open, it is hidden behind the kanban group's
header.
This commit fixes it by setting the kanban group header's `z-index` to
only overlay its siblings (cf. this groups' records) but not the
ControlPanel's dropdowns. The static value "1" allows to elevate locally
the header above the records instead of using the Bootstrap's
`$zindex-sticky` variable which is aimed at raising an element (like a
navbar) above any other content.
X-original-commit: 1799e02cd56a26e48665043ca23ac1c735996c50
Part-of: odoo/odoo#100759
This commit fixes the ActionMenu's position on smaller screens by
pushing it to the bottom-right part of the ControlPanel (instead of the
bottom-left one on regular sizes).
It also adjusts its vertical alignment.
X-original-commit: 42966bc89f873032fa6bad41c2cfa7a001537f9b
Part-of: odoo/odoo#100759
Before this commit, the contrast between the form fields' label
(specifically the one where the field is empty) was hard to read (light
gray on a white background).
This commit fixes it by differentiating the color used as main
background and the "secondary" one (which is used for labels, among
other things) and providing a better contrast.
X-original-commit: 8cd30bb4478d50d74ba5074d1b4a54b09daef369
Part-of: odoo/odoo#100759
This commit normalizes the FormView's layout allowing to simplify it
and reduce disparities between community and enterprise.
It also allows to remove the `form_view_extra.scss` replacement.
X-original-commit: 9c2e851af3bfae8e6e6c11f061a8a5b952c54db9
Part-of: odoo/odoo#100759
This commit normalizes the ListView's layout allowing to simplify it
and reduce disparities between community and enterprise.
It also allows to remove the `list_view_extra.scss` replacement.
X-original-commit: 40228334436fd03ee251bd89c794aa439bed5839
Part-of: odoo/odoo#100759
This commit normalizes the WebClient's layout allowing to simplify it
and reduce disparities between community and enterprise.
It also allows to remove the `webclient_extra.scss` replacement.
X-original-commit: d3d35397aeec18b54e342ef2d19749229d95c694
Part-of: odoo/odoo#100759
This commit transfers responsive related customizations for
ControlPanel, SearchView and SearchPanel to community which allows them
to render properly on smaller devices.
Note: a page reload (aka. F5) is required to properly adapt the UI after
a resize to a mobile-like size.
X-original-commit: 26a755610da36b01ba07ca224cc5937a672eb6a8
Part-of: odoo/odoo#100759
This commit moves and integrates the touch device detection and
customization (through the o_touch_device class).
X-original-commit: 60acbb73e16ca551dfbadb8b29b73637e39bf9a9
Part-of: odoo/odoo#100759
This commit enables the WebClient's "responsive" mode by setting up the
"viewport" meta tag to allow it to scale to the device's width (instead
of being desktop-like only).
X-original-commit: 4d6169000aad92bed68879d90c360cb5cd62b8eb
Part-of: odoo/odoo#100759
Since _checkScrollbar, _setScrollbar and _resetScrollbar doesn't exist
anymore in BS5 and that these functions were removed during the
migration as you can see here: [1], compensateScrollbar is no longer
used for modals. That's why this commit removes the
'compensateScrollbar' function from 'jquery.js' and adds the code of
this function in the 'menu.js' file in Website because that's the only
place we need it now for the affixed header.
[1]: https://github.com/odoo/odoo/commit/0b94da214b7017e8580e671cbaa68ade6de2fbc7#
task-2985702
closesodoo/odoo#100894
X-original-commit: f3f45c93d3e942b224332924d66f2e48fc711002
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This reverts commit https://github.com/odoo/odoo/commit/51939d09f84579f61f1ff77aacd754beba036dc2.
This commit was added to no longer have to compensate the scrollbar
width to display the fixed header. To do this, this commit had changed
the 'fixed' CSS position of the affixed header to 'sticky'. But this
introduced several issues with header effects (the main problem with the
"sticky" position is that Chrome and Firefox don't handle it in exactly
the same way.). For his reasons, we decided to revert the commit and get
back to a situation where everything works correctly.
task-2985702
X-original-commit: ab9a4497c9ade5d91d7661bb3a4f47a683be1c32
Part-of: odoo/odoo#100894
In addition to the `displayBadge` option which is already present this
commit adds a new option `displayText` which dictates whether we want
any text at all on our tags list.
This is useful for kanban view where we only want to display the avatar.
X-original-commit: 7930865f0514092960acb0f76532e794f35882a3
Part-of: odoo/odoo#100764
The `TagsList` component may be provided with a list of tags and a
number of tags that should be visible.
In the case where there are more tags then there are tags that should be
visible a ball with the number of remaining records is added with a
popover containing the names of the records.
However the popover contained plain text resulting in
`record1<br/>record2` instead of marked up html.
It will now use a tooltip template and more info.
X-original-commit: baf9711407a01ec196bf7de191372056aa4cab6e
Part-of: odoo/odoo#100764
It seems that the css rule was copied from the legacy version of the
kanban view however the dom related to those rules changed with the new
fields and thus the rule was never applied.
X-original-commit: dbb10524b2d97a0004e4e998e4f2252c1e46982a
Part-of: odoo/odoo#100764
`additionalClasses` can now be set on field components to add certain
classes the wrapper should have.
This is useful in case css rules have been defined on a field widget
that we want to inherit from.
X-original-commit: e882c892ad2bf476a6d25cbd90e72974c5453a38
Part-of: odoo/odoo#100764
There is a not that simple logic involving column widths in list
views, in order to optimize the space available for columns with
arbitrary long content (e.g. char or many2one fields). For that
reason, some columns have a fixed width. Before this commit, the
first column, containing record selectors, had no fixed width,
whereas it should be set to 40px.
This commit also renames o_list_controller.scss into
o_list_renderer.scss as this file only contains renderer rules.
closesodoo/odoo#100522
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have a model with date(time) field with a group_operator (e.g.
"min"). Open a grouped list view of that model, containing that
field. Before this commit it crashed, because the aggregated
value of the date field, for each group, wasn't parsed (it was
still a string), whereas the code trying to display it expected
a luxon instance.
We could have easily fixed the issue by parsing the aggregated
values for date fields. However, it wasn't supported in legacy views,
and it would raise questions. For instance, views aren't designed
with this in mind (aggregated fields are often positioned to the
right, to leave enough space for the group's title). For that
reason, this commit simply restores the legacy behavior, that is,
we only consider aggregated values for "integer", "float" and
"monetary" fields.
The issue occurred in the Journal Items list view.
closesodoo/odoo#100595
Signed-off-by: Géry Debongnie <ged@odoo.com>
The goal of this commit is to get rid of the analytic tags as they were confusing, serving tag purposes as well as distribution on analytic accounts.
Everywhere analytic tags were used as a distribution have been replaced with a new widget that will dispatch distribution on analytic accounts. If there was an analytic account field next to the tags, it has been included in the distribution.
Analytic tags that were used simply as information tags have been removed.
To fill the new widget, there are now 2 kind of rules that will help fill and prefill it.
The first are applicability: previous groups have been removed, and have by replaced by plans. Each account is required to have a plan. These plans define when they are available in the widget: a default applicability per plan and applicability lines that can specify rules following the context of the widget.
The second one are distribution models, that will replace previous default rules but follow the same principles. The accounts (and so the plans) that will be given by the distribution model can override the applicability rules from before.
closesodoo/odoo#98914
Related: odoo/upgrade#3885
Related: odoo/enterprise#30743
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Habib (ayh) <ayh@odoo.com>
Before this commit, some values entered in the percentage field could
be changed due to a rounding error.
For example, the value 28 was replaced by 28.000000000000004
How to reproduce it:
- Go to a form view with percentage fields
- Enter the value 28 in the percentage field
Before this commit:
The value in the input was replaced by 28.000000000000004
After this commit:
The value in the input remains 28
closesodoo/odoo#100559
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the data-hotkey attribute set on button nodes
in form views was ignored. This commit re-introduces the feature,
enabling the keynav on those buttons.
closesodoo/odoo#100563
Signed-off-by: Georis François (fge) <fge@odoo.com>
Since [1], a call to getView no longer returns the all models the
list of all their fields, because a lot of them aren't necessary.
However, it caused an issue in the following situation:
- have a form view with an x2many displayed as a list
- in the list, have a field or widget with fieldDependencies
(dependency on field A)
- in the arch, the x2many form view isn't inline
- in readonly mode, the user clicks on a row, which will open
the x2many form view
- since the form view isn't inline, a call to getView is done
- in the returned form view, field A isn't present.
Since [1], it crashed at this point because A wasn't part of the
known fields in the form view (but it was in the activeFields,
since they are shared between the x2many list and form).
This commit fixes the issue by adding fieldDependencies not only
in activeFields, but also in fields if not already there.
[1] 4636620004closesodoo/odoo#100495
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The implementation was a bit wrong for a couple things client side,
this PR fixes it.
closesodoo/odoo#100267
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
This commit removes the 'bg-white' and 'pt-3' classes used in
the Notebook template since commit https://github.com/odoo/odoo/commit/68f1c90a031a7c2f751d9c8eca7ff525e9f7e206.
Now that the component is used by other components, such as the
media dialog from web_editor, it is not appropriate to add such
style in the core component.
Also, removing the bg-white class has no concrete effect in form
views, so it can be removed safely.
closesodoo/odoo#100253
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Scenario:
Open a record that is invalid in database (a required field is
empty), and click on the pager to go to another record.
Before this commit, we prevented the user from leaving the record,
marked the field as invalid and displayed a notification. This is
a weird UX experiment, since the user changed nothing (he did not
even enter edit mode). In this situation, since the record hasn't
been modified, the user should be allowed to leave. This is how
the legacy form view behaved.
closesodoo/odoo#100442
Signed-off-by: Géry Debongnie <ged@odoo.com>
Since [1], a call to getView no longer returns the all models the
list of all their fields, because a lot of them aren't necessary.
However, it caused an issue in the following situation:
- have a form view with an x2many displayed as a list
- in the list, have a field using the widget many2many_tags
along the color_field option
- in the arch, the x2many form view isn't inline
list must be present, without the color_field option,
and the color field must not be present,
- in readonly mode, the user clicks on a row, which will open
the x2many form view
- since the form view isn't inline, a call to getView is done
- in the returned form view, the color field isn't present,
the field using many2many_tags/color_field in the
list is present, and without the color_field option.
Since [1], it crashed at this point because A wasn't part of the
known fields in the form view (but it was in the fieldsInfo,
since they are shared between the x2many list and form).
This commit fixes the issue by adding the color field not only
in fieldsInfo, but also in fields.
[1] odoo/odoo@4636620004closesodoo/odoo#100479
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Changes made in #98380 were missing an extension on the factor
computation although already used.
This commit introduces the needed extension.
task-2974145
Part-of: odoo/odoo#100378
The progress bar parsing code was inside a big block of code making it
impossible to override to add custom behaviour.
It is not in a separated function.
Part-of: odoo/odoo#98837
Use the `prefix` slot to give a prefix to KanbanAnimatedNumber, making
it possible to add text while not needing to extend the class/template.
Part-of: odoo/odoo#98837
Before this commit, when a record from a relational model would start to
load, it would empty its `data` object. The issue is that a rendering
process can be initiated right after a record started loading. In kanban
views, this causes a crash since all records are always assumed to
contain values in their data objects.
This commit takes care to only clean strictly unwanted data when loading
a record instead of removing all the values, ensuring that records
always contain data.
closesodoo/odoo#100414
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, on compiling the field, a search is done to find the
label to link to the field. To do this search, the following field's
attributes were used: the `id`, which is encoded on the arch of the
view; if the `id` wasn't set, the `field_id`, which is an internal
technical attribute, is used, and if neither of these were set, the
'name', which is also encoded on the arch, attribute is used. These
attributes are compared with the content of the `for` attribute on the
label.
The issue with this, is that as the `field_id` is an internal technical
attribute and could never be found on the view arch, neither on the
content of the `for` attribute on the label. Leading to empty labels, or
labels linked to the wrong fields. This principally occurs when two
fields with the same name are found on the view.
Now, only the `id` attribute and the `name` attribute, which both can be
found on the view arch, are going to be used to search the correct label
to link to it's corresponding fields.
closesodoo/odoo#99399
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: auth_password_policy, bus, calendar, event, mass_mailing, stock,
survey, web_editor, web_tour, website, website_event, website_forum,
website_mass_mailing, website_sale
This commit is a first step towards a potential deletion of the
assets_common bundle, although that step would need more work, specs and
discussions as some layouts kinda only use the assets_common bundle
(some take the full assets_common but parts of the assets_backend one
for example).
The main goal of this commit is to have the assets_frontend bundle
directly include the "common" files we need. As a first step, this
commit only blindly duplicates them all into assets_frontend (without
removing the potentially useless ones). The goal is to have those
advantages:
- Reaching a frontend page only calls two main JS files (one normal and
one lazy-loaded) instead of 4 (two normals and two lazy-loaded). This
may help reach a better google page speed (which is becoming more and
more strict).
- The frontend CSS is built as one: the common SCSS which was using
bootstrap variables, or even Odoo-based SCSS added by mistake in
common instead of both backend and frontend is now computed with the
right bootstrap customizations. E.g. the tempusdominus datetimepickers
use bootstrap grays... after this PR, they use the right grays as
customized by the user on the website.
It was also chosen to not have a common "sub-asset" which is included in
assets_frontend. Making assets_frontend completely independent makes
sense (as it probably will for other "main" asset bundles): we can focus
on adding the files each layout needs without the need of worrying if it
impacts unrelated layouts. Sub-assets (when not strictly necessary) is
also a source of errors: extending the "main" bundle instead of the
right sub-asset it may use (like it was the case with the sub-assets of
assets_common: _assets_common_scripts and _assets_common_styles as
explained in the previous commit). So this is indeed a small drawback of
not factorizing the code for the inclusion of "common" files in bundles
but it seems more explicit and easier to maintain that way. Note that
adding "common" file is not the most common usecase anyway, apps
generally only need files in backend or frontend.
The __manifest__ declaration will also likely evolve in more and more
uses of wildcards to match entire directories. In the future, adding
"common" web-app files in both backend, frontend and other "main"
bundles could just be about one line duplicated into each bundle.
closesodoo/odoo#100314
Related: odoo/enterprise#31394
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The "web._assets_common_scripts" and "web._assets_common_styles"
sub-assets were useless, confusing and prone to errors. Especially with
the refactoring done by the next commit in this PR where common files
will be put directly inside the frontend bundle.
Indeed, their standard purpose was only to be included in the
"web.assets_common"... but making them sub-assets suggests you could
reuse them for something else... which you actually could not since most
"web.assets_common" extensions by other apps were done in the main
bundle directly instead of the correct sub-assets one.
Part-of: odoo/odoo#100314
Pierre Paridans