Before this commit, when website was not installed, the frontend used
the default bootstrap font. That font was not receiving the unicode
support Odoo provide in the backend or the frontend when website is
installed. This is probably visible on some portal pages in hebrew or
something like that, so this could back-ported in stable if found
necessary (in that case, the fix to the `o-add-unicode-support-font` in
this PR should be back-ported too).
task-2993054
closesodoo/odoo#101068
X-original-commit: f7cfcae0f0169774e0b66b8b8083005a7cd34eaa
Related: odoo/design-themes#593
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
To allow increasing page loading performance, websites can now choose to
use system fonts instead of using a google font. It is also the default
in the default theme of Odoo from now on. The option will automatically
be available for all themes whatever way they defined their available
fonts but will only be used as default if explicitly asked by the theme
(as done in the default theme).
task-2993054
X-original-commit: c0f2f670eb087991cc9a6a67f4beea5f12bd15f2
Part-of: odoo/odoo#101068
Before this commit, if a theme wanted to define a main font for their
theme and let the "headings", "navbar" and "buttons" ones use the same
they had to add this in their map:
```
'font': XXX,
'headings-font': null,
'navbar-font': null,
'button-font': null,
```
Indeed, without setting the "null" values, those font would use YYY
which is the first font defined in the theme config, which might be
different from XXX. And if forcing XXX 4 times, like most themes do at
the moment, if the user wanted to change them all, he had to change the
4 ones instead of the main one.
Now, only the 'font' value use the first font defined in the theme
config if not explicitly set. So forcing the null values is not
necessary, it will be the default behavior.
The advantage is thus also functional, as most theme forced all their 4
fonts so changing the main one did not change the others.
task-2993054
X-original-commit: c6b56955f62c6b837b477223daac2d87ab984efb
Part-of: odoo/odoo#101068
Before this commit, if a theme defined in its website values "palette"
"null" as value for the "headings-font" variable, it was properly making
the headings font use the default "body" font as expected but the editor
panel showed an empty value instead of displaying the "body" font value.
Now, that panel UI problem is fixed for the headings, navbar and buttons
fonts. Note that all our current themes force the font for each of those
component so the bug was never visible anyway. That's why it is merged
here in 16.0 and not before but it could be backported if necessary
(although it is only an UI bug which is not really confusing).
Before this commit, for a theme which says "use XXX as main font" and
"let headings follow the main font", the UI displayed:
Main font: XXX
Headings font: /
After this commit, it displays:
Main font: XXX
Headings: XXX
task-2993054
X-original-commit: b07a408f2f80638a2abdda8304e31d3dac9968b3
Part-of: odoo/odoo#101068
Before this commit, the function (which allows adding unicode support
to a font definition) relied on the fact "serif" or "sans-serif" was
defined last in the given font. If that was not the case, you had to
give the position in the given font stack where you want to include
unicode support).
Now, if no position is explicitly given, the function does not suppose
"serif" or "sans-serif" is defined last. It only supposes it is defined
somewhere in the stack, and put unicode support just before.
task-2993054
X-original-commit: 1f34ef2b64aad34ab533e77b1f31e434a5a17af1
Part-of: odoo/odoo#101068
Some views still use them.
closesodoo/odoo#101081
X-original-commit: adb5508afd2749dbbfeb85803d707df43358b011
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Before, the user had to manually unplug and replug the IoT Box to reboot it.
Also, it was required to connect to the IoT box to restart Odoo service.
This improvement adds the 'Restart Odoo' and 'Reboot IoT box' buttons on the box's form view to IoT app.
They allow the user to reboot the IoT box and restart Odoo service on it remotely from the IoT app in Odoo.
task-2476576
closesodoo/odoo#101045
X-original-commit: 662b41293315ae934502c683939d9820e4ca451a
Related: odoo/enterprise#31747
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Currently cannot see assigned user working on picking/batch in kanban view.
Added user_id in picking kanban view, and related user_id
from batch
TaskId: 2871679
ENT PR: odoo/enterprise#28886closesodoo/odoo#101026
X-original-commit: 943e5b9761b43257ec968c12f15723c618c3b5ad
Related: odoo/enterprise#31740
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Ahmed Khalaf <ahkh@odoo.com>
Copying an odoo chart gave a traceback since the method `copyInSheetId` wasn't implemented in Odoo Charts.
Odoo task 2987656
closesodoo/odoo#100748
X-original-commit: c26b8ee12857253c90b62b14c0a86c60457af4c2
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Minne Adrien (adrm) <adrm@odoo.com>
Given the group only contains EU27 members and the UK was specifically removed in 52cdfd22d7 it seems clear this group represents the European Union speifically rather than any other interpretation of "Europe".
Rename the group to match.
closesodoo/odoo#101051
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When the kanban is grouped on a readonly fields,
it shouldn't be possible to drag and drop a record from
one column to another.
It was the case when the field was part of the view architecture,
but not when the fields wasn't part of the architecture,
despite we have the information as we have the field description
through the search view / the control panel.
This is a bug which has been introduced during the OWL conversion.
For instance, in 15.0, when grouping CRM leads by sanitized phone,
it wasn't possible to drag and drop records from one column
to another.
In master this is possible.
Besides, in the legacy code, the readonly information
is read from both the field in the architecture and the general
field descriptions:
- https://github.com/odoo/odoo/blob/67191359f2e71be85e6e72d64720bb2748008b3f/addons/web/static/src/legacy/js/views/kanban/kanban_renderer.js#L506-L515
In addition, compared to before,
this revision allows a new possibility compared to before:
Make draggable when grouped by a field which is by default
readonly in the model,
but which is set as `readonly="0"` in the view.
This is to be uniform with what is done in the list and form views.
closesodoo/odoo#101041
X-original-commit: 2a0f8d9ddba754cfc297b2a0de6e2c56990b1e61
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: crm,link_tracker,project,sale,utm
Before this commit, in some form and kanban views, there were
missing whitespaces, typically between icons and texts. This was
due to the transition to owl views, because we simply ignored
`&nbsp;` in archs. This commit also fixes a layout issue in
a project view, where the icon and the field should be displayed
in the same line.
closesodoo/odoo#101040
X-original-commit: f5813e348b6052436a4fabaa5837ecc37b15430e
Related: odoo/enterprise#31746
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Improve both tree and form views for the account.analytic.distribution.model
closesodoo/odoo#101001
X-original-commit: bb2820ad585ceed0f0562de3cd5f9ef8f1fac7d1
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
Before this commit
In a nondeterministic sequence, the editor was not totally loaded
whenever the test `mass_mailing_editor_tour` dropped a snippet
in the page.
Now, by waiting for the attribute `data-editor-message` to be set,
we ensure that the state of the editor is ready for dropping a snippet
in the page.
closesodoo/odoo#100752
X-original-commit: a333c8ff6b48c7f614ee0a45321fdf176e9dc33b
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The cache currectly fails to correctly invalidate relational fields that depend
on a non-relational field. Two passes of invalidation are done, to reflect
dependencies on both the old and the new written values. In the first pass
only relational fields are considered, as explained in the comments:
> It is best explained with a simple example: consider two sales orders SO1 and
SO2. The computed total amount on sales orders indirectly depends on the
many2one field 'order_id' linking lines to their sales order. Now consider the
following code:
>
> line = so1.line_ids[0] # pick a line from SO1
> line.order_id = so2 # move the line to SO2
>
> In this situation, the total amount must be recomputed on *both* sales order:
the line's order before the modification, and the line's order after the
modification.
The written values can be seen as the roots of a dependency forest (a
collection of dependency trees). Before this commit all non-relational roots
and their corresponding trees were filtered out during the first pass. However,
this approach is wrong, as relational fields can also depend on non-relational
fields. Instead, the complete dependency forest has to be traversed, skipping
invalidation for non-relational fields during the first pass.
The test that was previously included accidentally succeeded because of a
separate and unrelated bug in the orm domain parser: in certain one2many or
many2many leafs the domain parser would not take into consideration the domain
included in the definition of the field. As a result, the test still passed
by accident, because the records that no longer matched the domain after the
write were still invalidated during the second pass.
The problem can clearly be demonstrated, however, when the dependency is
generated by a compute function.
closesodoo/odoo#101038
X-original-commit: d4a5827b42d80f0f830455dcd2056701eb09aed1
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Nodes like
<attribute name="t-on-dragenter.stop.prevent">() => state.dropzoneVisible = true</attribute>
should not be exported in the translations files but
<attribute name="string">Hello World</attribute>
should be kept
It was already the case in the xml processing method for server side
templates.
Since 16.0, client side QWeb views also use the same inheritance
mechanism than the one on the server side so the exception needs to be
replicated.
X-original-commit: e05d1192481935b2cd7aae7e939f98e60e002899
Part-of: odoo/odoo#101053
The test was running by luck because the event and all talk pages
contains the needed elements. The favorite was checked randomly on
other pages because those steps are way faster than loading the page.
This test will fail in rare case if the page loads faster and the step
checking if the "favorite is on" occurs when the talk page is finaly
loaded.
This commit adds some step to try to ensure the page are loaded before
doing anything else.
Also enable ticks on freezetime so that we have an idea of the steps
durations in logs for easier investigation.
X-original-commit: 8405104b14624f27df4d95e21738b253d048063f
Part-of: odoo/odoo#101050
Remove sorting rules arrays from the functions that wrap them as they
are unnecessary noise.
closesodoo/odoo#101039
X-original-commit: b37baf8996d65d639f0178651a7be0206d0679d0
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit fixes some wrong usage of the bootstrap class `col` & `row`:
- POS: Missing the child `col` on `row` parent;
- Survey: Using the class `col` to center the node on the parent div;
closesodoo/odoo#101046
X-original-commit: acacf52d40a41b53aa78967748602cb3b1e62261
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, the inputs (radio, check and select types) on
`focus` state wasn't visible due to the override rules in Bootstrap:
```scss
/* Example of rule for checkbox */
.form-check-input:focus {
border-color: $form-check-input-focus-border;
}
/* Default config of Bootstrap 5 */
$component-active-bg: $primary !default;
$input-focus-border-color: tint-color($component-active-bg, 50%) !default;
$form-check-input-focus-border: $input-focus-border-color !default;
/* Our override in Odoo */
$component-active-bg: $gray-200 !default;
```
This commit, sets the `$o-brand-primary` color (`#71639e` in community,
`#017e84` in enterprise) on the border in focused state.
Note:
before Bootstrap 5, this bug was not present as custom-checkbox was a
custom pseudo-element (`::before`), and so it was not possible to be on
a `focus` state on this pseudo-element.
closesodoo/odoo#101044
X-original-commit: fba258e738d6b629bb79fb5d7d9c9585733d72b1
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit properly removes the Many2ManyTagsField and
Many2ManyTagsAvatarField's placeholder when at least one tag has been
selected.
Steps to reproduce:
- In Contacts, open a partner's form view
- Edit and set at least one "tag"
- The placeholder is present next to the selected tags
Note: the placeholder was already present in previous versions.
Reported by FP.
closesodoo/odoo#101042
X-original-commit: 5976e19a31b9b0edaefc1079541514810d12b240
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Steps to reproduce the bug:
- Create a storable product “B1”:
- Costing Method: average
- With BOM:
- BOM Type: Kit
- Components:
- 3 units of “C1” (cost c1 = $2)
- Go to the “B1” product form:
- Click on “Compute Price from BOM”
- Cost = 3 * $2 = $6
- Create a storable product A1:
- Costing Method: average
- BOM
- BOM Type: Kit
- Components:
- 2 units of B1
- Go to the “A1” product form:
- Click on “Compute Price from BOM”
So: 1 unit of A1 → 2 units of B1 → 3 units of C1
- Cost = (2 * 3 * $2) = $12
- Create a SO:
- Add 1 unit of “A1”
- save
- cost(`purchase_price`) = $12
- Confirm the SO
- The cost is recomputed and becomes = $6
Problem:
When the SO is created and the product “A1” is added, the cost is
retrieved from the product: https://github.com/odoo/odoo/blob/14.0/addons/sale_margin/models/sale_order.py#L27
But when the SO is confirmed, a picking is created, therefore the
cost is recomputed: https://github.com/odoo/odoo/blob/14.0/addons/sale_stock_margin/models/sale_order_line.py#L18
So The `_compute_average_price` function is called, in which a loop is
made for each move related to the `sale.order.line`, but the
`bom_line.product_qty` is used for each component (in this case the qty
necessary of the product `C1 ` to make a single unit of `B1`, but this
is not multiplied by the number of units needed to be used in the
parent's bom_line
opw-2971248
closesodoo/odoo#101012
X-original-commit: 9ec7aa9b89bc929af15473d0cc29084fd831cf94
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Before this commit, when exiting a record in any way, the validity of
each of the fields was checked, even if not dirty. This means that the
user would be locked on a required field if that field got an invalid
value from the server, even with no given input.
In this commit, switching the mode on a record ("readonly" | "edit")
will not go through validation if the record was not dirty.
closesodoo/odoo#101000
X-original-commit: 8a8241503e41486e79ca19f9ca16f413cfabb08b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When generating an invoice for a SO with 2 SOL that have a timesheet service
(1 SOL is timesheeted in August, the other is timesheeted in September) and
we request the invoice for the period of August only, the SOL for September
is incorrectly set to state "Nothing to Invoice", instead of staying in
state "To Invoice".
This is due to the fact that when we inspect the SOL to invoice, those that
are not in the domain (here the SOL in September is not in the time domain
of August), we set it's qty_to_invoice to 0, so it doesn't get invoiced, but
this is a computed field, which sets the line invoice_state to "Nothing to
invoice".
The proposed fix is to reset the invoice_state of the lines that are not validated by the domain to the state before setting the field qty_to_invoice to 0.
Affected versions:
- 15.0
- saas-15.2
- saas-15.3
- master
opw-2969641
closesodoo/odoo#100978
X-original-commit: 50b81adb3ea13db33bf1375b7038b6cc3546ec86
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
- In `unlink`, since https://github.com/odoo/odoo/pull/66938
modified is called on self for each batch of 1_000.
But it should be called on the batched records.
- In `write`, remove useless `records_to_inverse`
(there from ORM refactor but never used)
- make `_modified_triggers` more deterministic by
changing a `set` into `OrderedSet`.
closesodoo/odoo#100472
Signed-off-by: Raphael Collet <rco@odoo.com>
So far the vat_label was missing in res_country_data.xml.
This defines the official name for the local Tax ID (called "RUC").
closesodoo/odoo#100650
X-original-commit: 53b0ff01535c10d31102e9087d9e5196fa261630
Signed-off-by: Laurent Smet <las@odoo.com>
Longpolling port is replaced with gevent port and is deprecated
This commit avoid saving the value.
Not really usefull but when saved the value was None leadind to an error
when casting to int. The default value should be an int.
closesodoo/odoo#100991
X-original-commit: adac9a9ceaa173c0181a4fc57d0ea83b7a37fc71
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
They tend to come in the way of very obvious things in the UI, repeat
the same stuff that the label, etc.
Titles attributes are not good for a11y, so if needed I prefer replacing
them with an aria-label which:
- doesn't mess up the UI
- works properly with screen readers
I've kept them on nodes that have no text (e.g. icons), otherwise
they're not needed - text needs not be labelled.
closesodoo/odoo#100990
X-original-commit: 1c52c649f99d831de98d349d1ffbc6abc95a93ae
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Currently, When we create an invoice from a sale order containing some notes or sections.
The analytic account from the sale order is set on the invoice/move line.
During the creation of analytic lines, a line is created from the section/note line.
This commit makes no analytic line is created for section/notes.
closesodoo/odoo#100989
X-original-commit: a1bff32113bb0b551cd62efea5030c8f3bd4d1de
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When drag and dropping a work order in the Work Orders Planning, the
end time wasn't recomputed. This can make the end time inconsistent with
the duration when the work order spans across a non-working time.
Steps to reproduce:
1. Install Manufacturing
2. Go to Settings > Manufacturing > Operations and enable Work Orders
3. Go to Manufacturing > Master Data > Routings and edit routing
'Primary Assembly' to last 120:00 minutes
4. Go to Manufacturing > Operations > Manufacturing Orders and create
one with values:
- Product: Table Top
- Plan From: today's date at 11:00:00
5. Save, mark as todo and plan the manufacturing order
6. Go to Manufacturing > Planning > Planning by Workcenter and trigger
the day view
7. Move the work order to 8 am
8. The work order still lasts for 3 hours (according to its start and
finish time) even though its expected duration is 2 hours
Solution:
Recompute `date_planned_finished` when we move a work order in the
planning (`date_planned_start` and `date_planned_finished` are passed in
values), and recompute `expected_duration` when we extend it (only one
of them is passed depending on the way we extend the work order).
(`duration_expected` is never passed in values when we manipulate a work
order through the planning)
Problem:
`date_planned_finished` wasn't recomputed when moving the work order in
the planning
opw-2893622
closesodoo/odoo#100988
X-original-commit: 2515482d5a706c65a7d8e27028f43987f17e6e67
Related: odoo/enterprise#31720
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Before this commit, in a list view, the context set on a m2o field
is not used when you edit the field to create a new record.
How:
- Go to a list view with a m2o field containing a context
<field name="m2o" context={"test":1}/>
- Edit the field the m2o field
- Click on "Create ..."
Before this commit:
The name_create method call does not contain the context defined
on the <field/>
After this commit:
The call to the name_create method contains the context defined
on the <field/>
closesodoo/odoo#100987
X-original-commit: dd1e7fab585ed5a691456632c20097ce443d9d69
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit moves the inline handlers of the `useSortable` hook
calls in the list and kanban renderers to proper class methods.
This allows said handlers to be overridden in child classes.
closesodoo/odoo#100986
X-original-commit: ec5ab1d389a0bdfb37c8b2c6766b6be1330085a7
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit implements the "name_get" method in the sample server.
This is required for m2o fields with the "always_reload" option.
How to reproduce?
go to an empty list view with sample="1" containing a m2o field with the
"always_reload" option
Before this commit
We have a crash because the "name_get" method does not exist.
After this commit
The view is rendered correctly with the sample data.
closesodoo/odoo#100985
X-original-commit: 4e53f92caf2527b15439eae041fcd238e2ed8145
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The placeholders were rendered as empty string in the web version of the
mailing (accessed through the "view online" link in the email). This fixes the
problem.
Technical note: we cannot use mail_mail.body_html (which contains already the
rendered placeholder for the specific user) as it is marked for deletion so we
render it from mailing_mailing.body_html.
Task-2954282
closesodoo/odoo#100984
X-original-commit: 6b2d5db762ef198e9f07af95116c166b027eb383
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Indonesia officially added new province. Papua Selatan, Papua Tengah, Papua Pegunungan.
closesodoo/odoo#100980
X-original-commit: 9d047bfac876f814f46cf212d2be44614a8e7a71
Signed-off-by: Jérémy Kersten <jke@odoo.com>
The move line list js has a set thread method that tries to
get the move_id from the list view.
But in the list view, the move id was now missing so it
couldn't find it when a filter on journal entry was set.
This adds it again so that the code can get the information
again.
closesodoo/odoo#100974
X-original-commit: 8857d31bfa6f2e330d296ab6f3ed9223e228f54e
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
A crash would occur when creating new records as the code did not take
into account the possibility of having empty "base" data.
closesodoo/odoo#100973
X-original-commit: 497db878fa3f9303ce33035d5737352289c4f97d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Currently, if we create an activity for user other than logged in one and
create a calendar event from the activity, it automatically changes the
attendee on the event and re-assigns the activity to the logged in user
instead of the one originally assigned to the activity during creation.
It happens because default attendees are not passed while creating the
event from activity. ALso, when editing the calendar event, the sync
mechanism changes the activity user to the organizer of the event, which
by default is logged in user.
This commit improves the behavior by passing the appropriate default
values so that the calendar attendees and organizer matches with the
user to whom the activity is assigned initially.
task-2920631
closesodoo/odoo#96943
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit
The method `updateValue` was updating value constantly
because `value` was a string and `this.props.value` a Markup.
Now
Update only when necessary
closesodoo/odoo#100965
X-original-commit: 45d4ac14f65c53dcde56592715d50169bde116ad
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
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>
After this commit, fields from models framework are stringified to
follow the presentation ModelName/fieldName.
Task-2992286
closesodoo/odoo#100845
X-original-commit: d645bf2c708f67ff27d004b79754926f3086c58b
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Louis Wicket (wil) <wil@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>
qsm-odoo