Strings within inline templates are not translatable, so we convert
these templates into standard templates so that they can be.
Task-3761551
closesodoo/odoo#162106
X-original-commit: 5b38d58db1bb7cacd2a5ffa195a3799f2645fdbb
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Mohammed Basioni (basm) <basm@odoo.com>
Given the changes in [1] and subsequently in [2], which in some way
counteract the RTL adjustment, it is necessary to eliminate the rtlcss
directive from the carousel CSS to ensure the correct behavior.
Steps to reproduce:
- Enter in edit mode.
- Drag and drop an image gallery and a carousel snippet.
- Navigate to the theme tab.
- Add an RTL language (Arabic, for instance).
Bug :
- The images slide in incorrectly during transitions. In RTL mode, when
clicking on the left chevron, the next image should appear, not the
previous one.
If we have three slides numbered 1, 2, and 3
- In RTL mode: Clicking left should navigate from 1 to 2 to 3 and then
back to 1.
- In non-RTL mode: Clicking left should navigate from 1 to 3 to 2 and
then back to 1.
The directional Font Awesome icons (classes starting with `fa-` and
ending with `-right` or `-left`) are not flipped in the mobile viewport
as a result of [3]. Necessary adjustments have been implemented
to prevent this behavior.
Upon investigation, a more significant bug was discovered regarding the
'oi-...-[right/left]' icons. These icons were not flipped appropriately
in the frontend when the webpage context was set to an RTL language. A
pull request has been created and merged to address this issue [4].
More info on rtlcss [here]
[1]: https://github.com/odoo/odoo/commit/ebb61753bf3d3dd8d3f53db088112b9e4beb813d
[2]: https://github.com/odoo/odoo/commit/c48f57ea2538ad51e00ac27d58f8e191781444f3
[3]: https://github.com/odoo/odoo/commit/be375bb2a886edd002f042355455a71fcac4daf5
[4]: https://github.com/odoo/odoo/pull/157214
[here]: https://rtlcss.com/learn/usage-guide/value-directives/#tip
opw-3747848
closesodoo/odoo#162202
X-original-commit: 7f0f750b0d9e45982130742af2ac396d1985612e
Related: odoo/enterprise#60922
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the issue:
----------------------------
1. Enable dark mode
2. Go to Project app
3. Create a new project
4. Click on `See examples` in the kanban
5. Select an example.
Actual Behavior:
---------------
The name of the selected example is in black instead of white.
Expected Behavior:
-----------------
The name of the selected example should be in white.
Solution:
--------
Update the font color of the selected example name to white for better
contrast in dark mode.
task-3602610
closesodoo/odoo#162133
X-original-commit: 60d1580d4bc493c2572ac7c223df3c72f53873bd
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
After this commit, `colorField` is used instead of `cardColorField` to
handle color change from the dropdown of cards in the kanban view.
The value of `colorField` is observed in order to adapt the HTML classes
of `oe_kanban_card` (first `DIV` of `o_kanban_record`) by
adding/removing `oe_kanban_color_X` (where X is an index representing a color).
opw-3823860
closesodoo/odoo#161645
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>
This commit fixes a bug where the value of an autocomplete with autoselect
could go into an undefined state where the model value doesn't match the
input value but no change is detected. This would happen on escape press,
scroll and more recently due to https://github.com/odoo/odoo/pull/159333
on click out. To fix this issue, the commit introduces some change in the
autocomplete behavior so that it will no longer select the active option
on click out (blur) when autoselect is active and instead it will revert
the input value to the one stored into the model. Also applies this
behavior on escape key press and scroll for the before mentioned reasons.
Steps to reproduce:
- Go to CRM form view
- Edit the salesperson name to some non existant one and click out (or
scroll or press escape)
Before the fix, the name was stuck to the invalid one but no change was
detected so we couldnt save it. Before https://github.com/odoo/odoo/pull/159333,
click out would select the active option of the dropdown instead (and
launch a dialog for quick create). This is removed because the behavior
is neither intuitive nor practical. After the fix, the name is reset to its
previous valid value instead. This applies to all autocomplete components
with autoselect prop set to true.
closesodoo/odoo#162040
X-original-commit: 9d9026ed0c7bb0af6cf910cc206cf8b55d1b7a36
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
This is a followup on [1].
In Chrome the event's currentTarget is cleared after events such as
"scroll" are handled. For asynchronously called methods to be able to
access it, the current value of currentTarget needs to be kept.
To help developers that might stumble on this issue when using
`throttleForAnimation`, this commit emphasizes the fact that usage of
that function is not limited to event handlers, and it adds a test case
that illustrates a solution for tracking the lost scroll event target.
No scenario was identified in 15.0, but this could be used as an
alternative solution for [1].
[1]: https://github.com/odoo/odoo/commit/0ba601d2ef5c4e2f846818e78dcd23966d6f563d
task-3449843
X-original-commit: 6cc4cbf2b91d624368c489460a90795921985f6b
Part-of: odoo/odoo#161850
Commit [1] introduced a fix for old browsers to make the `at` method of
the Array class. It did so by simply adding a property on the prototype
of the Array class.
Unfortunately this way of adding a method means that it is exposed in
`for...in` loops.
To avoid this, this commit uses Object.defineProperty and sets the
property as not enumerable, removing it from the for..in loop.
[1]: https://github.com/odoo/odoo/commit/6e39e31030c28a8eb09ddcd93ca9ca382b4f6f10
opw-3824593
closesodoo/odoo#161891
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit removes the unnecessary duplicate of the 'o-input' class being present
in the template of the (Multi)RecordSelector components. As the RecordAutocomplete
component uses the Autocomplete component, which already set this classname on its
<input> node, the class was present twice in the DOM.
This could affect the style when trying to write a rule on .o_input since both elements
would get the style.
Now, only the input keep the class, which makes things easier and more predictable.
closesodoo/odoo#161934
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
This commit will make a `willDrag` information available to the
draggable_hook_builder context.
This is needed to fix a resize issue in the gantt view.
See correlated enterprise pull request.
closesodoo/odoo#161670
X-original-commit: 53254591c4a6a31483f409aa2fa072ac2ed0b3db
Related: odoo/enterprise#60623
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
The patch function was changed at commit [1]. This introduced a call to
`Object.hasOwn` which is the preferred way to check if an Object has a
property as its own. However, after multiple user reports, it seems like
a significant amount of user and website visitors still use browsers
that do not have Object.hasOwn implemented.
This commit adds a polyfill to add Obejct.hasOwn in case it is not
found.
[1]: https://github.com/odoo/odoo/commit/04fddc19d4aedd8105e0fda5582288c2bb1833fe
Fixes https://github.com/odoo/odoo/issues/142022
opw-3824593
Part-of: odoo/odoo#160758
Since [1] positioning of popovers targeting an element contained in an
iframe is permitted.
This commit will ensure the popper's element positioning is correct in
the following case: have a popper
- outside an iframe
- targeting an element that is inside it
- and no container element has been given (default is used)
**Before this commit**
The default container that is used is the target's owner document
element, a.k.a. the iframe's html element.
**After this commit**
The default container that is used is now the popper's owner document.
** Side notes **
This bug has been found when working for the following taskid-3603843
It is required for this task and will get fw-ported through the master
branch.
[1]: d6afa9f325closesodoo/odoo#161568
X-original-commit: e664b2367f482aa6edc492db16ec92ffff1ac0a1
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Issue:
======
traceback when clicking on gradient colorpicker in mass_mailing
Steps to reproduce the issue:
=============================
- Got to email marketing
- Add some text
- Select the text and go to graadient and activate custom
- click any color in the colorpalette -> traceback
Origin of the issue:
====================
Some colorpickers are created inside the snippets sidebar and then gets
removed by `_updateRightPanelContent` in `SnippetsMenu` so the owl
components corrosponding to them will have `this.el = null` which will
cause a problem when updating the props since we will use it in the
update.
task-3834112
closesodoo/odoo#161275
X-original-commit: 9ccd820813f6c0bd7608e80570a6999577aff513
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Have a form view that has twice the same x2many field, excpet the first one is invisible=1.
The second occurence has a context with the form_view_ref key.
The x2many should have at least one record.
```xml
<form>
<field name="x2m" invisible="1" />
<field name="x2m" context="{'form_view_ref': 'some_ref'}">
<tree>
<field name="display_name" />
</tree>
</field>
</form>
```
When opening a record, the context was not taken into account, yielding the wrong form view to open that record.
After this commit, the form_view_ref context key is taken into account, and the right form view opens.
opw-3845448
closesodoo/odoo#161253
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps:
Install web_studio
Change language to French
Open any form view and enable Studio
Add a datetime field and click on it
In french we have the following message:
"Première date acceptée": Date formatée ISO ou "aujourd'hui" He says that we can use the string "aujourd'hui"
when we only expect "today" in English.
This commit changes the help text to display "today" in every language
opw-3829954
closes odoo/odoo#160904
Forward-port-of: #160144
Forward-port-of: #159654
Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>
Steps:
- Install sales app.
- Go to settings of sales.
- See header field there is no download button.
Issue:
- Binary field should have download button and
user should be able to download file with out
issue.
Cause:
- Since Settings is abstact model so it does not
contains id field in it and download button visibility
depends on id field.
Fix:
- Extend binary field for setting view to get proper
file from related field where actual file is stored.
task-3620555
closesodoo/odoo#160070
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Steps to reproduce issue:
1. Select a boxed layout document
2. Create an invoice and add lines until the pdf version is on two pages
3. Print the pdf
4. On every page except the first one, the body of the document is cropped by the header
Explanation:
The PDF consists of three parts: the header, the footer and the body, and they are added separately. The body is delimited by the paper format and margins. Those do not depend on the size of the header and the footer.
In the boxed layout, the height of the header is bigger than the default size of the top margin of the body. Because of that, it covers a part of the body.
Suggested fix:
By removing some whitespace, the header size has been reduced to a size smaller than the default margins of the document while keeping every information readable.
opw-3768511
closesodoo/odoo#160925
X-original-commit: 08ec6a850b1959f71833d1ea7b39f50ab7ff4ed8
Signed-off-by: Bastien Fafchamps (bafa) <bafa@odoo.com>
Signed-off-by: Stroobant Paul (stpa) <stpa@odoo.com>
Before this commit, we didn't correctly detect when to prefix the
value of an url field for the href of its link.
closesodoo/odoo#160916
X-original-commit: 27458e3bdb545f550e60f1bd39addf188151c38b
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Previously, methods on python objects such as sets and strings were
implemented as functions returning a function returning the result.
While curried functions can be a great tool, they're also confusing at
first glance and in this particular case they can be easily replaced by
a simple function and the usage of Function.prototype.bind to bind it to
the correct argument. We also add a simple whitelist for pyjs functions
as a sanity check as it makes no sense to call JS functions from python
code.
With this change, we can also treat functions and methods from any
object more uniformly instead of having many return points that are
treated like special cases.
task-3762958
Part-of: odoo/odoo#139451
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes an issue regarding unwanted interaction between the
regular autocomplete option click selection and the onChange handler
from the input field hook used in the PartnerAutoCompleteCharField
component. This became an issue starting from https://github.com/odoo/odoo/pull/154203
because of the disappearance of the t-on-mousedown.prevent handler
placed on the autocomplete options list which would prevent the onChange
event from being triggered when clicking on an option. The issue would
be that the onChange handler from the input field hook would take
precedence over the option click handler of the autocomplete which would
most of the time be ignored afterwards. The solution found for This
problem is to prevent the immediate propagation of the change event
in the autocomplete handler when an option has been clicked on so that
it will never be propagated to the input field hook handler in this case.
Steps to reproduce:
- Go to contacts and open a company contact
- Type in the name field a few characters (at least 3)
- Click on any autocomplete option
Most of the time, the option will not be applied and the name won't change
closesodoo/odoo#160561
X-original-commit: aa1e5eabb67800fbf4155c9cae12b90d97bb75db
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
this commit fixes an issue introduced by https://github.com/odoo/odoo/pull/154203
which could keep the autocomplete options list opened even after a click
away when the user would "drag and drop" an option out of the list instead
of simply clicking on it. This is caused by the fact that the onInputBlur
code is directly terminated in this case (because of ignoreBlur) while
it is the only way for the autocomplete list to be closed in this case.
The solution is therefore to add an external listener on pointer down
which will always close the autocomplete list when clicking away from it.
Steps to reproduce:
- go to any autocomplete (crm salesperson for example)
- click on the input
- drag and drop a result outside of the list
- try to close the autocomplete list by clicking away
Before the fix, the autocomplete list would only close by scrolling
or clicking on the input once again.
X-original-commit: 57801ab7292e3d369615740a5f67aac9a4b9a521
Part-of: odoo/odoo#160561
On firefox and safari applying a position-sticky on an element inside
an other element with an overflow is causing a rendering issue (see
issue [1]).
This was occuring with the dropdown `.o_optional_columns_dropdown`
making it unusable as soon as the `overflow-x` triggered the horizontal
scroll in the table.
This commit works around this bug by moving the dropdown's menu out of
the actual table and attachs it to the ListRender's root element.
As this issue is specific to the Optional Fields dropdown, we
implemented it only in the ListRender (and not for all Dropdowns). Also
the issue is not present anymore in master since the Dropdown
refactoring (see PR [2]).
Note: a unique class identifying the ListRenderer has been introduced to
handle multiple List Views rendered at the same time (in the same view,
in modal...) as the the `t-portal` requires a global selector and
doesn't allow to use relative one (i.e. searching only the parents ; cf.
OWL feature request [3]).
task-3696473
opw-3682280
opw-3697814
X-original-commit: 01cd6d4d0cfa418f5a72a90742d10ee44af523a4
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1887116
[2]: https://github.com/odoo/odoo/pull/137691
[3]: https://github.com/odoo/owl/issues/1428closesodoo/odoo#160566
X-original-commit: 9a9da10bf5d1c0f96f48c9d56807512e0ad1d6ef
Related: odoo/enterprise#60116
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Steps to reproduce
==================
- Go to Field Service
- Group by "start date: week"
- Archive every record in a column until there is only one left
- Go back to the kanban view
- Click on the single record from the column
- Archive it
- Using the breadcrumbs, go back to the kanban view
=> The group order is not preserverd and the empty one is the last one
Cause of the issue
==================
Before archiving the record, we have the following data:
`{group1: [1], group2: [2, 3]}`
After archiving the record, we have `{group2: [2, 3], group1: []}`
A new group is recreated from the old one, but it is always added at the
end.
Solution
========
We can insert the old group at his previous index.
The same solution was used in previous versions
opw-3816409
closesodoo/odoo#160121
X-original-commit: 0d44e931c40fbca005b8d1864cf2d07485ed84f8
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Currently, the emoji picker uses the `onWillUnmount` hook to detect when
the popover element is closed. The code defined in this hook accesses the
component's DOM and retrieves the scroll offset of the emoji picker's
scroll view. The scroll offset will then be saved and restored the next
time the emoji picker is opened by the user.
Unfortunately, it happens that the emoji picker's scroll view is no longer
in the DOM when the popover is closed and when the callback function
passed to the `onWillUnmount` hook is called. When this happens, the
system will log an error to the console (`TypeError: this.gridRef.el
is null`) and the user will not be able to reopen the emoji picker.
To fix this, we simply check that the emoji picker's scroll view exists
before retrieving the scroll offset of the element in the `onWillUnmount`
hook. This fix will prevent the error while keeping the code simple.
Steps to reproduce the issue:
1. Click on the article emoji
2. Click out of the dropdown to close it
3. Click on the article emoji again
=> The emoji picker no longer appear.
TO BE: The emoji picker should reappear when the user clicks on the emoji.
task-3818728
closesodoo/odoo#160353
X-original-commit: 6ae04b576a3f3b74febf029383c0f6d9ca5744cf
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Julien Banken (jbn) <jbn@odoo.com>
People may have used a m2m where we don't really want a m2m relationship.
Task-3605612 (WhatsApp: Fix header / upload / reporting usage)
closesodoo/odoo#160332
X-original-commit: 910e41baf0d6ab558c53d41e511b3f10bf9860ad
Related: odoo/enterprise#59987
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit improves the UX of the color picker's hex input in two ways:
- If the user enters a hex color without the "#" symbol, it's
automatically added.
- As soon as a valid hexadecimal color is entered in the input, the
colorpicker updates, and the color is applied to the target element.
task-3747408
closesodoo/odoo#157034
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Before this commit, when the clickbot detected an error dialog, it
stopped the test and throw an error saying that an error dialog was
detected. This information is not enough to check why, and how, the
error dialog was produced.
Now, we also log the content of the error dialog as well as all the
information of the last rpc that was in error.
closesodoo/odoo#160103closesodoo/odoo#160272
X-original-commit: 4f26b324a30c5120ea60b6b42fef6cd6000d2859
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Follow-up of [1] which changed code in stable in such a way it could
break when the function was used in a way it was not intended to in
some custom code. Note that the function could also be used by giving a
string selector to it, that will not work anymore: but instead of
crashing, this commit will just make it do nothing (it is only about
adding a button loading effect anyway).
[1]: https://github.com/odoo/odoo/commit/8bd51d060a48378652ae10c57a1949c3bb7d78declosesodoo/odoo#160253
X-original-commit: d703125766d27ff33659c38fa50c2266f5f3dabb
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Odoo implements its own lazy-loading mechanism for the biggest JS
bundles that are loaded on the frontend. This mechanism allows the page
to appear to the user very fast, at the downside of having some
interactive elements (such as buttons) have no effect during the lazy
loading. In general, this is not a problem since:
- Standard links and buttons work, only those with custom effects (a
modal, a custom JS behavior, etc) have no effect.
- The full loading should not take long anyway.
- After the pages have been visited, everything should be in cache.
However, in some cases (countries with poor internet connections), the
experience can be confusing. Without lazy loading, they would have a
page that appears as a blank white page for a few seconds. With our
custom lazy loading, they get the website very fast... but some buttons
appear buggy (no effect) for a few seconds.
The long term plan is to review our lazy loading:
- Should it be less delayed than it currently is? (at the time, this was
the minimum delay that made Google give us good page scoring but it
may not be as impacting as before)
- Should some of the lazy-loaded JS should actually not be?
- Should the assets be split differently?
- Could we be able to remove some code that weighs too much?
- ...?
Meanwhile, this commit improves the behavior this way: during lazy
loading, any click on a button is now ignored but a loading effect is
displayed. Once the JS is fully loaded, the click is then re-played on
the previously clicked button, hopefully triggering its effect. In any
case, this cannot be worse than what we have before... except for:
- The reasonable risk we take merging this in stable (we considered
merging in a more recent version but it is needed for some specific
projects and many websites would benefit from this improvement).
- Any custom code that added behavior on buttons to be available during
lazy loading... will just wait for lazy loading with a loading effect
too now. This should be a good compromise as, again, that lazy loading
is cached and should not take too long anyway.
Note that this replaces the previous o_wait_lazy_js class behavior (it
has now no effect).
Overall:
- This should not impact (neither improve nor worsen) most websites that
are currently experienced from good internet connections.
- This should be a big improvement for most websites that are currently
experienced from bad internet connections.
Related to task-3770362
closesodoo/odoo#159680
X-original-commit: 6aeebe47dd552144fabd42ddb190021f1499e38a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
As a preparation for the upcoming improvements in the lazyloader, this
moves the code around a bit. This will ease the review later. This
also actually removes code that was totally useless in that moved code.
Related to task-3770362
X-original-commit: aef5a7631723f3e26425427a963c1a0dd7b6d133
Part-of: odoo/odoo#159680
In the future, we might want to make most utils available in the non
lazy JS bundle part. We are also considering moving the Bootstrap lib
and some more in there. This commit is about moving the strict minimum
to be able to improve the lazy loading behavior in stable: the DOM utils
that allow to make async handlers and create button loading effects when
we click on them.
This also means that those utils were adapted to not use jQuery and
other non available utils.
Related to task-3770362
X-original-commit: 2e922105d8714704b3db94966defc922297e2ab6
Part-of: odoo/odoo#159680
Have an x2many with several pages containing a field with a
readonly modifier (in the view, not in the field definition), e.g.
`readonly="1"` in the arch. Have an onchange that returns an
UPDATE command for a record that isn't in page 1 (so a record we
haven't read), with a value for that readonly field. Before this
commit, the value was sent in the UPDATE command, even though
readonly fields shouldn't be sent.
The difficulty here is that we can't always evaluate those readonly
expressions, as they can depend on other fields, which we didn't
read if the record is in a page we didn't browse to yet. However,
"static" expression like `"1"`, or `"context.get('something')"`
can totally be evaluated, and they should. This is what this commit
does.
Steps to reproduce the issue:
- Install mrp
- Go to Manufacturing > Products > Bill of Materials
- New:
- Product: quick create "B1"
- Components: two lines: quick create "C1" and "C2"
- Save
- Manufacturing > Operations > Manufacturing Orders
- New [in that form view, set the limit of the x2many to 1]:
- Product: "B1"
- Save
- Change quantity to 2
- Save
=> Invalid Operation
opw 3819253
closesodoo/odoo#160129
Signed-off-by: Géry Debongnie <ged@odoo.com>
In some cases, sorting a sub-view list and then deleting one of its rows can cause a traceback.
This commit corrects this situation.
Here's a way to reproduce the error:
- Install `sale_management`
- Open a quotation
- Put enough elements to have two pages
- Modify the view via debug mode and change the list view limit from "200" to "2".
- Add 4 elements
- Sort with `product_uom_qty` field
- Attempt to delete the second element (i.e. the last element on the first page)
When deleting this line, a traceback is raised
Let's say we have 4 records with the following data
Page 1 (`1 - 2 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 1 | Table | 6 |
| 2 | Lamp | 1 |
Page 2 (`3 - 4 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 3 | Chair | 4 |
| 4 | Board | 3 |
In this case we have two cached elements: the two elements visible on
the first page.
In the cache we have two complete records, by complete we mean a record
containing all the fields, for example:
```js
{
"1": {
id: "datapoint_4",
...
data: {
sequence: 10,
name: "Table",
product_uom_qty: 6,
display_type: false
...
}
},
"2": {
id: "datapoint_11",
...
data: {
sequence: 10,
name: "Lamp",
product_uom_qty: 1,
display_type: false
...
}
}
}
```
After sorting by quantity, we end up with
Page 1 (`1 - 2 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 2 | Lamp | 1 |
| 4 | Board | 3 |
Page 2 (`3 - 4 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 3 | Chair | 4 |
| 1 | Table | 6 |
It also changes at cache level, since we sorted via the `product_uom_qty`
field, we had to go and read the records on the next page (despite the
fact that they weren't displayed).
But as we only need the quantity information, we only fetch this field
from the records on the following pages.
In terms of cache, we have something like this
```js
{
"1": {
id: "datapoint_45",
...
data: {
sequence: 10,
name: "Lamp",
product_uom_qty: 1,
display_type: false
...
}
},
"3": {
id: "datapoint_16",
...
data: {
sequence: 10,
name: "Board",
product_uom_qty: 3,
display_type: false
...
}
},
"4": {
id: "datapoint_32",
...
data: {
sequence: 10,
name: "Table",
product_uom_qty: 6,
display_type: false
...
}
},
"2": { //Chair
id: "datapoint_1",
...
data: {
sequence: 10,
product_uom_qty: 4,
}
}
}
```
We therefore have one new incomplete record in the cache
The problem will occur when we try to delete a record from the first page,
if we delete `Board`, to have this
Page 1 (`1 - 2 / 3`):
| ID | Product | Quantity |
|----|---------|----------|
| 2 | Lamp | 1 |
| 3 | Chair | 4 |
Page 2 (`3 - 3 / 3`):
| ID | Product | Quantity |
|----|---------|----------|
| 1 | Table | 6 |
So we'll have to move the table that was on page 2 to page 1 (in our
case `Table`), except that when we render the list we'll have to compute
the required/readonly/invisible elements, and if we have a field that
has a readonly with the condition `not display_type` in our view, this
will cause a traceback because in the cache we only have this
```js
"4": { //Chair
id: "datapoint_32",
...
data: {
sequence: 10,
product_uom_qty: 4,
}
},
```
`display_type` is definitely not in the data because we considered this
cached record to be complete.
This commit modifies the `StaticList._applyCommands` function to create
datapoints for all records that are not **entirely** loaded via `StaticList._getResIdsToLoad`.
https://github.com/odoo/odoo/blob/00898aef4dbeb469e0cec7eaea387de2755c6426/addons/web/static/src/model/relational_model/static_list.js#L898-L912
opw-3771077
closesodoo/odoo#159264
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before that commit, the search defaults would not be filtered when the
WithSearch is started with a search model state or updated by its parent.
closesodoo/odoo#159406
X-original-commit: dac527b7baa699cef0828a9d87a4c814ff3f7f05
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Fix the property mobile display:
- Set the popup in fullscreen.
- The draggable feature is disabled.
- Replacing the move up/move down property arrows in the popup by a
back arrow so that the fullscreen popup can be closed.
- Removing the min-width on the property popover to prevent the popup
from going out of the screen.
- Edit button is now always visible as hovering on it is not possible on mobile.
Task-3635554
closesodoo/odoo#156886
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit, if a button had the attribute special="close" on the
footer of an x2many dialog, the dialog was not closed.
This occurs because the view button hook searches the dialog close
functions put in the environment by the dialog component, and in this
case is another component that initialize the hook, and the function is
not found.
Now, the view button hook will use the dialog close function put in the
environment by the dialog service.
closesodoo/odoo#159121
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Prior to this commit, `oi` icons were not adapted when RTL was defined
in frontend.
This is because RTL adaptations were defined in the backend bundle.
This commit moves the RTL adaptations to be used wherever `oi` icons can
be defined.
Steps to reproduce :
- Enter in edit mode
- Drag and drop an image gallery and a carousel snippet
- Navigate to the theme tab
- Add an RTL language (Arabic, for instance)
Bugs :
- The image gallery displays inverted chevrons
- The carousel's chevrons are correct, but clicking on "previous"
displays the next picture, and vice versa.
Also, some icons a bit everywhere in the apps were not rotated either.
For instance, the back button a forum post to go back to the forum.
Note that task-3714335 will replace FA icons by BS icons, and will
triple check Odoo icons at the same time, to ensure all Odoo icons are
available in the frontend and correctly imported. For instance,
`oi-spin` and `oi-pulse` could make sense in the frontend too.
opw-3747848
task-3794966
closesodoo/odoo#159150
X-original-commit: fc105130551cf9897c7a0a78baf4458e6d5e6fd8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Prior to this commit, the "hatched" event style in Planning wasn't
displayed in Day and Week views.
This commit adjusts the css selector to fix this issue.
task-3617329
Part of task-3575827
closesodoo/odoo#154964
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Prior to this commit, some of the main styles related to event elements
in calendars were set in the Calendar module.
This created layout issues when we installed independent modules without
installing the Calendar module (eg. `planning` or `hr_payroll`).
To fix that, this commit moves the necessary styles into `web`.
task-3617329
Part of task-3575827
Part-of: odoo/odoo#154964
This commit introduces an update to the Font Awesome library,
specifically replacing the X/Twitter icon with its new design. It also
involves adjustments to a few images and SVG files to incorporate the
updated X/Twitter logo.
Technical note: It updates an existing file, originally modified for the
addition of the TikTok icon, which was not available in Font Awesome 4.
task-3463530
closesodoo/odoo#158586
X-original-commit: 34cba04a452f2da21f3418d6fc48a484da8ecd27
Related: odoo/enterprise#59147
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
- BooleanFavouriteField wasn't translated as the component was using
an untranslated variable instead of relying on the translation of
the template.
Some other translation fixing:
- ID Azienda is very generic, the correct name is Numero REA:
See: https://www.registroimprese.it/codice-fiscale-p.iva-rea
- No one calls a mobile phone "Dispositivo mobile", we already
translate it as the more common "Cellulare" even in the same file
task-3263708
closesodoo/odoo#157949
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Steps to reproduce
==================
In 17:
- Install hr_holidays,project
- Switch the language to dutch
- Go to project > three dots > Projectupdates
We can see `x/y Genomen`, it should be `x/y Taken`
Cause of the issue
==================
The original term is Tasks.
When loading the views, python translates them and changes Tasks to Taken.
Owl then translates the template and transforms Taken to Genomen.
Solution
========
Since the views are already translated, we don't need to translate them with owl.
We can simply set the attribute t-translation to off on the view root node.
opw-3787336
closesodoo/odoo#158627
X-original-commit: 454760e12145f8987e443d7776a614a5eb441feb
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Open the code editor (wrapper around aceEditor) with an initial value -- in Odoo, that is any instance of the code editor.
Press Ctrl+Z.
Before this commit, the value disappears -- is undone -- even though no real change happened.
This was because we used editor.setValue, instead of editor.session.setValue. The latter resetting the undo history.
This behavior is "documented" [here: Common Operations](https://ace.c9.io/#nav=howto) with:
```js
//Set and get content:
editor.setValue("the new text here");
editor.setValue("text2", -1); // set value and move cursor to the start of the text
editor.session.setValue("the new text here"); // set value and reset undo history
editor.getValue(); // or session.getValue
```
After this commit, the initial value is not undoable.
opw-3793546
closesodoo/odoo#158548
X-original-commit: b33086599383a4c0ab43126598a63e8721f682fc
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Steps to reproduce the bug:
- Install the "Blogs" app and go to the "/blog" page.
- Click on "Edit" to enter edit mode.
- Go to the "Theme" tab.
- Select the 4th color from the theme colors and choose "black".
- Save the page to exit edit mode.
- Perform a search in the search bar input that yields no results, for
example: "zzz".
- Bug: The message "No results found. Please try another search." is not
visible because it is displayed in white on the white background of the
dropdown.
A previous commit [1] had already addressed the issue for the "Search"
snippet that can be dropped into a page, but this fix wasn't sufficient
to solve the problem everywhere. Indeed, the text-muted in a dropdown
should be adjusted in all cases and not just for snippets; it's a
Bootstrap issue. The text-muted color should be adapted to the
background color of the dropdown.
[1]: https://github.com/odoo/odoo/commit/f9bf40cb53cf487c8736c1f565c2f0d3834acd5e
task-3662985
closesodoo/odoo#158203
X-original-commit: 46fcb3712f0ba68144b03ed23f52157d4dfc789a
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
This commit simply removes the table-responsive class from the pivot
view in desktop mode so that its eventual horizontal scrollbar will
remain inside the viewport instead of being positioned at the very
bottom of the page. Also hides the scrollbar in sample data mode so that
the user cannot scroll horizontally in this case which introduces weird
display.
closesodoo/odoo#158083
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Have a list view with multiple groupbys and a lot of records to
have pagers displayed. Open a group (first level). The pager of the
group uses the number of records instead of number of (inner)
groups as total.
This commit fixes the issue. The pager now correctly allows to
navigate through inner groups.
closesodoo/odoo#157995
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Steps to reproduce:
- Install planning app.
- Go to planning app, and convert the view to List.
- Group by Resource -for example-.
- Notice how the allocated time values are mis-aligned with the header label.
Investigation:
- in the planning tree view, notice the property `open_form_view` set to `True` https://github.com/odoo/enterprise/blob/418ea2114c7d935865dc52e5fd5a30d626987190/planning/views/planning_views.xml#L8
- In the `getGroupNameCellColSpan` method:
- the `firstAggregateIndex` is `1` belonging to the `allocated_hours` (Allocated Time)column which set the `colspan = firstAggregateIndex = 1`
- as `this.hasSelectors` is `true`, `colspan = colspan+1 = 2` (which is the correct value)
- but now as the `open_form_view` was set to `True`, the `this.props.onOpenFormView` exists and so the `colspan = colspan+1 = 3` which makes the value be misaligned to the right by one column.
The proposed fix:
- As the `open_form_view` option add a View button to the end of the row, it makes sense to do the check with the `lastAggregateIndex` inside `getGroupPagerCellColspan` method.
- In our case:
- the `lastAggregateIndex` is `1` belonging also to the `allocated_hours` which set the `colspan = this.state.columns.length - lastAggregateIndex - 1 = 3 - 1 - 1 = 1`
- as we don't display optional fields this check fails https://github.com/odoo/odoo/blob/5af3cfc2b9ce648ae4aff69150266e4ad519050d/addons/web/static/src/views/list/list_renderer.js#L1025-L1027 and the `colspan = 1`
- Now we check the `this.props.onOpenFormView` condition which set `colspan = colspan+1 = 2` which is correct.
- But what if we wanted to show the optional field `allocated_percentage` would this fix still work? Yes!
- the `lastAggregateIndex` is `2` belonging to the `allocated_percentage` which set the `colspan = this.state.columns.length - lastAggregateIndex - 1 = 3 - 2 - 1 = 0`
- as we do display an optional fields= this check works https://github.com/odoo/odoo/blob/5af3cfc2b9ce648ae4aff69150266e4ad519050d/addons/web/static/src/views/list/list_renderer.js#L1025-L1027 and the `colspan = colspan+1 = 2`
- Now we check the `this.props.onOpenFormView` condition which set `colspan = colspan+1 = 3` which is correct.
- One last case, what if we have no aggregates
- both firstAggregateIndex` = `lastAggregateIndex` = -1
- we go into the else clause inside `getGroupPagerCellColspan`, making the `colspan = this.state.columns.length > 1 ? DEFAULT_GROUP_PAGER_COLSPAN : 0 = True ? DEFAULT_GROUP_PAGER_COLSPAN : 0 = DEFAULT_GROUP_PAGER_COLSPAN = 1
- if the `open_form_view` was `True`, the colspan becomes `colspan = colspan+1 = 2`.
opw-3764616
closesodoo/odoo#156647
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Mohammed Basioni