This fix is a continuation of an old fix https://github.com/odoo/odoo/pull/121689
After fixing the display of numbers to be always on the right , The symbol also should be display the same as in english from ltr.
Also the headers and the footers are not placed well, they should be aligned with the numbers.
Steps to reproduce the issue :
1-install arabic language
2-go to accounting / customer invoices and you can see the placement of the symbol is reversed
opw-3295573
closesodoo/odoo#127231
X-original-commit: 8fcdc24abf4734d020cb41392a2e449a73433d3b
Signed-off-by: Bastien Fafchamps (bafa) <bafa@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
This commit adapts several spacing issues related to the formView and
alerts.
task-3355091
Part of task-332626
closesodoo/odoo#127201
X-original-commit: a137b33dbbf0d18ac6909f958d126c7922d12a61
Related: odoo/enterprise#43579
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Since the introduction of Milk design[1], the fixed width for icons has
been removed in `view_button`.
This creates alignment issues when we have several buttons with icons
displayed in a grid or list (eg. status buttons).
This commit fixes this issue.
[1] commit 824024f
task-3387198
Part of task-3326263
closesodoo/odoo#127090
X-original-commit: a801dc6c74031e5593063ccac0245b2fe32c8ef3
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
We make the domain selector accept any expressions in the first and
second components of a domain condition. Along the way, we have found
necessary to refactor the Tree type (see domain_tree.js) and use it
directly in the domain selector instead of having yet another auxiliary
structure. Another simplification brought by this commit is that the
virtual operators is, is_not, set, and not_set are introduced earlier
and make possible to simplify the way operators are managed.
closesodoo/odoo#126350
Related: odoo/enterprise#43161
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Some props like className were declared as optional in TagsList while
they are not used by the component. We remove them from the props
declaration.
Part-of: odoo/odoo#126350
We make TagInput use the generic component TagsList. This gives a better
looking/working to the editors used for the operators "in"/"not in" for
char fields.
Part-of: odoo/odoo#126350
A string representation of a domain like "[('bar', '=', false)]" is
evaluated by py.js the same way as "[('bar', '=', False)]".So both domains
are recognized as correct while false is not a valid python expression.
We do the same in domain selector, the expression "false" ("true")
will be understood as "False" (resp. "True").
Part-of: odoo/odoo#126350
The computation of the default value used by an editor used to assume
that the (default) operator is equal. We now pass the operator info to
getDefaultFieldValue in order to be able to have a different default
operator ("in" will become the default operator for relational fields).
Part-of: odoo/odoo#126350
The key negate is defined as mandatory in the definition of the type Tree.
We add them at some places (event if it did not pose a problem for now:
undefined and false are both falsy).
Part-of: odoo/odoo#126350
This commit makes the datetime hook independant from the props update
mechanism it previously relied on (onWillStart & onWillUpdateProps) to
update its internal props.
This was an incoming issue as the future relational model will rely on
fine-grained reactivity to update the fields rather than updating the
model and re-rendering all child components (effectively calling
'onWillUpdateProps').
Now, the hook relies on an internal state that tracks whether the props
given by its caller changed from one render to another, which is checked
at render time (i.e. in 'setup' and 'onWillRender').
closesodoo/odoo#125039
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, 2 implementations of a "shallowEqual" function
coexisted, one in 'web/core/utils/objects.js' and another in
'web/core/utils/arrays.js'.
This commit only keeps the one in objects.js and makes the other simply
import and export it as well (easier to maintain while also easier to
find for those who want to work with arrays), while also taking an
optional comparison function argument in case the comparison needs to be
more specific (e.g. compare DateTime objects).
Part-of: odoo/odoo#125039
This commit adds the enable_formatting option to integer and float
fields. This allow an input to display and handle unformatted values,
independantly of the localization setting.
A test has been added for each type of field to verify that the
value is entered with the default formatting as 'raw' values.
task-3307126
closesodoo/odoo#121495
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This commit simply adds documentation in the supportedOptions of the text
field as well as the progressbar field. Since the support of documentation
has been added recently, those options were not yet documented in the
widget declaration.
This will improve the usability of those options in places like Studio
Part-of: odoo/odoo#121495
Current behaviour:
When creating a new record with a many2many widget, in the modal
window, any modification done after record creation (for example
clicking on the status bar buttons) aren't being saved once we "Save
& Close" the modal window.
Expected behaviour:
All changes should be saved, regardless if we clicked the status
button that trigger *some* action.
Steps to reproduce:
- Install Project
- Settings > Sub-tasks or Task Dependencies
- In a task on a project, add a subtask > New
- Set the title to "Title 1" > Change the stage > Set the title to
"Title 2" > Save & Close
- Observe the title of the task is "Title 1", not "Title 2".
Reason for the problem:
When we click on a status button, since it can trigger *some* action
in the backend, it forces the creation of the record front-end side,
which generates a `resId`. Upon saving & closing the modal window,
the record is not saved, only it's resId is appended to the list of
`many2many` records.
Fix:
Before appending the record to the list, we save the record if it's
dirty.
Affected versions:
- 16.0
- saas-16.1
- saas-16.2
- saas-16.3
- master
opw-3289908
closesodoo/odoo#127009
X-original-commit: 29aeafda0f75764ec5b30147fec422b47a4da164
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
* = account{_payment}, base, onboarding, payment{_stripe},
sale{_management}, web, website_sale
Use the dedicated onboarding module introduced in 16.0 instead of
the res.company model to store onboarding progress.
It allows
* onboarding steps to be reused across panels
* to support steps that should be completed per-database or per-company
* to clean the res.company model from many fields and methods,
* to remove many views, controllers, actions
Module-specific notes:
* account: We also clean the remaining two steps that are not
part of an accounting panel but make the most sense to be kept here.
* account_payment: Following 8e4e8eb8, the payment provider step is
added to the invoicing onboarding panel. We apply this change here too.
Also impacts the website_sale_dashboard panel (see related ENT PR).
(The "sale tax" one is currently used for to the website sale dashboard).
* payment: Note that the step was already not part of an onboarding
panel within this module.
* website_sale: We clean
* a field not used (The website_sale dashboard onboarding panel used
the payment_provider_onboarding_state field).
* a method that was only called from website_sale_dashboard, so it is
moved there. See related ENT PR.
Includes a few tests.
Moving views/templates/styling, as well as cleaning residual onboarding-related fields and methods in base, including populate.
This also includes restoring the "onboarding_complete" overlay panel
animating it to disappear after a few seconds so that it doesn't hide
text and block buttons to re-open steps.
Task-3025136
Part-of: odoo/odoo#104223
Since [1], an error was introduced when using the translation button on
a list view. This error occurs in a non-deterministic way. The issue
occurs because without the option stayInEdition when saving the record
before opening the translation dialog, the row is switch to readonly,
and the translation button is not opened.
This occurs in a non-deterministic way because there is a mutex in a
mutex. When switching the modes (in a save with mutex) a second save is
perform (with also a mutex), this commit will also fix this issue.
runbot-issue-id: 22339
1: e2d28e269dclosesodoo/odoo#126942
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since [1], a test introduced in [2] was failing undeterministically.
**Explanation**
Commit [1] introduced a positioning recomputation when a load event
occur in the target's document.
The failing test in [2] loads an inline stylesheet inside of an iframe
without waiting for it to be loaded.
When the test failed it was because of the "load" event of the
aforementioned stylesheet that occured at an inappropriate moment.
Now the test awaits for this event.
Note that within the same conditions in the real world, we want to
make sure the popper is repositioned.
So this current fix is a bit cheating but the test is about testing
an unrelated behavior, so this is acceptable IMO.
Runbot error id: 22544
[1]: 532c4cfa4e60bc9531
[2]: 208a1277750d63eef3
closesodoo/odoo#126938
X-original-commit: 3ca170bf31ca6e6f12293f0dabe106d385773333
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Before this commit, in other numbering systems than "latn", the time
pickers did not allow to select hours/minutes/seconds. This was because
the lib (TempusDominus) would use `parseInt` internally to retrieve the
selected value, which was not a latin number in other numbering systems.
This commit changes 2 things directly in the lib file:
- allow the internal `getMoment` function to accept a second 'format'
parameter;
- use that same `getMoment` function to parse the text of the selected
value, effectively using moment to both parse and format the values
displayed in the picker and ensuring consistency.
OPW-3258034
closesodoo/odoo#126711
X-original-commit: de6bc96afdc61b57493bcbde0b8f3479cc6ebd71
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
When you are sorting agregates of groups and you have more groups than
the limit, you get a traceback.
It is because you give the orderby to the private _read_group that is
not managed the same way when you pass it to the private _web_read_group
so it doesn't correctly build the query.
As we are calling _read_group to count the groups, we don't need to
order it. So we don't.
closesodoo/odoo#126862
X-original-commit: 6fdf86823088e0e413bef72dc0f20f926aa8f10a
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
Bug
===
The many2one properties to res.users and res.partner have an image
with the avatar. But the size was applied only for the res.users
model (and it was implemented in /mail and not in /web).
Remove the `width: auto` because it's redundant with `aspect-ratio: 1`.
Task-3377098
closesodoo/odoo#126835
X-original-commit: e05caa80120bd5bc7ba0b078c3237daddae995ed
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Steps to reproduce the bug:
- Drag and drop several snippets onto a web page in edit mode to make
the vertical scrollbar appear.
- Drag and drop a popup onto the page.
- Drag and drop snippets into the popup so that the height of the popup
exceeds the height of the viewport.
- Try to scroll the popup downwards by clicking and dragging on the
scrollbar (not using the mouse wheel).
- Bug: the page is scrolled instead of the popup.
Note: This bug occurs in Chrome (not in Firefox).
This issue occurs because two scrollbars are present at the same
location (one for the page and one for the popup) and they overlap each
other. Normally, Bootstrap removes the scrollbar from the body when a
modal is opened, and this behavior was adapted for the #wrapwrap element
with this commit [1]. However, when transitioning to Bootstrap 5, the
code that overrides Bootstrap was removed instead of being adapted (this
was done in this commit [2]).
In later commits [3] and [4], we continued to remove code that updated
the scrollbar based on the opening of a modal because this code was
causing errors due to the fact that it was incomplete without the part
removed by commit [2].
This commit restores the original behavior (before the deletions made by
the aforementioned commits) by restoring the missing code and properly
adapting it to Bootstrap 5.
[1]: https://github.com/odoo/odoo/commit/9cf8b97fe40444b44ebb6e6fb992bc658a087d32
[2]: https://github.com/odoo/odoo/commit/0b94da214b7017e8580e671cbaa68ade6de2fbc7
[3]: https://github.com/odoo/odoo/commit/cb7cf77ed080e86f800af61c9a3dc4ad36ad6cfb
[4]: https://github.com/odoo/odoo/commit/51939d09f84579f61f1ff77aacd754beba036dc2
task-3102275
closesodoo/odoo#126709
X-original-commit: 0e75f1c01ca4fcc3eb483a7256bcf72b2bca39c3
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Issue:
------
When a list view is editable and we add a `Group By`,
the create button in the header is no longer available.
This is annoying when we are working with default filters
and do not have any records.
Solution:
---------
Add the "New" button in the header of the list view
and redirect to the form view when we use it.
opw-3304692
closesodoo/odoo#126710
X-original-commit: 8332cca8926a8d032f921b39520227070303fcc5
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
1. Introduce primary variable to simplified overridden value of
`$min-contrast-ratio` and document its need.
2. Reduce `$min-contrast-ratio` to 2.9 to solve the inconsistency with
the previous version 15.0 of text color over some background color.
Of course it won't restore everything to the way it was: we still
want the version 16.0 to be an evolution over version 15.0 using what
bootstrap recommended to compare contrasts. But as going from 3.0 to
2.9 should not impact existing websites too much and solve use cases
we feel need solving, we feel it is an ok change.
3. Restore override of the `color-contrast` method that will now
handle the transparent colors. Before this commit, a color-contrast
function was just considering RGB value only, after this commit it
will consider RGBA value, relying (by default) on the fact the body
background is the background behind the colors we are comparing.
task-3241031
closesodoo/odoo#126759
X-original-commit: 313220ed4a0ff4ae26eb113a3a88b0dc44b649fe
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Divyesh Vyas (divy) <divy@odoo.com>
Release notes:
https://github.com/odoo/owl/releases/tag/v2.1.4
This release contains mostly devtools improvements, but there are three
small bug fixes as well:
[FIX] blockdom: properly merge dynamic class values
[FIX] parser: make t-on stricter
[FIX] compiler: apply translations to t-set text body
closesodoo/odoo#126755
X-original-commit: b26a66d928aad283c7ec17d767c6bc1e42e24206
Signed-off-by: Nicolas Seinlet (nse) <nse@odoo.com>
Signed-off-by: Géry Debongnie <ged@odoo.com>
=== ISSUE ===
With Milk, we introduced a change related to the active state color
meaning that the `active` state should use the following SCSS variables:
- $o-component-active-bg for the background ;
- $o-component-active-color for the text ;
- $o-component-active-border for the border.
The datetime_picker component was currently using the primary variable
which is not the expected color. This change also affects the different
states of the datetime picker (hover, click, ...)
=== AFTER ===
We apply the right variables on the component for consistency purpose,
and make some little design adjustments using `:before` and `:after`
pseudo elements to stylize the different states.
task-3329797
part of task-3326263
closesodoo/odoo#126728
X-original-commit: df0e75d36bfe85bdbe0a9823003e0849c17a9405
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit,
In the knowledge app, the date and datetime property fields are not visible in
the item-kanban.
Technical Reason:
In the previous version's date and datetime property field values are of
string type in a non-ISO format. However, from the version 16.2, the values of
date and datetime property fields are of datetime object, which parsed into the
string type ISO format, that's creates the formatting issue.
After this commit,
Now the date and datetime property fields are visible in the item-kanban.
Task-3324573
closesodoo/odoo#126657
X-original-commit: c2868b0c18bc89fd06c7bee43488a1fb1fc4bb67
Signed-off-by: David Beguin (dbe) <dbe@odoo.com>
This commit improves the appearance of property fields in the Kanban view of
item Kanban. A label will be shown for the integer, float, date and datetime
property fields. Additionally, The boolean field now has a badge appearance
with a label.
Task-3291930
closesodoo/odoo#126707
X-original-commit: 25e8fbe0a1327c289df826cf6eb7882098a4c325
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This commit adds Bootstrap JS assets to the web.report_assets_common bundle,
enabling basic interactivity in reports. Currently it is only necessary to allow
JS in the report_layout template.
#104794 removed all JS from reports, stating that they don't need any
interactivity. However, reports do sometimes require a bit of JS. An example is
the Green Savings Report in Sign (see task), which contains a Bootstrap modal.
By adding Bootstrap JS assets to web.report_assets_common, we can make the modal
work again. Additionally, we can fix/add basic interactivity in other reports if
necessary.
task-3285597
closesodoo/odoo#126638
X-original-commit: 21caa81fad84d05b76bd178242a991eef803e4b8
Related: odoo/enterprise#43263
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Viktors Lipskis (vili) <vili@odoo.com>
Adding an override for new secondary outlined buttons that was
missing in community
Task-3380259
Part of task-3326263
closesodoo/odoo#126604
X-original-commit: ddf77772c7f02a002da4525545111e9f501b07eb
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
Purpose
=======
In the documents modules, we don't need to give the close props,
and so instead of giving a dummy method, we make it non-required here.
Task-3290796
closesodoo/odoo#126633
Related: odoo/enterprise#40441
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This PR improves the livechat session history list view:
- Clicking on a session opens the channel in discuss if the
user is a member of it. Opens the form view otherwise.
- Display duration of the session (last message datetime - first
message datetime)
- Display country of the visitor
part of task-3332872
closesodoo/odoo#125899
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The issue happens when we have a really small percentage of tasks with a certain state and it’s very difficult to filter them clicking on the respective color in the progress bar. To fix this issue there was defined a minimum of 5% for each color and make sure that in the end the sum of values is exactly 100%.
To solve this issue, it was necessary to set a minimum of 5% for the width for every non-empty bar, also it was defined a max-width of 100 - (# non-empty bars -1)*5 % because we also have to ensure the sum of 100% at the end.
How to reproduce:
1. Go to Project -> tasks -> create a huge number of tasks in the same project (you can do it using interactive shell)
2. Change one of these tasks to another state (eg: done)
OPW - 3299363
closesodoo/odoo#126569
X-original-commit: bb533d8431d9adeb57539f7730649eb933fec105
Signed-off-by: Matheus Leal Viana (malv) <malv@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
The label of a facet with type "comparison" did not have any
background color. We set it to be the same as for the label of a facet
of type "groupBy".
closesodoo/odoo#126496
X-original-commit: b0527528ee73b503ffbfef491b2389018c119376
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
The label of a facet of type "comparison" had the role "button" while
click on it has no effect. That role should be reserved for the label of
a facet that is associated with a domain (e.g. a facet of type "filter").
X-original-commit: 4c649abf491b32c218769b0bb1eba19881dedbb0
Part-of: odoo/odoo#126496
Since [this other commit], initializing the color picker could trigger a
traceback. The traceback was due to the fact that for users to be able
to drag/move the color picker as they wished across different frames, we
needed access to the document of all the frames on the page.
Unfortunately, if one of these frames was not of the same origin, a
traceback was displayed. This commit corrects how we collect documents
from frames on the page, by only taking those whose document we have the
right to see (which do not raise a cross origin error). I didn't succeed
to reproduce the bug locally, but I got it on the runbot with theme
Nursery / Kiddo by dropping the block banner on the page, the error
appears because the block contains a vimeo video. In fact, you just need
to have embedded content (youtube / vimeo / ... video for example) start
edit mode, click on the block containing the video and the error is
displayed.
[this other commit]: https://github.com/odoo/odoo/commit/63bf363d302fe9f93a824fa6f1ff3bbe21f98088
runbot-22573
closesodoo/odoo#126447
X-original-commit: b22c1d942374014e0d50e5429c3f89cc1ca18173
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
When processing the buttons in the header of the arch,
the listArchParser did not use the method on this.
This was a significant drawback when trying to extend
the behavior of the parser.
After this commit, the processing of the button goes
through the existing method on this, making it possible
to extend that behavior. Note that for the processing
of the other buttons in the arch, this modification has
already been done earlier.
task-3072937
closesodoo/odoo#126400
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When a user changes a header setting, the record should not be marked as
dirty. If the user clicks on a button, the save dialog should not be
shown.
Next commit will bring a functional test and "steps to reproduce" of
this issue in website.
task-3265100
X-original-commit: 1a64fd83f8be677b76ad97a11928859c63709972
Part-of: odoo/odoo#126387
Co-authored-by: "Guillaume (gdi)" <gdi@odoo.com>
With [1] and [2], the colorpicker / colorpalette were implemented. In
both cases, for the custom colors hue / saturation / lightness selection
we listened to mousemove/mouseup events on the whole body / document.
That is to be able to start dragging the color cursors from inside the
colorpicker to anywhere on the screen (the cursor being confined into
their own box of course).
Problems occur when iframes come into the equation. Indeed, from that
moment, listening to mousemove events on an unique document is not the
way to go as mousemove over inner iframes will be ignored. This should
not be the case anywhere in 15.0 (that this original commit targets).
The only iframe there should be the mass_mailing one and in that case,
the colorpicker is inside the iframe so it should not be a problem.
However, [3] (then fixed by [4]) were meant to tackle a similar problem
(although [3] seems to say the goal was to ignore mousemove outside the
iframe which is the opposite of what this current commit tries to do:
listening on the whole screen). However, by doing so, a memory leak was
created as the document on which the events were bound was not properly
cleaned as the `destroy` which unbinds the events was not adapted. That
is the main reason why this commit targets 15.0 (although, the solution
here still makes sense generically in 15.0 and should make the code
simpler and easier to understand).
In 16.0, however, the iframe situation is a problem: the website builder
colorpickers are now in the main document but the edited content is
inside an inner iframe. In that case, listening to the main document's
mousemove/mouseup events makes the colorpicker only work when not
hovering the edited content (which could be acceptable but not perfect).
Note that during that website builder refactoring, [5] worsened the code
of [3] and [4] to do exactly that. Later, [6] was made to solve an
unrelated problem and actually woke up that worsened code, not
understanding what the new undocumented `ownerDocument` option was for
(it will stay like this in stable from now on, as it will be not used
anywhere anymore... hopefully). Because of that, the situation became
the opposite: dragging inside the colorpicker did not work until the
edited content was hovered. And because of that functional fact, an even
more visible problem was created:
- Click on a snippet
- Select a custom background color using the hsl selection
- Hover a non custom color (like nearly always the case "by mistake"
after configuring a custom color, your mouse just moves over the non
custom colors) => your custom color is lost
This was because the chain of events that were listened inside the
colorpicker were gone (because of the combination of [5] and [6]). In
the end, this only revealed the shortcomings of the implementation in
[1], [2], [3] and [4]: we should not try to search which frame we have
to listen to: we should listen to the whole screen. This commit solves
the issue by listening to the top window document and all its inner
iframes, also fixing the memory leak mentioned earlier.
task-3332711
[1]: https://github.com/odoo/odoo/commit/29f0c0a186a9a60d6e5b7f026c305d689b6fc807
[2]: https://github.com/odoo/odoo/commit/99910b526ed792235a778863b993d10cf4e77cd7
[3]: https://github.com/odoo/odoo/commit/4fb33f7f8d6955a44fbb7c94c7d204e9baa09707
[4]: https://github.com/odoo/odoo/commit/f1b26335a286a47f685b7830db97c21e6fefd68b
[5]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
[6]: https://github.com/odoo/odoo/commit/418c1178301e28b4bd1412da6d0558e219060830closesodoo/odoo#126313
X-original-commit: e03158e6da45d83c977b7cf51f0f998343dc6fd6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
It is more conventional to bind extra events in the `start` of widgets
instead of in their `init`. Indeed, the handlers often make sense only
if the widget is already in the DOM.
Related to task-3332711
Part-of: odoo/odoo#126313
Steps:
- Install studio.
- Open studio.
- Click on reset default view.
Issue:
- Confirmation dialog body display in single line instead in
multiple lines same thing happens in pos confirmation dialog
also in new friendly message task we need to display error
message in multiple line.
Cause:
- There is a style missing on body of that dialog to preserve
white spaces also need to use other tag then <t> to apply
proper style
Fix:
- Use <p> tag instead <t> tag and add a `text-prewrap` class
in bootstrap utility class and use this class in `<p>` to
preserve space.
task-3356114
closesodoo/odoo#125300
X-original-commit: 700d41d2f007124390b7cafca0a2e58a467e2b43
Related: odoo/enterprise#42842
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
After this commit, underscore library is totally removed.
Library calls has been removed from manifests.
Library files has been deleted.
This commit closed the task below.
task-3246238
closesodoo/odoo#125889
Related: odoo/design-themes#662
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
The purpose of this commit is to improve the design of the Property field
modal as it was done to release something fast.
We also introduce a modification of the JS test related to the property
header. Before this commit, the structure of the modal was composed
of a header and a body.
Since we refactored the component in one single block with the class
`.o_modal_container`, we apply the `.o_field_property_definition_header`
class directly on the input rather than targeting an input inside the
header.
task-3084756
closesodoo/odoo#126274
X-original-commit: 12a25449d9f26aec5f14482952ca0db40bf612b9
Related: odoo/enterprise#43091
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Removing ps-0 class that was breaking the default button padding
To deal with the possible aligment issue when `btn-link` is used
alone (as this button style has no background), we are switching the
second possible type of buttons to `btn-secondary`. It also matches
with the `btn` combinations used in modals
closesodoo/odoo#126246
X-original-commit: 16237b7ee064a4a7047d0eb6d58a477b048daf67
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Prior to this commit, when a filter or a dropdown item had a long name,
the layout was broken on mobile, the item went out of the viewport and
wasn't readable.
This commit fixes this issue.
task-3378207
Part of task-3326263
closesodoo/odoo#126071
X-original-commit: 96d1edcdba78af3572c3395867e561c0eb3d5054
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
The goal is to provide a better feedback to the user, especially in
mobile mode. With this commit, when switching menus, we clear the screen
and display an empty control panel (only for act_window actions though)
so we have some initial content that get filled as soon as the
view/action is ready.
Task 2900847
closesodoo/odoo#124068
Related: odoo/enterprise#43038
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Mahdi Cheikh Rouhou (macr)