An error is raised when trying to render date picker with the Mongolian
locale
Steps to reproduce:
1. Install Sales
2. Install and switch to Mongolian language
3. Open Sales and create a new quotation
4. An error is raised: `locale() locale mn-MN is not loaded from moment
locales!`
Solution:
Add the Mongolian locale. It is not present in the version of Moment.js
we use (2.19.3) so we get it from a newer version (2.29.2)
Problem:
The Mongolian locale was unintentionally removed in this PR
https://github.com/odoo/odoo/pull/111986 so we add it back
opw-3188184
closesodoo/odoo#113983
X-original-commit: 055c13af01c445c5e105d63ea3cd98e3ad2915a8
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Steps to reproduce:
- go to any invoice
- click on Preview
- the lines after the invoice number are in separate rows
Bug:
here is bootstrap 4 implementation of `.col-3`
```
.col-3 {
-ms-flex: 0 0 25%;
flex: 0 0 25%;
max-width: 25%;
}
```
and here is bootstrap 5 implementation:
```
.col-3 {
flex: 0 0 auto;
width: 25%;
}
```
we can notice that bootstrap 5 changed the way that the width is
applied to the flex object.
now in https://github.com/odoo/odoo/pull/51715
the width property is overridden for the class `.col-auto` which is
not useful in bootstrap 5 anymore anyway. This creates a problem with
elements that are both `col-auto` and `col-3` as the override from
`col-auto` misses with the new `col-3` implementation
Fix:
remove the override of `width`
OPW-3171131
closesodoo/odoo#113938
X-original-commit: b9d19643cbdfb58531f5bd7020f26c905df9c5b8
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>
Steps to reproduce:
1. Install Dashboard & Inventory (enable multi-locations)
2. Make inventory adjustments to have a location with negative stock
3. Go to the dashboard app & click on “Inventory On Hands”.
4. An error shows up: TypeError: chart.dataSource.getData() is null
Issue:
If one of the locations have negative stock, the pie chart will not be
displayed and it will throw many errors, It has the same behavior If
every location have negative stock.
Solution:
Discussed with the PO, when we have positive and negative values, we
want to ignore the negative values and display the pie chart with the
positive values only. For this case, we modified `_prepareData` and
`_isValidData` methods so they check and filter the positive values in
case we have any. For the other case when we don't have any data, that
can be displayed in the pie chart, we added a way to don't get any error
and only display a blank pie chart.
opw-3103967
closesodoo/odoo#113794
X-original-commit: 3fdfc357097fc77cb998e8a6794efe1f9ffa53bb
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
**Before this commit**
- The optional "class" attribute set on the root node of a view arch
is ignored, except for the kanban view which has a custom
way of using it.
- The optional "js_class" attribute set on the root node of a view arch
does not have any impact on the class names passed to its controller.
**After this commit**
The content of the optional attribute "class" set on the root node of an
arch like in
<list class="o_custom_class">
...
</list>
as well as an additionnal class derived [1] from the value of the
"js_class" attribute set on the root node of an arch like in
<list js_class="extended_list">
...
</list>
will both be found in the prop "className" of any view controller.
[1] a js_class value of "xyz" yields to the class "o_xyz_view"
**Note on this commit**
The kanban view was already appending the root node class attribute
to its renderer element. This is no longer the case and some styling
rules has been adapted.
closesodoo/odoo#113014
Related: odoo/enterprise#37265
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Steps to reproduce the bug (in 16.0 and above only):
- Go in the backend
- Focus the searchbar
- Type something and use the arrow to navigate the search dropdown
=> You cannot see what you are highlighting anymore
This occurs since [1] (its forward-ported version) which removed rules
that were targeting the frontend dropdowns by mistake while they were
indicated as wanting to target OWL dropdowns only. It appears that those
rules were actually used by chance in 16.0: to style the searchbar which
is not using OWL dropdowns and whose specific 15.0 styles were removed,
fallbacking on those erroneous rules. On top of that, the wanted style
here concerns a rule about the `focus` class... which is actually not
part of Bootstrap 5 anymore but that our old searchbar still uses.
There is a high chance that the problem is only confined to the 16.0
searchbar and not anything else. But as a precaution this commit fixes
the issue by restoring all the rules that were removed (well, rather
moved to be more specific to OWL dropdowns) but inside a backend file
only. The legacy/dropdown.scss file seemed very suitable for this
purpose. Obviously, those rules should be removed as soon as possible
once it will be judged ok in master after a searchbar adaptation.
[1]: https://github.com/odoo/odoo/commit/e24bff699190bc511b357c200f4494a177be5b77closesodoo/odoo#113944
X-original-commit: 77537678d6b6f3533eb0c9d9d37d8fe679ef9580
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit addresses a bug in jQuery Draggable where the 'stop' event
did not trigger a 'mouseup' event outside of the dragged element window
if it was inside an iframe. This issue only occurred in Chrome (Firefox
was not affected).
In mass_mailing, this issue occurred in the email editor when the mouse
was released in the area above the editor. This error also affected the
Sign module, where elements can be dropped into a PDF, and where the
'stop' event of the dragging did not trigger outside of the iframe.
Steps to reproduce the bug in mass_mailing:
- Open the Email Marketing app.
- Create a new mailing.
- Choose the second available email template.
- Click and hold the "drag and drop" button of the first snippet (Your
logo) to start dragging it.
- While dragging the snippet, move the mouse outside of the email editor
iframe.
- Release the mouse button.
- Bug: the drop zones are still present in the DOM, and it is possible
to save the template with them.
opw-3164969
closesodoo/odoo#113893
X-original-commit: f083e664bfe5b6b6abeec7aeee242771a21d8710
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the new drag & drop tour helpers could only be used
on the white-listed "o_record_draggable" class name. This meant that
only the new kanbans could use the "drag_and_drop_native" tour helper.
This commit allows any element using the "o_draggable" class name to use
that helper, and renames occurences of "o_record_draggable" to
"o_draggable".
Part-of: odoo/odoo#112756
The aim of this commit is to make more warning and error dialogs behave
like the "oh snap" dialog of form views.
task-id=3126594
closesodoo/odoo#112276
Related: odoo/enterprise#37593
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Bug
===
- Create a boolean property
- Close the popover definition
- Re-open the definition
> The boolean value has been change because it received the click event.
Task-3172106
closesodoo/odoo#113448
X-original-commit: 677aac62b0efb4b16afd0348c3b3b2c9b4ef65b0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Bug
===
Currently, the default value of a property is only used when we create
new record. But it can also be used when we create a new property.
Note that the default value is written on the property ONLY if the
property just have been created, to not update existing value on
other records (the goal is to have a behavior similar to normal fields).
Task-3172106
X-original-commit: e3099ae584cef74434fdb51f7fee2ae6250f18ca
Part-of: odoo/odoo#113448
To reproduce
============
- Modify the task list view like so: <field name="partner_id" attrs="{'invisible': [('partner_id','=',8)]"/>
- the field value will be invisible if the customer is "Joel Willis" (with standard demo data)
- However the popover for the value is still there
Problem
=======
the value of tooltip is always set even if the value is invisible
Solution
========
set value of the tooltip based on condition about field visibility
opw-3177191
closesodoo/odoo#113785
X-original-commit: 5bee2125528ee1d20779112093e098eaa64cf5c0
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: hr_skills, project
This commit improves the behavior of the ProgressBar field. Before 16.0,
views had a readonly mode, and to avoid having the inputs always visible,
the user had to click on the progressbar to enter into an edition mode.
Nowadays, this is redundant, and make it difficult to guess that the field
is editable. With this commit, the input is always visible, which also
allow to improve the template and the code of the component. The commit
delete unused props/options that were no longer used by the widget.
This commit also remove a legacy scss file that was still present, and the
style of the component has been moved to its own file. Some dead classnames
have been dropped, or replaced by bootstrap classes, reducing the size of
the scss file.
Tests had to be adapted, because some assertions were irrelevant, or were
triggering the click to enter edition mode.
task #3178958closesodoo/odoo#113002
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The external button of the Many2one field has been changed with the
"always edit" feature of the form view, s.t. it displays by default
another icon (a right arrow) and when clicked, opens the related
record in another plain screen action instead of a FormViewDialog.
However, this doesn't work for Many2One fields that are already in
dialogs, because
1) if it's an action dialog (target="new"), that dialog will be
closed when opening the related record and the user loses its
working context
2) if it's another type of dialog (e.g. FormViewDialog), the
related record opens in the background and the dialog remains
open, which is obviously a bad UX experiment. This had been
locally fixes at some places [2].
This commit fixes the issue by automatically opening the related
record in a FormViewDialog if the Many2One is itself already in a
dialog.
This commit also fixes an issue with the scenario where the related
record opens in a dialog: if there were changes done in the main
record, those changes where lost when the user clicked on "Save"
in the dialog of the related record. We now only reload the
display_name of the related record, and apply it to the model.
[2] https://github.com/odoo/enterprise/commit/ba0e95fe42696dcf44b8feddeb302f04876fcbdc
Task 3191319
closesodoo/odoo#112959
Related: odoo/enterprise#37213
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Prior to this commit, there were functional issues for the floating toolbar
and design issues for the Powerbox in the web editor.
This commit fixes those issues, like alignement for the icons in the list
of the commandbar, box shadows, and the responsiveness of the floating
toolbar on mobile.
In commit [1], the toolbar dropdown had the display static added, but it
causes problems to the responsiveness.
This commit put the display back to dynamic on the dropdown and so, fixes
the dropdown not showing on mobile because of the overflow-x on auto.
The dynamic state also allows the dropdown to change direction (dropdown
to dropup) when there's not enough space for the content of the dropdown.
Would be nice to have : use display state on the all the editor
toolbars (frontend and backend) to modify the layout of the toolbar for
mobile, for a better behavior and design (ex: the different lists in a
dropdown).
For now, it's just a horizontal scroll.
[1]: 459d4e27a8
task-3087826
Part-of: odoo/odoo#110161
From a practical point of view, it seems better to also add the
dialog service in the service registry when calling
setupControlPanelServiceRegistry.
closesodoo/odoo#113610
Related: odoo/enterprise#37510
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Reproduction:
1. Install Sales
2. Go to the quotations
3. Drag the column “name” and change the size
4. Check any sale order in checkbox
5. The column size is reset to default
Reason: the keepColumnWidths parameter isn’t set to True after changing
the size. This happens to all the list views
Fix: we freeze the list after resizing the columns. Remove the extra
keepColumnWidths setting in reordering since it's already set to true
after resizing. Also added tests to check the column size is kept after
toggling the checkboxes
A similar fix is here: https://github.com/odoo/odoo/pull/10902
opw-3113822
closesodoo/odoo#113607
X-original-commit: 30a346a90b633dd73fa823de2cdaf37a0e52c526
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>
This commit is part of the preliminary work to rewrite the form,
list and kanban model. We want this new Model to only be aware of
field related information it needs (whereas in its current
implementation, the model stores all the information extracted
from the field node in the arch). This would allow to properly
manage multiple occurrences of the same field in views, that is,
each occurrence would be represented by a field component (if
visible of course), and that field component would use the field
information of the arch node it represents. To this end, we want
fields from not using anymore information stored in activeFields
in the record datapoint. Instead, we now call extractProps with
the whole fieldInfo (the information extracted from the arch), s.t.
each field can generate the props it needs from those information
(e.g. sub views for x2manys).
This commit doesn't remove the use of record.activeFields in
concrete fields (this will come later), but reworks the fieldInfo
object generated by parseFieldNode, and provide it to the calls of
extractProps. In fieldInfo, the `options` key is no longer inside
`attrs`, as it is now top-level, alongside several other generic
keys that have been processed (like on_change, modifiers...). For
that reason, a lot of extractProps definitions had to be adapted.
Part of task 3179751
closesodoo/odoo#113092
Related: odoo/enterprise#37266
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
The form view currently reads its data as follows:
1) read the main record, which returns [id1, id2...] for x2manys
and [id, display_name] for many2ones.
2a) read x2manys records, with the context set on the x2many field
node, which returns records like 1)
2b) call name_get for many2ones with option "always_reload" set to
true, with the context set on the many2one field node
3) same as 2), but for records returned by 2a)
The context set on a field node is a string, and needs to be
evaluated (some placeholder values need to be replaced by actual
values), e.g. "{'partner': partner_id}" -> { partner: 4 }.
For 2a and 2b, the context sent is evaluated with the main record
as eval context. For 3, there an additional key "parent" in the
eval context which contains the values of the parent record.
The rationale of this commit is that those data related keys in the
eval context are useless for read-like rpcs.
In the future, the data of the form view will be fetched with a
single rpc, returning the main record and its related records, with
all the values required by the UI. To achieve that, we must ensure
that sub records are never read with a dynamic context depending
on the parent record.
This commit thus directly imposes the limitation, by removing from
the eval context the record related data when it is used to evaluate
the context to send to read-like rpcs.
Part of tasks 3171453 and 3179751
closesodoo/odoo#113527
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Bug
===
If the Reference field is in a list view, and has a default value, an
error is raised if we create a new record without editing the reference
value. This is because the ORM return a string "model,id" in the
onchange method and this value is wrongly parsed in that case.
Task-2234179
closesodoo/odoo#113392
X-original-commit: b1a35d1b95612bc449b68ed38749d8b3755287ed
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
This commit revamps the UX of the StateSelection field widget. Now, instead
of filtering the options by removing the current selected value, the field
displays the entire list in the dropdown, and the selected item has a
checkmark to indicate its status.
This allows us to remove the tooltip, since its presence was not useful
anymore, and was unintuitive to use. This changes required to adapt some
tests asserting its presence, as well as the number of items shown in the
dropdown menu.
task #3177182closesodoo/odoo#113203
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
As with fieldsToFetch in commit 25bf5a3fabfa9da5367e82d1c5713425c77bc373,
we will convert fieldDependencies into an array of fields.
We did it because it's easier to use and more natural to has an array.
Part of task 3179751
closesodoo/odoo#113482
Related: odoo/enterprise#37449
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When using the ControlPanel's bottom-right slot in another component, if
`viewSwitcherEntries` wasn't defined in `env.config` it would raise a
traceback, as the template would try to check an `undefined`'s length.
Removed the workaround that added an empty `viewSwitcherEntries` in the
forecast report and the bom overview report since it's no longer
necessary.
closesodoo/odoo#112415
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit aims to simplify the extractProps api by removing "field".
The Field will need to go into
this.props.record.fields[this.props.fieldname] to access the information
previously stored in the "field" parameter.
Part of Task: 3179751
closesodoo/odoo#113214
Related: odoo/enterprise#37469
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
It may happen that the response of a json rpc isn't json parsable,
for instance when the connection pool is full (PoolError). In this
case, the response is an internal server error (500) in html.
Trying to json parse it throws an error. Commit [1], backported in
15.0 by [2] aimed at throwing a more readable and meaningful error
when this happened.
However, this error occurs frequently on the saas for the moment
(see task 3193565), and users constantly report those HTTPError
tracebacks introduced by [1].
In 14.0, we were using jQuery ajax, and the legacy rpc and error
system, where those internal server errors were handled as
connection lost errors (error code -32098). So basically, a
notification was briefly displayed instead of an error dialog.
This commit restores the previous behavior in the new rpc service.
[1] https://github.com/odoo/odoo/commit/5c4a54022b320
[2] https://github.com/odoo/odoo/commit/a01122543a79cclosesodoo/odoo#113434
X-original-commit: 278686d8540a194f0af51e1a0b68b26b13eaf544
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Bug
===
The number property should be formatted like a normal integer / float field,
in the form view (show 2 decimal for the float, thousands separators, etc,
even when editing).
Task-3162402
closesodoo/odoo#113449
X-original-commit: 99c251820dcf4791625fabd3fcd61db84280d408
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The delay of tooltips opened with the tooltip service can be given
in xml, with attribute data-tooltip-delay. If not specified, there
is a fallback in the service to 400ms. Before this commit, the
fallback wasn't correctly applied, because we parsed the xml delay
into an integer, which was NaN when the delay wasn't specified,
and as NaN isn't undefined, the fallback wasn't applied. As a
consequence, we opened the tooltip in a setTimeout with NaN as
delay, and it thus opened directly.
closesodoo/odoo#113425
X-original-commit: 553b2775a4b31c75d1d246816b749e4521e25726
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Since [1] the highlight of the focused element in the search
auto-complete has disappeared. This makes the keyboard navigation barely
usable.
This commit restrains the owl styling of dropdowns to the Owl Dropdown
components. This restores the highlight of the focused element on all
website dropdowns (e.g. also the logged-in user one and the "+" to
display more menu entries).
[1] did move the bootstrap's dropdown specific style customizations to
`webclient.scss`.
Steps to reproduce:
- Drop a "Search" snippet.
- Save.
- Type "a" in the search box.
- Navigate the suggestions with the keyboard up and down arrows.
=> Currently focused element looked the same as the other ones.
[1]: https://github.com/odoo/odoo/commit/84715436d87bb05b421bc9ccaacda67d07571690
task-3148871
closesodoo/odoo#113409
X-original-commit: e21ab2cb4904da9efeb7710a8bf8f6efec67821b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- In debug mode
- Go to a cancelled invoice in Accounting
- Click to the "Reset to draft" button in a fast timing (before the
`PopoverContainer` is mounted).
When hovering an element, a tooltip appears. If the target element
disappears before the `onMounted` of the `PopoverContainer`, then the
popover causes a crash because the target element does not exists
anymore.
This fix makes the `tooltip_service` verify that the target still exists
before adding the popover.
closesodoo/odoo#113406
X-original-commit: 589acab37a4c1b68876386b752a91c3412dc4569
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Dardenne Florent (dafl) <dafl@odoo.com>
This commit, is part of a series of commits that aim to simplifie
the concrete fields API.
In this commit we will remove type prop from concrete fields. Now each
field could directly use this.props.record.fields[this.props.name].type
if they need to know the type of field.
task-id 3179751
closesodoo/odoo#112792
Related: odoo/enterprise#37118
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit, is part of a series of commits that aim to simplifie
the concrete fields API.
In this commit we will remove update prop from concrete fields. Now each
field will directly use this.props.record.update to make changes, and
handle the save in fields that need to (e.g. priority). As a consequence
of this, the record props need to be mandatory.
task-id 3179751
Part-of: odoo/odoo#112792
To reproduce (V16):
1. Force modify a view with an unexisting field
For example `res.users.tree` with:
`<field name="unexisting_field"/>`
( note that odoo won't allow to do so,
you will have to do it in raw PSQL * )
2. Open Settings > User & Companies > Users
=> JS traceback error:
```js
UncaughtPromiseError > TypeError
Uncaught Promise > Cannot read properties of undefined (reading 'string')
TypeError: Cannot read properties of undefined (reading 'string')
at http://localhost:8069/web/assets/debug/web.assets_backend.js:67523:84 (/web/static/src/legacy/legacy_load_views.js:67)
...
```
* : In practice, it happens to Odoo customers after
incorrect installations/removal of apps
After this commit:
The JS traceback is much clearer regarding the error:
```js
UncaughtPromiseError
Uncaught Promise > Missing field string information for the field 'unexisting_field' from the 'res.users' model
```
OPW-3071843
closesodoo/odoo#113345
X-original-commit: 33f82a60cd3bb64e67d939795b774cd332ab0508
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Clicking on draw in the signature dialog should clear whatever is already drawn
on the canvas.
task-3040855
closesodoo/odoo#113248
X-original-commit: f1c3d83f5b4f6ef0e2b5db2b7aa55344c91454f0
Related: odoo/enterprise#37338
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
By following these steps:
- Drop a block table of content on a page
- Disable the visibility of the block in desktop view
=> A traceback is displayed.
This is because for scrollspy to work properly, the elements that it
handles must be visible (no display: none). Unfortunately, we put a
display none when the block must be invisible for a certain device and
the width of the screen is the one of this device. Since it is quite
complex to prevent all the cases where the block could become invisible,
we patch the scrollspy component of bootstrap so that it has a similar
behavior as in version 4.X. (not cause an error if the navigation
element is no longer in the DOM or is no longer visible).
The error is only visible since [the migration from bootstrap 4 to
bootstrap 5] because to add the class, bootstrap 4 did it with the
JQuery addClass() function which does not cause an error if the element
on which it is called does not exist. Now, bootstrap 5 does the same
thing in pure JS with classList.add() on elements that meet the
requirements (visible) which causes an error if the element on which it
is called is not defined (this is the case before this commit because
the TOC was not visible).
[the migration from bootstrap 4 to bootstrap 5]: https://github.com/odoo/odoo/commit/c48f57ea2538ad51e00ac27d58f8e191781444f3
task-3116227
opw-3135927
X-original-commit: f2b86dda77133ed9c4f02394693e771758d18bad
Part-of: odoo/odoo#113184
Before this commit, the widget's description was stored on the
component and this component was then registered.
Now, an object describing the widget is used on registration the same way
as it is done for views since b828cfc.
This split the component's description (props, template, ...) of
the widget's description ( component, extractProps, ...) and makes
it clearer.
We did the same thing for fields in 9f4622492c
Part of task: 3179751
closesodoo/odoo#112962
Related: odoo/enterprise#37215
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Problem:
In a list view, editing a record and then clicking an action button
on that record does not save the edited field values.
Expected behaviour:
Changes applied to the record must be saved before executing the button
action.
Solution:
The 46bd694c8a67f25470a911c1eb04e0bf2e17a5f7 commit in master solves
this problem (TaskID-3132960). We will backport it and add a test for
our use case.
How to reproduce:
- Go to a list view with one text field and one button action per record
- Edit the text field
- Click on the button action
Before this commit:
The value of the text field has been restored. We lost our modification.
After this commit:
The record has been saved.
closesodoo/odoo#113120
Taskid: 3168517
X-original-commit: 5f5040730707e62885757aa6a39345a46cda9b48
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
In the sample server, we generate random float values between 0
and 100. The faulty assertion expected the value to be strictly
less than 100, however, it sometimes failed: when Math.random()
generated a value >= 0.99995, it produced 100 as float value.
Runbot error 15206
closesodoo/odoo#113181
X-original-commit: 4abfb9553559080d53bc5a8ba521eec000c56a26
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
The sample server did not create a __range value when grouping by 'date'
This resulted in a traceback as it is expected to at least be false.
This commit computes it properly.
task-3098681
closesodoo/odoo#113163
X-original-commit: cf074f1dc01da39e75aa30e4ac21eafa29d528d9
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The previous commit has as a side effect to change the value returned by
the create method of the orm service. Here we adapt the code that uses it
and make the test pass.
Part-of: odoo/odoo#111965
Before this commit, the "create" function of the ORM service didn't
allow to pass multiple records. As a consequence, it was needed to
create records one by one calling the ORM create multiple times or call
create via the method call.
This commit allows to use the create method to create several records at
once.
Part-of: odoo/odoo#111965
For performance reasons, we added a feature that allows to limit
the search_count done when fetching records in list and kanban
views, to display on the right side of the pager [1][2]. However,
the page previous case wasn't correctly handled when we had a
limited count. When doing page, we need to know the total number of
records to compute the offset. Before this commit, we went to the
last page, which wasn't really the last page (because we sent a
wrong offset), which can be misleading for users. With the commit,
we force a search_count when doing page previous on the first page.
[1] 6acfad2651
[2] 699215ec9a71b8c9b6a53fe96e924a400d216729
Task 3162026
closesodoo/odoo#113134
X-original-commit: cefff0dcd5b3b1120b215e6af28d678c7ec34d52
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Since commit [1], we can have list or kanban view with same limit
and count_limit (to save a costly search_count), i.e. have a pager
like "1-80/80+". Before this commit, when reaching the count limit
on page next, we performed the search_count. This was fine before
as the count_limit was hardcoded to 10k, so you basically never did
page next until the limit. However, it's a issue now that the
count_limit can be specified, as in the above example, we don't
want to slow down the loading of the second page records because of
the search_count.
With this commit, we slightly increase the count limit when we
reach it, so for instance doing next when the pager shows 1-80/80+
fetches the records with args offset=80, limit=80, count_limit=160
and the pager then shows 81-160/160+. If the total number of records
is reached, we know the count and display it, for instance, after
another pager next: 161-190/190.
The same logic applies when the pager is manually edited, e.g. when
you write 1-150 in a pager showing 1-80/80+, you'll get 1-150/150+
if there are more than 150 records.
[1] 699215ec9a71b8c9b6a53fe96e924a400d216729
Task 3162026
X-original-commit: d39559274e6de6cdba6972775f9bda8bd2de8fa6
Part-of: odoo/odoo#113134
This commit adapts the translation tests for non-English Numbering
system to rely on the month's numbers instead of names, as the goal of
those tests is to verify that the correct Numbering System has been
applied instead of this specific datetime format.
This is due to Chrome 110+ modifying/fixing month's name translation in
the Intl API, and more specifically the bengalese's test breaking since
this update.
Note: Firefox and Webkit browsers applied similar fixes in their recent
versions.
closesodoo/odoo#113121
X-original-commit: 42b679b9b71bf2b58e0f785c21ef002de6f3ca32
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This commit fixes the appearance of the select element in dark mode.
Since the background color is set with transparency, a white background
was set on the options dropdown by desktop browsers, which made the
text difficult to read. By adding a color to the options, we can fix
the appearance without the need to put a color without transparency
on the select elements.
task #3147138closesodoo/odoo#113106
X-original-commit: 194a6506a933665cc47ca96d976a0aa304eb864c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
For the Knowledge module, we would like to allow the user to fully
customize a graph view and let the user insert the graph they see in an
article. When loading the graph view from an article, the system can not
currently restore the following settings:
- For the bar chart and the line chart: The system will not able to
restore the "sorting order" and the "stack option" set by the user.
- For the line chart: The system will not be able to restore the
"cumulative option" set by the user.
This commit will ensure that these options can be specified from the
context of the view. The context configuration will have a higher
precedence than the configuration stored in the metadata of the model.
When the user will open an article containing a graph view, the graph
view will automatically load the options that have been set by the user
when inserting the view. The user can thus create their own dashboards
by customizing the graphs and inserting them in an article.
task-3056268
closesodoo/odoo#112600
X-original-commit: 458bf22c7e275b7893505bb39c16073a9f63b9ca
Related: odoo/enterprise#37046
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, there are a few mistakes in the standard view props definition:
1. To check the type of each element in an array, the prop definition has
to include an "element" entry. In the standard view props definition, we
included an "elements" entry which will completely be ignored by the
schema validator of owl in debug mode.
2. The "element" entry is only used when the `type` entry of the prop
definition is `Array`. We will therefore simplify the property definition
and remove the "element" entry for the props that are not arrays.
3. The `orderBy` definition of the standard view props mismatch with the
`orderBy` definition of the `WithSearch` component and the search model.
This commit will fix that inconsistency for all those components and
update the tests and the JSDoc accordingly. It will then be possible to
set the `orderBy` value from the props of the `View` component without
getting an error in debug mode.
task-3056268
X-original-commit: 4911e6cd366eadc60923940364274b30372e1584
Part-of: odoo/odoo#112600
For performance reasons, the grouped kanban view automatically
folds groups when they are to many, s.t. at most 10 groups are
open by default (because for each one of them, we must perform
a web_search_read rpc to fetch their records) [1].
However, during the convertion to owl, we broke half of this logic.
The qunit test introduced by [1] simulates a read_group that only
sets the __fold key to true in folded groups, but doesn't define it
in other groups. This test passed. But the logic in the model
didn't correctly handle the case where the __fold key was given for
all groups, even when its value was set to false. This happens for
instance in the project task kanban view.
This commit fixes the issue.
[1] https://github.com/odoo/odoo/commit/fa4c650b01dc184041c61d9d52299b0b740a83bd
Task 3191948
closesodoo/odoo#113061
X-original-commit: dd71662cc994fb8716cae63944b4df9d4201dcdc
Signed-off-by: Georis François (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in a form dialog view, clicking on an action button
in the header does not save the record being edited. The record is reset
in case a new record is created.
How to reproduce:
- Go to a form view with a non-editable m2m
- Click on add a line
- Click on Create
- Edit the new record
- Click on an action button (the arch must contain a <button> in the <header>)
Before this commit:
The record is reset. All encoded data is lost.
After this commit:
The record is created in db and we keep all the encoded data.
closesodoo/odoo#113063
Taskid: 3165983
X-original-commit: 52fdfe0b26941718bf1532e517a51de38cacfdbc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Positive Lookbehind regex syntax is currently not supported yet by
Webkit, and thus Safari (both on macOS and iOS) resulting into a crash
as the syntax is not recognized.
This issue affects both frontend and backend.
This commit fixes it by reimplementing the feature without using this
syntax.
closesodoo/odoo#112985
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
This update conatins the following commit:
- [IMP] devtools: provide access to Fiber and RootFiber
- [FIX] props validation: do not subscribe to props keys
- [FIX] reactivity: only show key in subscription if observed by callback
- [FIX] components: stop rendering stale t-component when delayed
More details at: https://github.com/odoo/owl/releases/tag/v2.0.6closesodoo/odoo#113041
X-original-commit: fd67ca5d2aaa9683ac1e4667e76fc4230d5d62c6
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
MerlinGuillaume