When a report with header is displayed in iframe with layout
"Background", part of the header maybe outside of the page.
For example on /my/invoices portal show of an invoice, the max width
report iframe can set at 210mm (+/- 793.7px normally), the header in
background layout has `min-width: 900px` so is wrongly centered and may
have content outside of shown page (eg. company tagline).
The same issue happen when using HTML rendering of the report in
backend, but depends on the viewport width.
This may be the expected configuration when printing (wkhtmltopdf should
unzoom if something was too large to fit) but not when displaying html
directly.
opw-1915807
closes#32373
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When creating a record from a calendar view,
the default form view is always used when using the popup mode,
ignoring the `form_view_id` attribute of the <calendar/> tag.
After this commit, the `form_view_id` is no longer ignored.
closesodoo/odoo#32379
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Steps to reproduce the bug:
Let's consider that we are in 2019
- Create two customer invoices: I1 and I2
- I1 with invoice date = 2 april 2019 and amount = 100€
- I2 with invoice date = 2 april 2018 and amount = 1000€
- Go to Reporting > Invoices
- Click on widget "Time Ranges" and set "Based on" Invoice Date and "Range" This Year "Compare To" Previous Year
Bug:
The untaxed total for previous year was 1100€ instead of 1000€ because it counted previous year and this year.
opw:1962027
closesodoo/odoo#32331
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
In fullcalendar, we have in f5b7ad80f fake moments date with UTC time
that are the local time, thus when we move an event to another day, we
need to set it as:
- the selected year-month-day
- the original utc hours (real local hours) -> local hours
- the original utc minutes (real local minutes) -> local minutes
- the original utc seconds (real local seconds) -> local seconds
When it is sent to server, timezone offset will be removed so we will
transfer to server the expected datetime in UTC.
With this changeset we send server the correct time when a fullcalendar
event is "all_day" but the original event was not (eg. drag and dropping
event on the month view).
Added test without change failed with:
- 4. event moved to 27th nov 16h00 +40 hours timezone
(expected "2016-11-29 08:00:00", result: "2016-11-27 16:00:00")
- 5. expected: "event|6|11/27/2016|16:00:00"
result: "event|1|12/09/2016|08:00:00"
- 6. expected: "event|1|12/09/2016|08:00:00"
result: "event|3|12/10/2016|23:55:05"
opw-1955281
closes#32136
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
On a form view:
- we open a modal form view
- in this modal we open a modal form view
- we close that second modal
=> the modal is closed and the first one is still opened, but on mobile
we can't scroll to above or below the modal.
This is because bootstrap remove .modal-open class on body when we close
the second modal, but this class is necessary to scroll (this is not
much an issue on desktop since scroll is often not necessary).
We already had a fix that was weakened in 02a063fd73.
With this changeset, we keep .modal-open as long as a modal is opened.
Without the change, added test failed with:
10. Modal is said opened (expected: true, result: false)
opw-1948423
closes#32106
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The widget handle was displayed on x2m fields in form views, even when
the field was readonly, which makes no sense.
It is now correctly hidden.
Fixes#30580
opw-1937833
closesodoo/odoo#31743
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit iteration in a t-foreach containing null or
undefined values crashed because they have no attributes.
closesodoo/odoo#31828
Signed-off-by: Fabien Meghazi <amigrave@users.noreply.github.com>
Have a list view, apply a group_by and a filter with a sort parameter
Click on one record to access the form view
Have a x2m within it
Before this commit, the x2m records were loaded with a context containing
the keys orderedBy and group_by
It seems harmless at first, but even conceptually those keys should not be here
- they apply on a list of records, and not to individual ones
- they may contain field names not existing in the x2m model
Hence, when accessing another list view through an action button, the list
will try to be orderedBy or group_by with the given context
Which is plain wrong in the first place and may cause crashes
After this commit, the context of a record datapoint (representing a single record)
is stripped from the keys
Read the opw for a concrete use case
OPW 1943583
closesodoo/odoo#31706
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before 11.0 the kanban view used to have its own widget registry. It is not the
case anymore, but there are still leftovers from the past. For example, the
widget `kanban_label_selection` is still used in many views, even though it is
now called `label_selection`.
As we are in a stable version, a fallback has been added for it in the field
registry.
Similar to odoo/odoo@5401c15Closesodoo/odoo#30904Closesodoo/odoo#25928
Since f8b38f64d dictionaries "groupbys" are the same object between the
pivot model instance and the headers menu.
But this causes an issue in 12.0 since when there is no results, the
headers menu groupbys is truncated and now being the same object, the
pivot model instance is also truncated.
So succedding search that find results would possibly have lost the
groupbys which is unexpected and breaks some 12.0 tests not expecting
it.
With this changeset, the groupbys are not truncated anymore.
Without the change, the added test fails with:
Column groupby not lost after reload after empty results
expected: { "pivot_column_groupby": [ "customer" ],
"pivot_measures": [ "__count" ], "pivot_row_groupby": [] }
result: { "pivot_column_groupby": [], "pivot_measures":
[ "__count" ], "pivot_row_groupby": [] }
closes#31644
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
moment().locale('en').format('YYYY-MM-DD')
"2019-03-25"
moment().locale('ar').format('YYYY-MM-DD')
"٢٠١٩-٠٣-٢٥"
moment().locale('my').format('YYYY-MM-DD')
"၂၀၁၉-၀၃-၂၅"
Was rejected as a valid bug at moment/moment#4448
Apply the same logic than 109b319d64Fixesodoo/odoo#32081closesodoo/odoo#32102
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In 187c32c2 some improvements were made for conserving/restoring group
bys on the pivot view.
This introduced an issue on the column group by:
- before reload, if we set manually a column group by (+ icon in the
header) it would be saved and not lost (unless a context or filter
in the search view override it)
- after reload, the following manually set column group by are not saved
anymore on subsequent reload (the column group by at the first reload
are set back)
This behavior is not normal since the behavior (conserving or losing
column group bys) should be the same at first reload or second reload.
The issue was caused by the duplication of group bys that were not
synchronized (one on the column root header, one on the pivot model
instance).
Without the change, the added test failed with: "Column groupby not lost
after second reload" and product_id is hidding from the object
pivot_column_groupby dictionary (having only "customer").
Using _.clone on initialRowGroupBys was necessary change because without
duplication of "groupbys", the initialRowGroupBys would be changed on
expandHeader which is unexpected.
opw-1941095
closes#31407
make sidebar filter generic
Adding `res_model` and `res_fields` attributes on a field of
a calendar view adds a filter in the sidebar.
It saves the result as the defined model and should save it
in the defined field.
However `partner_id` has been hardcoded in the rpc call that creates
the record. This breaks genericity, it cannot be used with another
field than `partner_id`.
This commit makes this generic by correctly setting the field name
in the rpc call.
closesodoo/odoo#31858
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Ildar Nasyrov <iledarn@gmail.com>
In 11.0 f8b38f64d improved the column group by managment when reloading
several times by having the same "groupbys" dictionaries between the
pivot model instance and the header menu.
This has been reverted in 12.0 (with c6e7adfb95) because the following
pivot tests failed with the change:
- 'rendering of pivot view with comparison'
- 'export data in excel with comparison'
The failure is because now that the "groupbys" dictionaries are the same
object, the truncated dictionary of a header truncate the one of the
model instance.
So if we search something that has no results, then something with
results, the groupbys could be lost.
This behavior has no reason to be and is changed in 11.0 with #31644,
this commit is the forward-port of f8b38f64d and #31644.
closes#31627
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Create a record.
Add an attachment, using the widget (aptly named 'add an attachment').
It is not set as message_main_attachment_id.
If you add the message through 'log note', then it is.
We add a hook to make sure that it is set as message_main_attachment_id
when added through the widget.
opw 1950403
closesodoo/odoo#31847
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
This makes the assets to be recomputed everytime somebody with a different
language load the page.
closesodoo/odoo#31782
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
If the content is too long, it overflows badly.
Since the height is fixed, the flex doesn't work well.
opw 1924145
closesodoo/odoo#31717
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
The widget has been moved in rev. odoo/odoo@15f3bbe but was not very generic.
In particular, there was a traceback when clicking on the button if the field
had no value (the button was displayed for readonly fields in create mode).
The button is now only appended in readonly mode (a `button` inside an `input`
or a `textarea` is not very DOM friendly) if the field has a value.
Task 1941996
closesodoo/odoo#31635
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The style of a link (color) of a many2one is only applied over the
first line (probably for eg. the partner on an invoice that has the
partner name and on following lines the address).
In some instance this make some sense, but on other (the name of a
product is too long from where it is) it makes no sense and seems buggy.
With this change, we have the link style over the whole link which seems
good enough.
opw-1947113
closes#31568
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Switch to French language
- Go to Inventory > Inventory Adjustment
- Launch an adjustment
The field 'Real Quantity' doesn't follow the float formatting.
This is because the widget is set as `field_float_scannable`, which is
not recognized by the formatting function.
Since the widget descriptor has priority over the type descriptor, we
must explicitly take this widget into account, on top of adding the
`format_value` method.
opw-1940884
closesodoo/odoo#31366
On a pivot view with a default filter which has column and row groupbys
Remove the filter
Collapse all columns and rows
Activate another Filter from favorite which has a column groupby at least
Before this commit, the columns were not displayed in the DOM, though RPC's
and internal data were actually correct
This was because we considered the changes had been done "in place"
taking the old tree to build the new one for the columns
when really, we should have recomputed the column tree
After this commit, the columns display the group we want
OPW 1935155
closesodoo/odoo#31247
Let's assume a form view with a clickable statusbar, in readonly.
When the user clicks on a status, the change is saved directly.
When the save fails (e.g. access rights), the statusbar widget
is in an inconsistent state and must be reloaded.
This rev. reloads the whole record and re-render the form when
this happens.
Related to Issue: #1915391closes#29519
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Nicolas Lempereur