This commit is to replace all uses of activeFields in Field components
by passing fieldInfos to extractProps. We will therefore retrieve the
node-dependent information in the extractProps function.
Why?
This ensures that the info used is that of the correct node. Because the
activeFields function contains the information from the last node that
referred to the same field.
Example:
<tree>
<field name="a"/>
<field name="a" context='{'b':"yop"}'/>
</tree>
For the first field:
FieldInfo.context = {}
activeField.context = {'b':"yop"}
For the second field:
FieldInfo.context = {'b':"yop"}
activeField.context = {'b':"yop"}
Part of task: 3179751
closesodoo/odoo#113874
Related: odoo/enterprise#37621
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
We take advantage of the change of api made in commit
145540921f to rename FieldsToFetch to
relatedFields.These two commits are in the same version of odoo (16.2).
FieldsToFetch is not a good name for defining the fields to be fetch for
relational fields. So we decided to rename it to relatedFields.
Part of Task: 3179751
closesodoo/odoo#113963
Related: odoo/enterprise#37651
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Refactoring send&print wizard.
==============================
Main reason for this commit is that we want to let the user
decide when to generate the relevant documents / approvals
for its invoices. The natural choice is when the information
leaves Odoo. So now, each time the users decide to
download/send its invoices, he will be able to select the
relevant documents to be generated and the approvals to be
requested from the send&print wizard.
This used to happen automatically during the posting with lots
of undesirable behaviors (difficulty to update/revert, hard to
know exactly what will happen,...)
Main changes:
1/ Send&print wizard
- The model 'account.invoice.send' has been replaced by
'account.move.send' and became models.Model to handle
asynchrounous generation of documents (webservice,..) in
case of more than one invoice.
- The wizard is meant to be overriden in order to add
checkbox and document to be generated. A comprehensive exemple
can be found in account_edi_ubl_cii.
2/ Import invoice from attachments
- The decoding logic has moved from account_edi to account
on the attachemnts.
- The function _extend_with_attachments() serve as a common
entry point for import (from chatter, dashboard).
3/ Export invoice pdf / document
- All the specific actions to export attachments should be
implemented on the account.move and called from the wizard in
_generate_documents()
- The official pdf for the invoice is now only generated once
the user request it. In order to regenerate the pdf and
documents, it needs to be deleted.
task-id: 3117238
[enterprise](https://github.com/odoo/enterprise/pull/36757)
[community](https://github.com/odoo/odoo/pull/111857
)
[IMP] web: enable close on ir.actions.act_url in wizard
Before this commit, calling ir.actions.act_url on a modal
leaves the modal open. Which feels ackward in the send&print
wizard.
We now enable 'close' parameter on ir.actions.act_url. If set,
the wizard will close after act_url.
closesodoo/odoo#111857
Related: odoo/enterprise#36757
Related: odoo/upgrade#4387
Signed-off-by: Laurent Smet <las@odoo.com>
Before this commit, in a grouped kanban view, a lot of rerenderings
were done when the user dragged a record from a column to another.
This commit adds an option to Record.update to bypass the rendering
part, and we use this option for calls during the record move and
resequencing, as we know that the view will be rendered at the end
anyway.
Fixes performance issues spotted on odoo.com (Project task grouped
kanban view).
closesodoo/odoo#114225
X-original-commit: 3aa91db099532c09b12f1a4148ae3829a1a9593b
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The evalContext getter is called a lot of times during a rendering
of a view, by several components (the renderer, the fields...).
It is a getter better it can evolve (with reloads, changes...) and
we wanted to ensure that it's always up to date. This causes
performance issues, in particular in grouped kanban views where
we can have a lot of displayed records, and fields.
To mitigate the issue, we introduce a brief cache that is reset
after a micro tick. The rationale is that during a rendering, the
evalContext doesn't change, so we'll compute it once and then
retrieve the same object. After a micro tick, the value is reset,
so it will be recomputed the next time we need it.
Mitigating perf issue on odoo.com (Project tasks grouped kanban
view, when resequencing records).
X-original-commit: 7ec8e3124325da65031c6c7c392c34f56c534cc5
Part-of: odoo/odoo#114225
Very niche usecase, but still:
\- Create a planning shift, set a recurrence for ever.
\- Go few occurences later (form via kanban) and set...
...recurrence type to "Number of Occurences",
...recurrence nmber to 1.
\- Save.
The write method will update the recurrence
so that it only contains only one occurrence.
Consequently, the record you just updated is deleted.
Then we try to fetch the record to display its form again.
Because de read returns [], _fetchRecord rejects the promise,
and we're stuck.
So, in this commit, we make `FormController.saveButtonClicked` call
`Record.save` with its params, so itself can be called with throwOnError,
and the potential error catched.
We all so cover the case where `BasicModel._fetchRecord`
returns `Promise.reject()`, in `BasicModel.save`.
Also, `Record.save` has an object as a default value for params.
When we call it from `FormController.saveButtonClicked` with params,
say params is an empty dict, the default value will be lost.
Istead of overriding this object, this commit only overrides/adds
the key of the object we give `Record.save` if any.
Also, when investigating on that, we jsut noticed that,
when you click save on a form dialog,
it reloads the record before closing it, which is useless.
closesodoo/odoo#112335
Related: odoo/enterprise#37752
Signed-off-by: Audric Onockx (auon) <auon@odoo.com>
This commit adds the possibility to display a properties field in a list
view.
How it works:
When a properties field is present in the arch of a list view, it will
not be displayed directly. It will display its properties as an optional
column. Now, we will find at the end of the dropdown of the optional
columns a section by record parent of the properties field. The proposed
sections will be the properties linked to the parent record of which at
least one record referring to it has been encountered during the
navigation in this list view.
(A parent record is the record storing the properties definition).
Limitation:
Multi-editing is not applicable on properties fields as you cannot edit
one property without modifying all the others.
closesodoo/odoo#112005
Taskid: 3105039
Related: odoo/enterprise#37004
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: mcm-odoo <mcm@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
Before this commit, the user had the possibility to spam the "Log in"
button when trying to connect. This could lead to a change of the CSFR
token and an errror of type "werkzeug.exceptions.BadRequest: 400 Bad
Request: Session expired (invalid CSRF token)" could then happen.
This commit makes the “Log in” button un-clickable once it has been
clicked and adds a loading effect to it.
task-2996329
closesodoo/odoo#114226
X-original-commit: e6273856b2f5ef13c5cf965ae79b830498beaa5a
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
This commit adds the possibility to navigate between the different views
of the view switcher from the palette command.
closesodoo/odoo#113658
Taskid: 3205658
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
We remove a useless import of GroupByMenu and refactor the processing
of data points in the model.
closesodoo/odoo#114172
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 setDirty prop from concrete fields. Now if
needed the fields can declare itself dirty using triggering
"FIELD_IS_DIRTY" on the model's bus.
Note that this PR partially revert [1] and completely revert [2]
task-id 3179751
[1] : 89c2a3978e
[2]: c79bb3c9c6closesodoo/odoo#114124
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: point_of sale, web
Previously, the error handling code was refactored and centralized, in
doing so, we broke the ability to select a table while offline: when
selecting a table we ask the server about the orders for the table. When
offline, this creates an error that was previously caught, and showed an
offline error popup, but continued the rest of the flow normally. The
refactoring centralized the display of offline errors to an error
handler, but removed the catching, causing the error to interrupt the
flow.
This commit fixes that by catching the error again, and when it's a
ConnectionLostError, it dispatched the error in a separate async call
stack (using Promise.reject) so that the display of offline errors is
still centralized, the the flow can continue normally.
closesodoo/odoo#114077
X-original-commit: f45f5e644b4b219b968fa19737d75cc710c823f3
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
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>
FrancoisGe