d06e67e748 introduces tools to use owl
renderer in a view. However, this owl renderer is never destroyed.
This commit fixes this issue.
Task-ID 2171436
Before this commit: all dialogs would go through the static method (OwlDialog.hide)
when destroyed, regardless of wether they had been opened or not.
Now, only dialogs having an 'el' property set (= having been opened) will use
the 'hide' method.
Task 2170705
closesodoo/odoo#43124
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Revision on https://github.com/odoo/odoo/commit/141b34f152f36d970d4ff78abe53f563555a8e69
Having async/await as a new promise constructor is an antipattern.
The reason is that it may lead to unnoticed errors: if an inner
promise is rejected, it won't propagate the error to another promise
that will handle the error. As a result, this error becomes unnoticed
and the initial promise is pending indefinitely, which also may lead
to more bugs [1].
[1] https://stackoverflow.com/a/25569299Closes#43072
When accessing stock_barcode module to validate pickings, is not
possible to add floating point quantities for any localizaton which uses
',' as decimal separator.
The numeric field is now defined via browser tags <input="numeric"> to
make the numeric keyboard popup automatically on mobile devices
(commit 8f5840369b28962ab2be9edfce7331a836c3df22)
Adding the override to avoid further processing when the input
is already anumber
opw-2154657
closesodoo/odoo#42748
X-original-commit: 1ccc60deeb067f8d461d48cbf51719317c22cb90
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
New component: the custom file input. Its purpose is to define a input of type file
with a custom trigger (button, link, etc.).
Its construction is the following:
- attributes: behaviour of the actual input (route to call, multifile, allowed
extensions etc.)
- inner template: the trigger that will fire the upload prompt when clicked
Once a file has been uploaded, the component will emit a 'uploaded' custom event
containing the files.
closesodoo/odoo#38423
Related: odoo/enterprise#6031
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
New Owl component: Dialog. It does not rely on Bootstrap but behaves the same
and does not conflict with legacy dialogs.
To call this component, you need to define it in the XML parent template instead
of calling it in the JS file, and put a flag in the parent state to toggle the dialog.
Old dialog file has also been slightly updated to ensure compatibility between both
versions.
This commit also updates a list view test which did not wait for click events to
properly trigger and would cause the new dialog system to crash.
Let's assume a many2many_checkboxes widget in a form view with a
dynamic domain (depending on another field in the view). At first
rendering, the widget contains a checkbox for each value matching
the domain.
Before this rev., if the user changed the value of the field used
in the domain, the many2many_checkboxes wasn't redrawn, so it still
displayed the values matching the previous version of the domain.
Closes#38509Closes#40173closesodoo/odoo#42867
X-original-commit: 1ace56f9a8cb56fb39235468dd13447bcbbee40a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Before this commit, pointer events were prevented on all checkboxes in readonly
list views. That meant that the boolean_toggle widget for instance could not be
properly toggled in a non-editable list (which was the purpose of such a widget).
Now, pointer events are enabled only if the checkbox :
- is in a selected row AND does not have a readonly modifier
OR
- has a widget applied on the field.
Also ensured that the field widgets in the list view multi edition confirmation
modal are not interactive.
We cannot test the `pointer-events` property interactions as it does not affect
manual event triggering used in tests.
Task 2154055
closesodoo/odoo#42848
X-original-commit: c7ee164d572e01fcb565001fd5e62fe1278b5cd8
Signed-off-by: Julien Mougenot (JUM) <Arcasias@users.noreply.github.com>
Before this commit, negative numbers are never rendered as human readable (e.g. 34000 -> 34k).
closesodoo/odoo#42789
Taskid: 2160790
X-original-commit: b51877c4c4c9d8cd873dd0205954fd807d62ee01
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Previously it was always possible to create within the calendar view.
For some modules this did not make sense and lead to confusing behavior,
for example: a new model instance created in the calendar view that was
not viewable in the calendar view, but was viewable in other views. By
adding a 'create' attribute (to be used in view xml), we allow users to
choose whether or not they want a calendar view to be able to create.
Note that this change does not affect the edit ability of calendar views
for existing instances.
Part of
Task: 2126530
Before this change, fields.Reference displayed into the popover of
a calendar view was always empty. This was because the popover view
generated from a double click on an element in the calendar view
creates its own recordModel in JS and the function to create this
record did not handle the reference field case.
This commit detects if a reference field is defined into the record
and adds the necessary processing to process its value and creates
the corresponding dataPoint.
opw 2151635
Closes#41262closesodoo/odoo#42707
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
While x_name has long been automatically supported as an equivalent
of name, x_active was not.
This commit adds this behaviour OoB, both in the ORM and the web client.
On the ORM-side, a new `_active_name` attribute is supported on models.
This attribute specifies the field that should behave as an active marker
for records of the model. It is supported the same way `active` has been
until now (filtering by the `active_test` context key and toggled by the
`action_archive`, `action_unarchive` and `toggle_active` methods).
Although no check has been added on the field's type, it is assumed to
be a boolean field (the same way no check is present on the `(x_)name`
field).
On the client-side, the list view and form view now both support
detecting the presence of either `active` or `x_active` on records,
automatically adding an '(Un)Archive' button in the Action menu if such
a field is detected.
Note that the ORM implementation does actually need the field to be named
in any specific way, but since the web client has no mechanism to load
information regarding a model (the lifecycle of an action loading
includes loading the action, view and record(s) but no generic
information about the model itself besides what is included in the
views), we restrict the field's name to `(x_)active` to avoid confusion
as any other name would work at the ORM-level but not in the client.
In the future, the client might be able to more elegantly get
information about models, but this was not the scope of this change and
this solution should cover most cases.
Note that the `active` field will always takes precedence over the
`x_active` field to avoid confusing the polarity, even if both fields
are present on the model.
In the case of a custom field, it might be slightly annoying that the
default value of a Boolean field is `False`, which means that upon
adding the column, all existing records are automatically archived. This
can easily be worked around using an `ir.default` record for that
particular field and an update of existing records (e.g. through the
list view). The goal of this change was not to make it easy to add
support for custom active fields, but to make it possible - we have
therefore kept this implementation which introduces few changes while
adding enough flexibility for developers.
See https://twitter.com/zubair_shafiq/status/1202587553871880192?s=20
for more info regarding supporting any `_active_name` in the web client.
Co-authored-by: Raphael Collet <rco@odoo.com>
Revision on [1].
Commit above made changes to test helper `nextTick()`, so that it
waits for `window.nextAnimationFrame()` (shorten, 'rAF'). This was
useful to wait for OWL rendering, since OWL renders on next animation
frame.
From a theoretical standpoint, the helper should wait at least as
much time as before, as it adds either no slowdown (rAF is readily
available), or a few milliseconds wait (rAF waits for next available
animation frame).
However, some old tests show non-deterministic behaviours, resulting
to crashes [2]. It suggested, for some reasons, that `nextTick()` did
not wait long enough for re-render... Which is surprising considering
explanation above!
Some of these tests have been fixed, assuming it was caused by un-
guaranteed order of successive `setTimeout(0)` [3]. Unfortunately,
this does not explain why it never crashed before the change on
`nextTick()`...
After investigation, we think that this behaviour comes from rAFs
having their own task queue, which no longer guarantees that queued
tasks happen after queued micro-tasks:
When the requested next animation frame is readily available, the
callback of `requestAnimationFrame()` is immediately called and waits
for `setTimeout(0)`. The `setTimeout(0)` await is resolved before any
other queued async micro-tasks, so that `nextTick()` is resolved
sooner than expected. This would explain how `nextTick()` does not
wait long enough for rendering from the loads of resolved Promises,
even though there is a promise resolution after `setTimeout(0)`.
This commit fixes the issue by moving the await `setTimeout(0)`
before the rAF call, so that it correctly waits render from chain of
resolved promises (since the `setTimeout(0)` is awaited in the same
main task queue).
[1] https://github.com/odoo/odoo/commit/b0941d19a07b08fabc64a284b58e57edc46203dd
[2] http://runbot.odoo.com/runbot/build/771505 and http://runbot.odoo.com/runbot/build/752855
[3] https://github.com/odoo/odoo/commit/6cbfdbce2d0f1b567b6a6d6f637fe2a476980accclosesodoo/odoo#42123
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
The attribute "groups" on filters and fields in a search view arch was not taken
into account anymore.
Now items that should be invisible are not anymore available for selection
in the interface (as expected) but are still activable as search defaults
(and the corresponding facets appear if needed).
Task ID: 2081450
closesodoo/odoo#42125
X-original-commit: ca2514a9fbcd693752367cb566d5c11165b40bd4
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit introcudes two changes to the multi edition in list views:
1. Editing one record does not require confirmation through a dialog
2. Successfully saving multiple records unselects all currently checked records
Task 2146429closesodoo/odoo#41099
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Prior to this commit, there was no clean way to have a button
triggering asynchronous work (like asking user for confirmaton
for example) and close or not close the modal according to the
user choice. Your options were:
1. Swallow the pill and just accept that the modal will close
even if the user chose not to undertake the action.
2. Set the `close` parameter of the button to false and handle
the conditional closing by yourself from outside the dialog.
This commit introduces a way to tell the form view dialog that
the action has not been processed correctly and that the modal
should not be closed by returning a rejected promise. Prior
behavior can still be obtained (close no matter the result)
by having the handler not returning a promise at all.
closesodoo/odoo#33837
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Removing the test "field changes are correctly debounced in text fields"
because it doesn't represent the reality that fields are not debounced
anymore in production code.
This test was nondeterministic.
Sometimes, it might be useful for an action (e.g. a client action,
although this may be used by standard views as well) to include custom
values in its state. Since the state of a 'fullscreen' action is pushed
in the URL, this means that it is possible for the action to resume its
state properly upon refresh of the page (before this commit, only some
standard information were pushed to the state - action_id, menu_id, etc.
for window actions and action's name, active_id, active_ids for client
actions).
By implementing the `getState` method, an extension of the action mixin
can thus push any state it wishes to the URL.
closesodoo/odoo#39529
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Because the webclient and other higher level components such as the
actionManager are not yet rewritten in OWL, we cannot make a complete
migration of the controller and the model to a more OWL-ish code.
We have rewritten the renderer completely in OWL, it uses more
extensively a template and manages its own state and its sub-components.
We did not rewrite the controller, however we have made it inherit from
`web.ControllerAdapter` which is a thin compatibility layer used when a
odoo controller uses a OWL renderer.
In the tests, the only changes are that all the events triggered by the
test and handled by OWL must be triggered on DOM nodes directly and not
on JQuery elements.
closesodoo/odoo#39491
Related: odoo/enterprise#7135
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: VincentSchippefilt <vsc@odoo.com>
Co-authored-by: pro-odoo <pro@odoo.com>
In this commit:
- transformed test_utils helpers to always trigger native events
- introduced new test_utils_create helper: prepareTarget
- updated qunit asserts to support Owl Components
- updated all misused helpers that would crash with the updated test_utils
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Pierre Rousseau <pro@odoo.com>
With this commit, we properly introduce the Owl library into our beloved
codebase. More information on the Owl library can be found in the project
repository: https://github.com/odoo/owl/
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Before this fix, a QUnit test was wrong (didn't parse)
After this fix, the test actually works and tests something.
closesodoo/odoo#41257
X-original-commit: 3818a7f0df754717a7379dc8341729b508a166be
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Fixes the way record end hours are computed in calendar views.
Before this commit: objects `record start` and `record end` properties being copied by reference
and being incorrectly rewritten by other functions.
This caused incorrect end hour computations (and a SQL crash in the Planning app).
Now, objects are copied by value and don't interfere with each other.
Task 2072961
closesodoo/odoo#37690
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
`name` field can be required and falsy `data.name` should not be
added as default in context or it warns for missing required field.
Task-2052536
closesodoo/odoo#35880
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
On mobile, there was no way to create a new column in the kanban view. This
was specifically annoying in the Project app (the user was able to
create the project but couldn't set its stages).
This commit enables this feature by adding a `+` icon at the end of the
tabs. This button opens a quick-create column widget.
If there is no existing column (for example in a newly created project),
this quick-create column widget is opened by default.
Finally, this commit improves the processing needed for the swipe
animation between the columns.
Task ID: 1893137
closesodoo/odoo#40722
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Co-authored-by: Ankit Sathvara <asa@odoo.com>
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Co-authored-by: Romain Estievenart <res@odoo.com>
Before this commit, with a time range activated in a pivot view,
click on a non empty cell would not always give the right list of
records because of a bad action domain.
The reason is that the headers domain or comparisonDomain were
not always set when appropriate:
- for the headers 'Total', the corresponding group obtained
by read_group does not contain the key __domain. For that
reason both the key domain and comparisonDomain were left
undefined.
- for headers that correspond to groups not present in the two
periods compared, one of the key was left undefined.
With the present commit, we correctly set the domain and
comparisonDomain keys everytime they are useful.
closesodoo/odoo#40713
X-original-commit: 2f89820faa5966b8321d6681e9745a4e938e2bec
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Conditional expressions were already parsed, but there was no support
for executing them (or stringifying them back though I'm not sure when
that's used).
closesodoo/odoo#40502
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce:
1. Go to the Accounting / Invoicing apps
2. Open Taxes (Configuration -> Accounting / Invoicing -> Taxes)
3. Try to create a new tax and the client crash.
It occurs because the `_processX2ManyCommands()` method doesn't handle
correctly a missing `fieldInfo` on some X2Many tags.
On mobile, when calling `load_views` the kanban view is used by default.
But if the kanban isn't defined, a default kanban view with only the id
of the model is used.
In the case of the taxes form, the `default_get` retrieved for this
form refers to a Many2Many (`tag_ids`) inside a One2Many. But this field
isn't present inside the loaded kanban view, so when we process the
command defined by the `default_get`, the `field_view` item doesn't
exist (because the default kanban loaded only contains the id of the
field).
Now instead of using an undefined `fieldInfo`, we fall back to an empty
object on the missing field to avoid the crash.
closesodoo/odoo#40617
X-original-commit: 47a306a31ac6d3c9e68e83b77a80426d5c6ceb05
Signed-off-by: res-odoo <res-odoo@users.noreply.github.com>
This is a weird situation, but the python handles it. Let's assume
a many2one field F1 on model M1 with comodel M2, and on M2 the name
field (which is the _rec_name) being itself a many2one, and the
following scenario:
- create a new record for M1
- for field F1, select 'Create and Edit': it opens a form view for
M2 in a dialog
- type something in F2 input, and click 'Quick create'
- save the dialog
Before this rev., the value of F1 was [object Object]. Now, the new
value is properly displayed.
OPW 2091106
closesodoo/odoo#40549
X-original-commit: 5a04ea848abf50b1fb1f9893d1fcd98013bc025d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Currently, if the first week day was Saturday the calendar week view
would possibly get the wrong week.
This is because current heuristic would get date of current week from 6
(Saturday) to 12 (Sunday).
Thus if we were:
- on Friday 14th, we would have a week day ranges: 15-21 (wrong)
- on Saturday 15th, we would have a week day ranges: 15-21 (ok)
- on Sunday 16th, we would have a week day ranges: 22-28 (wrong)
So it would only get the right range when getting range from saturday.
If a week:
- start on monday, the week range would only be wrong on sunday.
- start on sunday, the week range would always be alright.
Added test without the fix fail:
- CalendarView: Saturday week start week mode
The domain to search events in should be correct
(domain range 14-20 instead of correct 07-13 whilst the day was 12th)
- CalendarView: Monday week start week mode
The domain to search events in should be correct
(domain range 16-22 instead of correct 09-15 whilst the day was 15th)
opw-2091448
closes#40244closesodoo/odoo#40327
X-original-commit: 6c3d74846581d6c1bfc0c6e3a7104440515ddbc5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In editable list view, moving to next cell using TAB key crash when the
following field is read-only (i.e non-focusable) and an onchange() event
is triggered.
Consider an editable tree view like this:
<form>
<field name="o2m" onchange="1">
<tree>
<field name="description"/>
<field name="date" readonly="1"/>
<field name="type"/>
</tree>
</field>
</form>
1. Adding a new line will give focus to `description` field widget
(currentFieldIndex is 0)
2. issuing a TAB keypress, will call _onNavigationMove which calls
_selectCell() with fieldIndex of 1
3. The _selectCell() method set widget currentFieldIndex to the new value
(currentFieldIndex is 1) add call _activateFieldWidget() to activate
on the corresponding widget.
4. _activateFieldWidget() will fail to activate the `date` field as it's
readonly, then try for next ones and succeed to activate the `type` field
cell
5. When focus is given a `type`, the `description` field is blurred which
trigger an onchange() and the controller apply those changes to the
editable list rendererd using the confirmUpdate() method.
The confirmUpdate() will try to get the current selection, but that
field is actually set to the `date` field (currentFieldIndex = 1),
which is readonly and so has no focusedElement - triggering the crash.
This commit ensure we don't try to call getSelectionRange() it current widget
has no focusable element.
OPW-2075229
closesodoo/odoo#39976
X-original-commit: 93c7ae9ba5309810c41c58fc8f2fafb3c3dac76e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This completes a commit that was made for the version saas-11.3 (12.0):
https://github.com/odoo/odoo/commit/1440c8be0337c89e3d67d6d93e614c269c8689f1
Indeed, the logic was implemented for the appendTo, prependTo, etc
methods but not for the attachTo...
This could solve unknown problems in stable versions as well but was
judged too risky to merge there. Indeed, if a real problem occurs in a
stable version because of this, the condition can be added to the
related widget individually.
The problem was found in master: during website edition, the public
widgets can be restarted if an element is edited... but sometimes the
public widgets may be restarted in the same JS stack execution. The
willStart method being async, the destroy method was called before
the start method. This does not lead not any known problem with our
current widgets but will create one for a new snippet being implemented.
closesodoo/odoo#39949
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In this commit, we remove the lazy loading currently used by the mobile
kanban view to avoid the poor user experience. We had to wait each time
we swiped between kanban columns.
Now all data are fetched like in desktop. Note that it might still have
loading during the swipe for folded columns.
Task ID: 1896614
closesodoo/odoo#28142
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
In form views, when the window size is too small, a "More" button
appears and it should contain the overflow buttons.
On all browsers, the "More" dropdown doesn't contain the expected
amount of buttons, so it is shifted on the second line.
Before this commit:
- The "More" dropdown doesn't contain the expected amount of
buttons, so it is shifted on the second line.
After this commit:
- The "More" dropdown contains the expected amount of buttons
and it is not shifted on the second line anymore.
OPW-2079694
X-original-commit: 2bda8230fba07a229fcda77a1528694a0e317917
Be in RTL mode, on a list view
Click on the button to set up optional fields
Before this commit, the dropdown expanded to the right, and was partly invisible
After this commit, we dynamically set to which direction the dropdown should expand
depending on RTL/LTR
Consequently the dropdown is fully visible in either mode, and expands to the list
rather than away from it
closes#39402closesodoo/odoo#39628
X-original-commit: fb914d176de5a4711f11de32945ebaec0164f62e
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the calendar searched records on the wrong time ranges
which did not take into account the timezone of the user
It obviously resulted in some records not being there
After this commit, all the relevant records are fetched according to the right
time range in UTC, corresponding to start/end of the week/month/day of the calendar
OPW 2076114
closesodoo/odoo#39466
X-original-commit: 0f10927efe490bd82e7c23e0fc646dd6c8de2d27
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, all the computation of the default widths for column
headers was done before the list was attached to the DOM, meaning that no
column was actually visible. This was a problem since columns that are
meant to stay unseen were taken into account in the calculation of relative
column widths.
Now, the same algorithm runs once the columns are visible so that invisible
columns can be properly excluded.
fixes#38744
Task 2076721
X-original-commit: 4bf98b47898b075049975dfe597f0fb92c7c14d1
Before this commit, the `width` attribute was interpreted by a jQuery node generator
function as a `style="width"` property and gave an incorrect width value to the affected node.
Now, the `width` attribute is automatically plucked in the list renderer in the
specific function used to render buttons.
Task 2076721
X-original-commit: c67b36c00ca263f51e0dd49d6e38702c4d614289
A 404 will take 3 to 5 seconds to be resolved and execute +- 1900 query, to return
a rendered page which is quite expensive, especially when multiple missing images
are rendered in a view.
Catching static route and marking them as not frontend will help to avoid to handle miss
on static resources. In this case server returns a standard 404.
This commit also fix a iframe src in order to avoid a 404 on
/web/(test )/report/html/some_report (thx to aab-odoo)
X-original-commit: 818d0cb59fbae78d0edf06318082981f318e4db7
In a list view, create a custom filter involving a date or datetime field
Before this commit, the domain that was sent to the server
contained the date or datetime as the pure string
representation that Moment.js constructs
that is a ISO compliant one, containing info on timezone
After this commit, the format is the one of the server, in UTC
and NOT ISO compliant. Also, the format for date is dealt with
OPW 2085936
X-original-commit: 1f1fa173c38dae105637edeb3a1e856e9748a14f
Purpose
=======
We want to add an option on the widgets
- many2many_binary,
- binary,
- image
This option specifies what file extensions the user can pick from the file input dialog box.
Examples
========
```xml
<field widget="many2many_binary" options="{'accepted_file_extensions': 'image/*'}"/>
<field widget="many2many_binary" options="{'accepted_file_extensions': '.png,.jpeg'}"/>
<field widget="many2many_binary" options="{'accepted_file_extensions': 'application/pdf'}"/>
<field widget="image" options="{'accepted_file_extensions': '.png,.jpeg'}"/>
<field widget="binary" options="{'accepted_file_extensions': '.pdf,.svg'}"/>
```
How
===
Add an option (accepted_file_extensions) in the template ``HiddenInputFile`` (the widget many2many_binary is using this template)
So, we can also use this new option in others widgets using ``HiddenInputFile``
In the many2many_binary, read the ``nodeOptions`` and set the widget attribute ``accepted_file_extensions``
We also have to fix some other widget, because an property ``image_only`` was already existing in the template ``HiddenInputFile``
(we just need to replace ``image_only=True`` to ``accepted_file_extensions='image/*'``
The widget ``FieldPdfViewer`` (pdf_viewer) now use the new option to filtrate PDF
(instead of removing the <input/> and adding <input accept='.pdf'/>).
Tests
=====
We also test if the option is correctly set on the <input/>
- binary
- image
- many2many_binary
Impacted widgets
===============
- many2many_binary
- image: this widget use ``options="{accepted_file_extensions='image/*'}"`` instead of ``image_only=True``
- tablet_image: same as ``image``
Task #2082815closesodoo/odoo#38351
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
This option, if set to True, prevents the user from modifying the
color of the tags.
Part of task 2070454
closesodoo/odoo#38848
X-original-commit: a62b65a8f9114493064d4efae92825814a880c04
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, it was not possible to show a message using a client
action. (e.g. show a success message only with core in Python)
Now, it's possible using a client action. This client action call
displayNotification and so we can use the same options also.
A test is added to be sure that this action do not change the current action
Note: in the future a custom registry may be created in a refactoring
to specific function action registry.
X-original-commit: 8775fd670b6b3ec19a77fc0eab72d2223baa36c8
Pierre Rousseau