When NumpadDecimal is triggered, appending the decimalPoint to the
input field value is not enough, rather, we should replace the selected
range.
Also, we should ignore this for input field of type="number" because
it's natively taken into account.
X-original-commit: 3389cd2226ec82df9aa015637ac2d6a405936a4a
Part-of: odoo/odoo#104114
Reimplementation of 74fa91e0b3 on top of
new version of pdfjs. See previous commit for explanation.
Ideally we would set that behaviour from the outside using
e.g. `PDFViewerApplicationOptions.set` but there are multiple
locations from which we embed the viewer, which makes that a difficult
proposition. There should probably be a clean component which handles
loading the library, configuring it to our specifications (possibly on
a per-embed basis), and exposing both manipulations methods and events
which pdfjs triggers on its eventBus.
Part-of: odoo/odoo#100067
Our current version is getting rather outdated. Replace by
the *legacy* bundle: pdfjs now provides a non-polyfilled version of
the library, which is probably faster though it doesn't save overly
much (for the entire bundle anyway). Use polyfilled version for
safety, though it's unclear whether non-chromium Edge is still
supported by Odoo. If not, we could just use the non-polyfilled
version.
The difference is quite large for pdf.js (+32.5%), however it is much
less consequential for the sandbox (+1%) or for the much larger
worker (+5.6%). The biggest difference is likely performances
but... who knows?
Notes:
- The main reason for this change is that automated vulnerability
scanner have apparently started scanning for `postMessage(..., '*')`
and the previous bundles includes a version of corejs polyfills
without zloirock/core-js#542), therefore triggering those scans. As
the PR notes this is almost certainly not a concern because of the
innocuous payload, but there is no reason to waste time on those
reports if we don't *have* to.
- The bundle now includes "standard fonts", those were removed as
they're heavy and may not be necessary for our usage (?).
- All the bitmap images were dropped and replaced by svgs, which is
nice.
- The local changes since the previous update were *not* impacted in
this, the entire thing was just reset to upstream. This means
changes which were backported (922c7c72, 6943714f) are superseded
but more odoo-specific changes will have to be reapplied in further
commits.
Part-of: odoo/odoo#100067
This commit adapts the codebase to match its enterprise counterpart
where calls to legacy cookie api (cf. web.utils.cookies) are replaced by
cookie_service ones.
closesodoo/odoo#104080
X-original-commit: 724469e19ff83e91a41c6721e334df1ad8d1c02c
Related: odoo/enterprise#33189
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
As the current test suites are "light mode" based and to avoid
unexpected errors when running them locally (due to the cookie
possibibly being already set), the dark mode is disabled
for the following suites:
- `web.qunit_suite`
- `web.qunit_mobile_suite`
- `web.benchmark_suite`
X-original-commit: 3f1b44f0d2ce72f79308ef36cd72ea3f7b82b186
Part-of: odoo/odoo#104080
Before this commit, if an invalid list view is left, then a "View can't
be saved" error dialog is displayed.
The expected behaviour is a notification indicating the invalid fields.
How to reproduce:
- Go to a list view with at least one required field
- Create a new record
- Edit this record while leaving the required field empty
- Leave the view
Before this commit:
You stay on the view and get the "View can't be saved" error dialog.
After this commit:
You stay in the view and you get a notification "Invalid fields: "
with the invalid fields displayed.
closesodoo/odoo#104082
X-original-commit: 98fbacd8511594ca7a8cc9f0afa5d199a9b2ff20
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit, in a list view, if you click on a readonly field of
a record in edit mode, then it switches to readonly mode.
Why ?
The "pe-none" class added to readonly fields will prevent clicking on it.
Our click will then be applied to the table causing a unselectRecord
on the list.
How to reproduce:
- Going into an editable list view with a readonly field
- Click on a field to switch the record to edit mode
- Click on the readonly field
Before this commit
The record switches to read mode
After this commit
The record stays in edit mode
closesodoo/odoo#104070
X-original-commit: 52c817b88b5c799322a19f49807126928d9f28e1
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
Before this commit, in a multi_edit list view, if you click twice on
a readonly field, the focus is placed on the readonly field.
How to reproduce ?
- Go to a list view in multi_edit="true" mode with a readonly field
- Select a record
- Click on the readonly field of the selected record
- The record goes into edit mode and the focus is placed on the editable
field following the readonly field
- Click a second time on the readonly field of the selected record
Before this commit:
The focus is placed on the readonly field.
After this commit:
The focus is placed on the next editable field.
X-original-commit: aac7e6e4de371dcd01028a3a9ab66eed022c1ef0
Part-of: odoo/odoo#104070
In a kanban arch, have a dropdown that don't have a toggler, just an
explicit menu.
Before this commit, there was a crash.
After this commit, the kanban and the dropdown are correctly rendered.
closesodoo/odoo#104019
X-original-commit: 01418c474cb02455660156cf47822588f0554376
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Have a kanban arch with a field in display full in the kanban card template
```<field name="fieldName" display="full" />```
Before this commit, the class that should endup in the DOM was wrongly computed.
Technically, it was quoted in the owl template as if we passed it to a Component.
After this commit, a field having display="full" is correctly rendered.
X-original-commit: 526eb4f875ec6736d4b76da1fbdbcc99a8c33a9b
Part-of: odoo/odoo#104019
Before this commit, the usage that KanbanRecord makes of useViewCompiler was faulty in that
it did not respect the hook's API (the last argument is a dict params, not a string).
After this commit, the usage of useViewCompiler by KanbanRecord is correct.
X-original-commit: 8dbf7c88742e4603543005a1d5a158e5e0db2feb
Part-of: odoo/odoo#104019
The new WOWL Kanban view supports that luxon be used in the archs.
Legacy kanban had a similar support but for moment.js
Obviously, new archs can't work with legacy implementation because of this.
This commit aims at providing some sort of hackish support, only valid in
the transition phase.
At least one use case has popped up, that is, when editing such kanban view with Studio.
In that case, there was a crash, which is fixed with this commit.
closesodoo/odoo#103821
X-original-commit: 14f56b324d241f35b742781424535cecf26a218e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, fields using Many2OneField in their template (for
example, the many2one_avatar field) had a wrong style for the external
button (the arrow on the right to open the record in form view).
closesodoo/odoo#103981
X-original-commit: c63493ab7b19a238304b2d7791c28bf1a52c0d2f
Signed-off-by: Luca Vitali <luvi@odoo.com>
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 file is only necessary for the website.
closesodoo/odoo#102606
X-original-commit: 71584d7846dc76d8cbe0f19c283ccc7711e157a9
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@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>
Joseph Caburnay