In this commit, we will remove:
- groupedBy because the api is weird, we don't want to handle type abbreviations.
- getAggregableRecords because it is only used in one place.
In this commit, we will also convert canQuickCreate to utils and we will
move it to kanban because it is the only view that uses it.
Part of Task: 3179751
closesodoo/odoo#114459
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The main goal of this commit is to simplify, uniformize and remove
unused props. The props removed are : options, attrs and className.
The readonly prop is uniformized with the one in the fields api. It will
now allow the use of readonly as modifiers on the widgets, as it's
already the case on fields.
This commit also uniformize the parseWidgetNode with the parseFieldNode,
the widget doesn't receive on props the rawNode anymore but a widgetInfo
as is the case for the fields.
Part-of task-id 3179751
closesodoo/odoo#114188
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 value prop from concrete fields. Now each
field will directly use this.props.record.data[this.props.name] to
access their value, As a consequence of this, the name props need to be
mandatory.
task-id 3179751
closesodoo/odoo#113495
Related: odoo/enterprise#37464
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit:
- When a color index is greater than 55, the CSS class applied does not
have a matching style.
Only 56 CSS classes have a matching style: from 0 to 55.
To reproduce:
- Go to Calendar, edit an event and add an attendee having an id greater
than 55. When displayed, the event does not have a proper color.
It has the default FullCalendar color instead.
After this commit:
- The colors will cycle through 55 colors, from color 1 to color 55.
(Color 0 being the value for "no color", which is some kind of gray)
closesodoo/odoo#114491
X-original-commit: eda4e12202a1bf6459009b41313f9af4b4dc326b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Before this commit, the model's record had two similar functions: isNew
and isVirtual, this commit will remove the isVirtual function to only use
the isNew one.
closesodoo/odoo#114431
Part-of: task-id 3179751
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
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>
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>
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>
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>
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>
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>
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>
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>
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
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>
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
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
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>
To reproduce
=============
- on settings upload a custom background on document layout and save it
- open document layout again and try to download the image -> Traceback
Problem
=======
when calling download method we will ask server for a record with `id=false`
which gives an error
Solution
========
download button shouldn't be visible when `record.resId == false`
opw-3138230
closesodoo/odoo#113029
X-original-commit: 2e2cdee563dd645cabe2d361489d6eb17b174a33
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes an issue where the "No records found" helper text is
wrongly positioned below the sample data's records (i.e. not visible)
instead of over them.
This is basically a revert of 9407383a56
due to the changes in the DOM and styling made in the meantime.
But actually we can go further and ensure we always have the ListView's
table present in the DOM. This change allows to simplify the positioning
of the helper and the implementation of the Purchase's dashboard.
Steps to reproduce:
- create a new database **without demo data**
- install "Planning" and "Sales" apps
- with a mobile-like screen size, open Planning
- switch to Gantt view
- in a cell, click/tap on the magnifier button (which is on hover...)
- the many2x view doesn't contain data
=> action helper "No records found" isn"t visible (scroll to bottom to
find it)
closesodoo/odoo#112878
X-original-commit: 766498a36b322ffe9c647616f56f3ba04cc51d96
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit, the field's description was stored on the
component and this component was then registered.
Now, an object describing the field is used on registration the same way
as it is done for views since https://github.com/odoo/odoo/commit/b828cfc72c587d0b73fcc5459695705640437671.
This split the component's description (props, template, ...) of
the field's description (displayName, supportedTypes, ...) and makes
it clearer.
closesodoo/odoo#112498
Task: 3171520
Related: odoo/enterprise#37105
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since commit (1), the write/writeText were no longer correctly called,
because the browser native functions couldn't be called. Sometimes, it
raised the "Illegal invocation..." error, or could have an unexpected
behavior, preventing the value to be copied in the clipboard, which made
the button pointless.
No additional test was added, since it is difficult to test the clipboard
API programmatically, and the current test coverage is all that we can do,
without using the real clipboard object.
(1): 9cdcd1c1f7219030386d2c90205ea083eb835a13
closesodoo/odoo#112843
X-original-commit: 767922d43334a6cbccdb4be64f207813240fd314
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
repro steps:
1) in any kanban view that is not grouped, use the arrow key to focus the last card
2) use the up key to focus the previous card
3) use the TAB key to focus any element inside that card
4) use the down key to try to navigate to the last card -> traceback
The error comes from the fact that `focusNextCard` assumes that the
focus is exactly on the card element and not on any of its children.
closesodoo/odoo#112797
X-original-commit: 76434f4959cd0fade41ad02f790226f1a8046fea
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The goal of this commit is to disable sample data mode when creating
a record using an on_create action in an empty kanban view.
How to reproduce:
- Go to an empty kanban view with an on_create and sample="1"
- Click on the create button
- Validate the creation
Before this commit:
The kanban view is still in sample data mode.
After this commit:
The kanban view deactivates the sample data mode.
closesodoo/odoo#112732
Taskid: 3176939
X-original-commit: b5909daaa16466321a0ad85aaf013155c0bcf5b2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, there was a hack done in Field.js to handle
a special case of the Many2ManyTagsField which sometimes require
an additional "color" field to be fetched. This field is given in
option on the many2many field, in the arch.
It wasn't possible for the Many2ManyTags field to add that field
on its "FieldToFetch", because this object was static (it didn't
depend on the arch). This commit allows it to do so as FieldsToFetch
can now be a function that receives the fieldInfo (extracted from
the arch) in arguments.
So with this commit, fieldsToFetch can be either an array of fields
(instead of an object as before), or a function returning an array
of fields.
Part of task 3179751
closesodoo/odoo#112518
Related: odoo/enterprise#37020
Signed-off-by: Georis François (fge) <fge@odoo.com>
Community counterpart of the enterprise commit having the same name.
This commit acts as a setup to allow for the reworked gantt view to work
properly.
Task Id: 3105022
Part-of: odoo/odoo#110819
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
This commit adds several improvements and overall changes the way
draggable builders can be built, adding some helpers to temporary
manipulate DOM elements during drag sequences and making some changes
on the way drag callbacks are handled.
The current implementations of draggable hooks built with this feature
have been adapted.
The drag test helpers have also been reviewed to more accurately
mimick real-life scenarios and allow for more flexiblity (i.e. moving an
element to a certain point during the drag sequence before being
dropped).
Part-of: odoo/odoo#110819
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
FrancoisGe