The goal of this commit is to restore the behaviour of the legacy
attach_document widget.
How to reproduce :
- clicking on the attach_document button and selecting a file
In legacy:
We have a full reload of the view (Render and reload the record).
Before this commit:
Render the view without reloading the record.
After this commit:
We reload the model which causes a rendering of the view and a reload of
the record.
Why do we have to reload the record ?
If the action linked to the attach_document button modifies the record,
we want this modification to be applied in the view and not only on the
server side. To do this, we need to reload the record data to ensure
that all the changes are displayed in the view.
closesodoo/odoo#103891
X-original-commit: 82d4f0cd2f0265393cf66cd7be1a0a714584400c
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
Similar to the html field widget, this commit add the display: block
class to the pdf viewer widget in order to make it use the whole area of
a notebook zone:
Task: 2991906
X-original-commit: a1407975c2fafedef5f5eb7d4597cfcd88117e49
Part-of: odoo/odoo#103872
Before this commit, in a list view in multi_edit mode and editable="0",
it was possible to edit a required field with an invalid value.
Why:
In the PR 101924, we decided to no longer pass readonly/required of fields
in non-editable views (if no editable="1").
Solution:
To know if a view is editable, you should not only look if it is
editable="1" but also if it is multi_edit="1".
So we want to pass the readonly/required fields if the view is
editable="1" or multi_edit="1".
How to reproduce:
- Go to a multi_edit="1" and editable="0" list view with at least one
required field on the server side
- Select the checkbox of the record you want to edit
- Edit that field with an invalid value (e.g. clearing a text field)
- Click outside the line being edited
Before this commit:
The record is saved with the invalid value
After this commit:
An alert dialog is displayed to warn us that the value is invalid.
The record returns to readonly mode with the old value.
closesodoo/odoo#103790
Related: odoo/enterprise#33066
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Since odoo/odoo#95729
nodes with a `groups=` are completely removed from the views when
the user is not part of the group, instead of being made invisible.
In that PR, views have been adapted to add back fields, with invisible="1",
when they were required, for instance when they were used in a domain
of another field which was still there despite the user is not part
of the given group.
As `tree` views having `multi_edit="1"` where not considered
as editable views, the domain of fields in these views were not
validated:
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1460
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1321-L1322
while they are well required for the web client,
in `multi_edit="1"` this is possible to edit relational/many2one field,
and therefore it will do `name_search` calls using the domain of the
field, and therefore the fields used in these domains must always
be present in the views. Without it, a crash in the web client occurs
when attempting to edit the relational/many2one field.
This revision targets to consider the `multi_edit="1"` tree views
as editable, to make the field domains validated as they should be.
Hence, views are adapted to add back fields with `invisible="1"`
when they are required in domains of other fields.
Part-of: odoo/odoo#103790
Release notes: https://github.com/odoo/owl/releases/tag/v2.0.1
- fix: runtime: correctly throw an error for duplicate object keys
- fix: parser: give t-set-slot="default" priority over the content
- fix: blockdom: correctly reorder children in heterogeneous t-foreach
- fix: portal: correctly move portal content when target is after it
- fix: blockdom: fix event_catcher traceback when a parent component has an empty child
closesodoo/odoo#103847
X-original-commit: be996cf423ce09be4e4661c0b42a97d92a4dcdb4
Related: odoo/enterprise#33097
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Steps to reproduce:
- Go to a list view with multiple items
- Click on an item
- Delete it
- Go back in history twice (Using the browser navigation) to return to the list view
-> We can't click on another record
opw-2854113
closesodoo/odoo#103808
X-original-commit: 92c90823139b413c8289d1c323ad694fc8220a61
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
To reproduce:
1. Create a (incorrect) view manually. For example, inherit from
`res.config.settings.view.form` and do add the following view architecture:
```xml
<data>
<xpath expr="//div[hasclass('settings')]" position="inside">
<field name="field-dont-exist" widget="upgrade_boolean"/>
</xpath>
</data>
```
( In practice, Odoo will refuse to let us save the view if it is incorrect
(we can bypass that by pushing directly in the database for testing) )
-> When trying to open the settings app, you will have a cryptic JS error:
`TypeError: field_utils.format[(formatType || this.formatType)] is not a function`
The goal of this PR is to improve the error to ease its correction.
Note: This issue can happen in practice after an upgrade or a failed
uninstallation of a module.
OPW-2952309
closesodoo/odoo#103686
X-original-commit: 73dccc3e51472f76cf5cf32a4fbd48d0b58b5c36
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Fix the hatching and striking effects for events
by moving some scss rules to the right place:
- o_event_hatched
- o_event_striked
Various fixes for the calendar popovers to display properly, such as:
- year scale popovers
- proper popover body padding and font-size
- style that depends on attendee status
- other scales popovers
- inverse the condition when the popover footer must shrink
closesodoo/odoo#103661
X-original-commit: 917d8e4123517c73d8bd6a4bd83becf1b0ee1090
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
This commit removes some style that is dead code, related to classes:
- o_cw_custom_hover
- o_cw_nobg
- o_calendar_hatched
- o_calendar_hatched_*
- o_calendar_striked
- o_calendar_striked_*
X-original-commit: 4a19e031ae70a44369970147dd1735da66a9ea64
Part-of: odoo/odoo#103661
This commit fixes a race condition spotted by the click all test,
in the Lunch application. To reproduce, go to Lunch > Configuration
> Products, in the list view, toggle filter "Archived" s.t. there's
no record matching the domain (and nothing displayed in the search
panel anymore), then switch to kanban view, and remove the filter.
On a multi-build, this scenario fails ~4 times out of 10.
The issue occurs because a re-rendering of the search panel is
triggered by its parent (because of the filter change), but the
search panel didn't compute its active sections yet (this is done
when the "update" event is triggered on the search model). The
exact situation is hard to reproduce, but if there are non empty
sections in the model, and the active sections haven't been computed
yet in the search panel, it crashes. For instance, it happens all
the time by delaying the promise returned by "_fetchSections".
This commit doesn't introduce a qunit test because we didn't manage
to reproduce the exact same situation in a test. This makes the
Lunch click all test pass all the time though.
closesodoo/odoo#103638
X-original-commit: b84df7e08b4d413de2e8a0b1df6cb8d6ad4b08cf
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, multi clicking quickly on the "Ok" or "Cancel"
buttons of a ConfirmationDialog would call the confirm/cancel
callbacks multiple times. For instance, in "Mass mailing", create
a new mailing and click "Send". In the confirm dialog, clicking
quickly multiple times on "Ok" would call the "Send" button action
multiple times.
This commit also ensures that we wait for the promise of the
confirm callback before closing the dialog. This highlighted an
issue in the ORMBatcher, as we didn't reject the promise when
the batched rpc failed. As a consequence, the confirmation dialog
never closed itself. This has been spotted by an existing test.
Fixing #74647 (from 16.0 to master)
closesodoo/odoo#103572
X-original-commit: 95f8266a5b84f5faa59a713019ab713392b3ef78
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The purpose of this commit is to fix an indeterminate error in
the test_03_sale_quote_tour.
Error: UncaughtTypeError: Cannot read properties of undefined (reading
'unselectable')
Why:
In the autocomplete component, it is possible to replace the sources
without it being rerender. It is therefore possible to click on a option
that no longer exists in the component's internal state, which causes
the crash.
Solution:
We wait that all the sources are loaded before replacing them.
closesodoo/odoo#103497
X-original-commit: f25df0be75082caf9e8ed62c581a13fe82a27546
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
Take a (py.extras) datetime representing the moment "2022-10-17 00:00:00"
in the timezone of Brussels. Trying to get the related utc moment through
to_utc gives wrongly "2022-10-16 23:00:00". This happens because the
months are not numbered in the same way in Date or datetime, so that in
October for example, the offset applied was that of November which is
-60 instead of -120 (summer/winter change). We fix that problem.
closesodoo/odoo#103579
X-original-commit: ee1a8d26f241f2f7bea6880afcc946119b0e6bd8
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Take a PyDateTime representing the moment "2022-10-17 00:00:00" in
the timezone of Brussels. Trying to get the related utc moment through
to_utc gives wrongly "2022-10-16 23:00:00". This happens because the
months are not numbered in the same way in Date or PyDateTime, so that
in October for example, the offset applied was that of November which is
-60 instead of -120 (summer/winter change). We fix that problem.
closesodoo/odoo#103561
X-original-commit: a11e1fb5f702400fe51938362fe3f24570977ba9
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
**Before**
A traceback is raised when pressing shift-tab on the first column of
the first row in a focused list field as shown in the vid:
https://youtu.be/g97ZTp1QdBE
**After**
shift-tab on the first column of first row will now unselect the list field
and immediately focuses on the previous field.
**Additional change**
We now allow skipping focus on the dropdown toggler by introducing new
props.
closesodoo/odoo#103485
X-original-commit: 9ba9977e42d201035b5299bc13ba03211cddbc1f
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Now that the module web_dashboard has been removed https://github.com/odoo/enterprise/pull/31641,
some props of the reporting views graph and pivot have become unused.
We remove the code related to those props.
X-original-commit: 7d231d1d37707dab4b0ecdd4e2e7cc4535ba6196
Part-of: odoo/odoo#102761
When a x2many record is opened in a X2ManyFieldDialog, it can happen
that the form renderer displayed in the dialog also contains a x2many
that use a kanban or list renderer. In those cases, the View component
is not used. Consequently, the WithSearch component responsible for
making available a search model in the env is not used either so that
a crash occurs at the setup of the kanban renderer (and sometimes later
on for the list renderer). We fix that problem.
closesodoo/odoo#103349
X-original-commit: 2c284317b6dc3c0f0b4e9e376dcee755d81222da
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
This commit removes the code that wrapped legacy fields and widgets
(coming from the legacy registries) into owl components and added
them to the wowl registries. This temporary compatibility layer,
which was incomplete and only allowed us to merge the new views
without converting all fields/widgets in once without breaking
everything, is no longer necessary as we now have converted all of
them into owl components.
X-original-commit: 555959c87e25faa71396f61479e8bb41b66ac164
Part-of: odoo/odoo#102606
Now that all views are converted to owl, that compatibility layer
is not needed anymore.
X-original-commit: 736572b5ae7692e0fe4b61f3331317ff1be16e8f
Part-of: odoo/odoo#102606
Before, even if the checkbox is deactivated, clicking on it
cause an `onChange`.
This caused unexpected behavior, the form view changed to a dirty
mode even if the checkbox was in read-only mode and nothing
was modified.
Now, the checkbox does not call `onChange` when deactivated.
closesodoo/odoo#103429
X-original-commit: 4802c2528cfa23c5981fa30fa69cfa23f28faf05
Signed-off-by: Luca Vitali <luvi@odoo.com>
In commit, odoo/odoo@3c10fcadee
a typo was introduced in the `minWidth` (`769` instead of `768`).
This typo was resulting in a strange behaviour in the webclient when the
width of the viewport was `768px`.
Step to reproduce:
* Open Odoo
* Go to a form view (e.g. Sales -> Select a record)
* Set the size of the viewport to 767
* Set the size of the viewport to 768 => BUG nothing happens
* Set the size of the viewport to 769 => BUG redraw but to late, CSS
already change due to its media break point rules when it was at 768.
Ref:
https://getbootstrap.com/docs/5.1/layout/breakpoints/closesodoo/odoo#103397
X-original-commit: 82d8348d3d5a05e065a07af1924de579cbec3a35
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Have some keys in the context passed to a view.
Have a many2x field in that view that uses those keys in its domain
with some flavor of:
```xml
<tree>
<field name="many2one" domain="[['someField', '=', context.get('some_key')]]" />
</tree>
```
Before this commit, the global context was not added to the evalContext used to evaluate the domain.
After this commit, it is.
closesodoo/odoo#103370
X-original-commit: 93c5e6cbc06bdb6ab2cfc959b68be8088837e1de
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Have more than one Odoo module installed. Go to the Settings.
Scroll the first page.
Change the app in the sidebar.
Before this commit, the scroll position was the same for all modules (or apps, same thing).
It is not wrong per se, but when changing app, there is no reason that the scroll position of the former
is somehow correct business-wise.
After this commit, the scroll position is stored and restored on a per-app basis.
closesodoo/odoo#103369
X-original-commit: 01b16c392b888ceaccc8b0c95da142dbb90517ef
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Have a simple char field somewhere in res.config.settings.
Before this commit, when arriving on the settings form view, the settings page
was scrolled. This was because the standard FromRenderer has and used its autofocus feature,
thus focusing the first text field present in the view.
After that, the Settings form view gave the focus back to its search view input.
After this commit, the FormRenderer's autofocus feature is deactivated.
X-original-commit: 2c67b1dbe15d2cb77ee0b50514a4b9d41a006114
Part-of: odoo/odoo#103369
Do an action in target new that will spawn a record in its form view.
The typical example is "Edit View: XXX" in the debug systray.
On the dialog, click on "Discard".
Before this commit, that button did not close the dialog.
After this commit, that "Discard" button closes the dialog.
closesodoo/odoo#103275
X-original-commit: 08751e0eef0cefe74e626ffa8ba26a5e8f18113f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the basicRelationalModel could not handle the legacy
event "reload" trigger by the basicModel., resulting in crashes.
In particular, when the method "action_archived", via the method `record.archive()` returns an action
(in target new usually) to confirm or ask the user for some additional information, closing that modal
will trigger a model reload via the event.
After this commit, this whole flow is tested and works correctly.
closesodoo/odoo#102826
X-original-commit: 0abb90fb2aa7857990b5f5dae95e9e891125b5fa
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
# Before
A calendar arch without a main color attr that has
some dynamic filters would crash.
# After
No traceback occurs, the default color is used.
closesodoo/odoo#103350
X-original-commit: 54e690b9c789ea862ce3039dd6040e210fa80b39
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Before this commit, click on the "Search More" option in a list many2one
and then selecting an option in the opened dialog would lead to a crash.
This used to happen because the record is updated with a value of the
form [integer, undefined] (that is with no defined label) and nothing was
done in the list model to fetch that label, making impossible to render
the many2one after the update.
Here we make sure that a label is available after the update.
closesodoo/odoo#103271
X-original-commit: 81abccf729ef5b56a8656961931b7489e4364a1f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Have a kanban view grouped on a many2one and displaying that many2one
with a widget in the record cards. Drag a record from one column to
another: a crash occurs. This happens because the record update is done
with a value of the form [id, undefined] (that is with no defined label)
and nothing is done in the kanban model to fetch that label,
making impossible to render the many2one after the update. We fix that
problem by using the known group display name as label for the dropped
record.
X-original-commit: 2a6fe373d48385485933429fbc1e6e3eabd877b4
Part-of: odoo/odoo#103271
This commit fixes the alignment of the progressbar in form views. A fix
that has been introduced in commit fae1d7a3e22bb6d295ca7d0550d425a9b1af934e made
the progressbar aligned to the right in its readonly state, before turning
into edition, which displayed the field on the left. Since the right
alignment is only needed in list views, the style has been adapted to only
show the 'end' alignment on that specific case.
closesodoo/odoo#103203
X-original-commit: 297dfd5499ec50967bf28bb6bf6d1a5d9269b2b5
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
Prior to this commit, the mail preview for gift card wasn't readable in
dark mode.
This commit fixes this issue.
task-2710677
closesodoo/odoo#103163
X-original-commit: 360e8da33fa8b1a607a96eb58fc0dcc5e1b07539
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Prior this commit, there was a height difference between the badges with
an outline and those without it.
task-3012970
X-original-commit: 5a009fa654f40f3348217fff2014f475ce099a49
Part-of: odoo/odoo#103160
Prior to this commit, the badge hover was not readable in dark mode
task-3012970
X-original-commit: eebd6c42a8669a0c4181a59ae5b33d6bc40d6f06
Part-of: odoo/odoo#103160
Prior to this commit, the mobile search colors used in dark mode were
incorrect. This commit adapts the mobile search colors for dark mode.
task-3012970
X-original-commit: 5408fadba20a59ce2e186821350b56b2347f7685
Part-of: odoo/odoo#103132
Since Bootstrap 5.1 cell background color is controlled by CSS variables
in order to effectively handle mixed scenarios (eg. "selected + :hover +
table-info" combined).
Commit https://github.com/odoo/odoo/commit/1d4145dfda1f8a95c3f386ae01fb0e29ddd4be48 forced bg-colors for :hover and :focus states, achieving the
desired result in a simple scenario but inadvertently breaking the
behavior for complex combination and/or different color schemes
(eg. dark-mode).
This commit restore the default BS mechanics for `:hover`, and uses BS
variables to handle `:focus`.
task-3012970
closesodoo/odoo#103118
X-original-commit: 1978a5bfa08a534487d7a70921105f8b5c3a5d30
Related: odoo/enterprise#32740
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Prior to this commit it was not possible to detect/use the default
border-color in within the 'primary_variables` bundle.
This commit define a new `$o-border-color` variable to be used in BS
overrides and by components/functionalities that need it (eg. dark-mode)
task-3012970
X-original-commit: 29cd4ad3601cd6d3d86c8eaa747ddff600061c00
Part-of: odoo/odoo#103118
This commit does 2 things for the draggable hook builder:
- the scrollable feature will apply on the nearest scrollable parent if
the current element cannot be scrolled (removes the need to pass a
parent ref which is not the target container);
- the dragged element is now strictly bound to the current viewport or
the container ref, whichever is the smallest.
closesodoo/odoo#103137
X-original-commit: 70bdf940cc1491fd0cdbae0240d930e8a1d5b25e
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Before this commit the attribute default_order was not taken into
consideration by the kanban view.
closesodoo/odoo#103127
X-original-commit: 0116b590a47c8c12354877498e576ad28e42c1f2
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Before this commit, a list header with no label and associated with a
first orderBy field would be highlighted (i.e. would have the class
table-active). Since this is visually weird, we remove that class from
such a header.
closesodoo/odoo#103108
X-original-commit: 36fb5a0d170d9f5692485d0b2fc374951794cd69
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
The 'transparent' background value has been added by https://github.com/odoo/odoo/pull/99755 to
correctly handle color variations for the backed.
The rule was inadvertently overriding custom designs defined by
website_sale_renting (frontend).
This commit allows to inject dark-mode customization using CSS variables
, while keeping a fallback value used by the frontend.
task-3015397
closesodoo/odoo#103128
X-original-commit: 39442c8f8481d6764699236bc6e1595337dc5d1e
Related: odoo/enterprise#32744
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit adds an implementation of the UserMenu item's type 'switch'
for the BurgerMenu (used in smaller screen).
Note: this commit also adds unit tests for the BurgerUserMenu ; the
asserts are largely inspired by the regular UserMenu tests.
closesodoo/odoo#103102
X-original-commit: 0653ec8672e5878e40c804ea569dfccbd6105edc
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This PR purpose is to ensure that tests are created on OWL Components that have been created in the context of the OWL migration PR odoo/odoo#100729.
This PR also addresses some bugs that have been discovered during tests writings.
task-3001470
closesodoo/odoo#103033
Forward-port-of: odoo/odoo#101967
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Due to a previous fix, attachments uploaded through media dialog would appear in the attachments of mail marketting.
That fix prevents attachments from 'dangling' and being garbage collected later.
That fix is now limited to the mail composer in this commit as attachments are only garbage collected for that model, for now.
related commit: c112361bf9e2f5e7b087c5e5b9a31879856b1da4
task 3003939
closesodoo/odoo#103038
X-original-commit: 69fdca133b06eb66443635bc52d380233580ef51
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
FrancoisGe