| Age | Commit message (Collapse) | Author |
|---|
|
Currently, when form view is opened in edit mode and if you proceed
through the tab(keyboard) then focus is skiped on radio field.
For Ex: in project when you procceed through the tab it will skip the
visibility field radio.
The issue occurs because the radio is inherited from the selection
field and in selection field the focus is set on 'select' while
there is no method to set the focus in radio and radio does not have
'select' element it has 'input'
So in this commit, override the method getFocusableElement in radio
widget and set the focus on 'input' instead of 'select'.
closes odoo/odoo#52073
Taskid: 2252798
Closes: #52073
Related: odoo/upgrade#1430
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
closes odoo/odoo#52826
Related: odoo/enterprise#11084
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
closes odoo/odoo#52347
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Generally, Users are not necessarily aware that they can quick create a most
records by simply typing in their name+enter in the many2xxx field input.
The exact purpose of this commit is to make sure the user discovers the quick
create feature of our many2xxx fields.
For that, when the input is empty, display 'Start typing to create a record...'
at the bottom of the dropdown when can_create is set and no_create_edit option
not set. So the user can easily understand that by typing and pressing enter
will create the new record.
Also "Search and Create" options in the dropdown only been shown to the user
when it type anything in the input box as the same case in the "Create" option.
Task : 2266557
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
|
|
Issue
- Install Projects
- All Tasks > Form View
- Edit the view
- Set statusbar clickable to '0'
Still clickable
Cause
In relational_field.js we do
`!!'0'` which returns true
like `!!'anythingelse'`
Solution
Add a '+' which will convert
the value into an integer
for a better conversion.
OPW-2235311
closes odoo/odoo#51083
X-original-commit: 53cc68fce32f46a0b4bc83a1e73a5d13a60fc995
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
|
|
Write something in a many2one field, and click on 'Create "..."'
to quick create a record with the given value (name_create). When
the name_create fails (e.g. because there are mandatory fields in
the model), we open a form view.
Before this commit, when this happened for many2one fields inside
x2many editable lists, it crashed, since [1].
[1] 50bf8309f88fb6c8d8e27b14d40450e92e5a4e4e
closes odoo/odoo#50948
X-original-commit: 43c513306094444ff25ad98584b426ddb8a3b525
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
This commit improves the dialog that opens when a user clicks out
of an 'un-commited' many2one. It is no longer possible to edit
the value, and the sentence has been reworded.
closes odoo/odoo#49528
Task: 2234212
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
In readonly, this widget displays the image of the related record
next to its display_name. In edit, it behaves exactly like the
regular many2one.
Part of task 2195254
|
|
A long time ago, commit [1] increased the limit of displayed badges
inside a many2many_tags widget, from 40 to 1000 (a large limit that
should never been reached with such a widget).
However, this solution was specific to the many2many_tags widget,
and didn't apply to its extensions (like the many2many_tags_email
widget). For instance, open the chatter full composer, add 40
partners in the recipients field and try to add one more: nothing
happens.
This commit sets the limit on the widget itself. That way,
extensions automatically have the same limit, and can override it
if needed.
[1] d4cf4374d1baa529bb651bb3cc32e9db140963a8
Task : 2091027
closes odoo/odoo#49488
X-original-commit: 02e41f1131b4ea3ad977cc241a3d447c37195f6e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Some web actions/controllers/viewsl have been adapted to properly instantiate the
newly refactored control panel and update it accordingly. We needed to adapt the
starting mechanism of actions and controllers to ensure that the control panel
instantiation did not delay the loading of any widget.
Part of task 2196029
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
|
|
The FieldMany2One allows to quick create record (name_create).
However, sometimes, required fields on the co-model make the
name_create crash. In this case, the FieldMany2one opens a form
view in a dialog to let the user specify those fields, and create
a new record with the 'create' method. This was working fine.
The FieldMany2ManyTags embeds a FieldMany2One to let the user
search for and select or (quick) create tags. In this case, failing
quick creation didn't fallback on the dialog form view, but
displayed a server error instead. This commit fixes this issue.
Bug introduced by 50bf8309f88fb6c8d8e27b14d40450e92e5a4e4e
Task 2192754
closes odoo/odoo#47183
X-original-commit: 63ab065f3298c13bb19ae1245d7fd2652581b254
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
This commit fixes two issues that occurred in the following
situation: in a form view, have a one2many field F1 displayed as a
list, that contains another one2many field F2, displayed with
widget many2many_tags (in the list), and with a list in the form
(in the dialog). In the dialog, the list of F2 displays a
field, say 'name', which has an onchange that sets 'display_name'.
Moreover, there is an onchange in the (main) form view, that
populates F1 and F2, for instance, it returns something like: {
F1: [[5], [0, 0, {
F2: [[5], [0, 0, {
display_name: 'xxx',
name: 'xxx',
}]]
}]]
}
1) If the user opens a related record in F1, and adds (in the
dialog) a related record in F2, then validates the dialog, the
newly created record in F2 isn't correctly displayed in the
many2many_tags (the display_name is `false`), i.e. the onchange
hasn't been applied.
2) If field 'name' in F2 in the list is required, the new record
can't be saved, even if the user enters a correct value.
In both cases, the reason is that we use the incorrect viewType in
datapoints: as we don't specify that we specifically want 'list',
the 'default' one is taken, and we thus use the fieldsInfo of the
many2many_tags, which only knows field 'display_name'. As a
consequence, onchanges aren't correctly applied (issue 1), and
fields aren't correctly reset (issue 2).
Issue reported on task 2189529
|
|
This commit trims leading and trailing spaces in search terms of
many2one.
task-2187414
closes odoo/odoo#45282
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Before this commit, there was a discrepancy between
many2many_tags widget and regular many2many list
That is, in tag mode, when someone had read access alone on the comodel
he could modify the members of the m2m relation on the current model
Which couldn't be done in m2m list
After this commit, it is possible in a m2m list to add
records to a relation, even if we don't have CRUD access on the comodel
Task 44074
closes odoo/odoo#40194
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
By default, in readonly, unset field widgets (and their labels) are
not displayed. However, we would like the statusbar widget to be
always displayed (even when it is not set).
This commit introduces a new method 'isEmpty' on AbstractField, and
uses it (instead of isSet) to determine whether or not a field should
be hidden. By default, it uses isSet, so that it doesn't change
anything for the other fields, and we override it in statusbar to
always return false.
There was a need to make the distinction with isSet, as this one is
used to determine if a record can be saved (if the field is required,
and isSet returns false, it can't be).
task-2172272
closes odoo/odoo#43419
Related: odoo/enterprise#7929
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
After this commit, x2many fields can have options like
create/delete which accept a domain, to make create/delete on
x2many conditional, say for example x2many field can have options
like:
options="{'create:' [('foo', '=', True)]', 'delete:' [('foo', '=', True)]'}"
With this when foo field is True, Create and Delete actions will
be available, but if foo is False then they won't.
In case of one2many fields, if 'create' is false, then 'Add a line'
(list) or 'Add' button (kanban) won't be displayed.
In case of many2many fields, 'Add a line' or 'Add' button will
always be displayed even if 'create' condition is false as it
doesn't really create records (but rather links existing ones).
Same applies for delete.
Task-2092953
closes odoo/odoo#42919
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Parth Chokshi <pch@odoo.com>
Co-authored-by: Aaron Bohy<aab@odoo.com>
|
|
*sale,sale_product_configurator
Let's assume a form view containing a many2one with an onchange
that updates the value of a one2many. Do a quick create in the
many2one. While the name_create request is pending, add a row to
the one2many but do not leave it. When the name_create returns, and
the onchange has been performed, the one2many is reset, and the row
is no longer in edition (worse, it could be invalid, i.e. in a state
that the user could not have reached in a normal situation).
This commit fixes this issue by considering the whole [name_create +
onchange] operation as one. This operation is executed in the mutex
of the model, so the other request (adding a row to the one2many) is
delayed until the many2one value has been correctly set.
This fixes an issue with the sale and rental tours (on sale_order),
that had been deactivated for a while.
|
|
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 #38509
Closes #40173
closes odoo/odoo#42867
X-original-commit: 1ace56f9a8cb56fb39235468dd13447bcbbee40a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
Issue
- Install CRM & Studio
- Edit CRM kanban view
- Add tags > select "tags"
Traceback
Cause
_render is called multiple times, there is one case where
`this.$el` is undefined.
Solution
Checking if `this.$el` exists before using it.
OPW-2156964
closes odoo/odoo#42382
X-original-commit: 05f31289c1bb1d8c4b8e1f72f519e8e35e5ecb8c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
|
|
This reverts commit ff1c35513aecef5fbc30f7c2f3834450e719714e.
closes odoo/odoo#41480
X-original-commit: 116057b26e71db4692280463669f3e80d813ddcc
Related: odoo/enterprise#7110
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
Some debugging lines were introduced in https://github.com/odoo/odoo/commit/30cf7bc798ddede8e610001146f4a76352aa582f
Those should be removed
closes odoo/odoo#41400
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
|
|
Task 2046908
Instead of having all the fields duplicated with second_*, we have now a
o2m allowing us to
* have more than 2 lines
* reduce duplicated code
* fix bugs and add features at only one place
We also remove the computation of writeoff and suggestions from the
client side as some code was 4-upled before (twice in in client and
twice in server side). The logic is now only at one place.
closes odoo/odoo#38119
Related: odoo/enterprise#6324
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
|
|
FontAwesome 5 introduced new names for some icons as described on
https://fontawesome.com/how-to-use/on-the-web/setup/upgrading-from-version-4#name-changes
This commit replaces the old names to the new ones.
closes odoo/odoo#35826
Taskid: 2050241
Related: odoo/enterprise#5180
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
X-original-commit: 127a75ed5c746291f9b0b7466d8935c83abc32a0
|
|
To reproduce the issue, go in the settings of the employee app,
simulate a slow 3G connection, modify the working hours:
* Select the first one, modify it but don't save it,
* Click on some others working hours consecutively
They will be all editable
* Edit them quickly
Before this commit:
- You get an error
After this commit:
- You get no error and the behavior is the same than in V12:
the working hours are updated consecutively
Note: when you stress the relational field quickly, there is a moment
where this.$el is undefined. This is the reason why the error is raised.
OPW-2088558
closes odoo/odoo#39435
X-original-commit: 2acb76ffbb2f1ca2a6af0e316da15ce605f2273a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
|
|
``accepted_file_extensions``
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 #2082815
closes odoo/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
closes odoo/odoo#38848
X-original-commit: a62b65a8f9114493064d4efae92825814a880c04
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Allows the quick create on m2o in list views
Before this commit, when entering a new value in a many2one in a list and
exiting the cell through a click, the quick-create modal appeared for the
duration of the mousedown.
Now, the modal remains and allow to edit the new many2one value
Task 2076380
closes odoo/odoo#38289
X-original-commit: c00f84eb0a176b8d23927080078eb02dc2e5d806
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
|
|
Changes the behaviour of many2ones when their value is changed via a form dialog.
Before this commit, when editing a m2o with a form dialog opened by an external button,
the field triggered an onchange with its old value before reloading its widget.
This caused the edition in list views to display outdated information when
saving multiple records.
Now, the reload is executed first, then the onchange occurs so that the value is
the newly updated one.
Part of task 2078807
closes odoo/odoo#37576
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
*:board,hr_skills
Hold on tight, this is a tricky one.
Allows *any* readonly list view (only plain lists, not x2manies) to
become partially editable when checking records.
This means that once checked, a record line acts just like it was
in an editable list. You can click on it, edit any of its values as long as
they're not constrained by readonly modifiers, and save them on the fly.
Clicking on an unchecked record will have the same effect as before:
it will open the record, regardless of the other selected records.
You can also check multiple records and edit them all at once by
changing the value of one selected record (just like standard multi edition).
Keyboard navigation is also allowed between selected records (TAB and SHIFT+TAB
to navigate and ENTER to save).
/!\ If a list is only made of records having all of their fields locked by
readonly modifiers, checking a record and clicking on it will do absolutely
nothing. This is to keep consistency with the rest of the specs.
Task 1967602
|
|
closes odoo/odoo#37372
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
closes odoo/odoo#37314
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
Gives time to the user to enter an actual value in m2o in list views.
Before this commit, emptying a many2one field (selecting all > BACKSPACE or DELETE)
triggered instantly a field_change. This was an issue in multi edition as a field
changed triggered instantly a save on selected records without giving time to the
user to enter a new value.
Now, many2ones only trigger a fieldChange when selecting a new valid value.
|
|
Fixes the way many2one fields are rendered in editable list views.
Before this commit, many2ones in readonly mode would render as links
and their widget would be considered as active even though you couldn't
edit it.
Now, they are rendered as plain text and act the same way as readonly char fields.
|
|
*:
- account
- barcodes
- calenndar
- hr_timesheet
- mail
- mass_mailing
- partner_autocomplete
- web
- website_slides
This commit removes description of fields that should not be shown in
non-debug mode Studio. Only field widgets whose own description is
set are displayed in non-debug mode Studio in "Widget" of sidebar.
In other words, even if any ancestor has a description but not the
current widget, it won't be displayed in the sidebar in non-debug
mode.
Task-Id 2056992
closes odoo/odoo#35902
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
|
|
There are too many image sizes. Since they are stored resized this takes time to
generate when saving a new image, it's more rows on the attachment table, more
files on the disk, ...
64px is close enough to 128px that it can be removed without a big impact on
download size.
It will even reduce download and number of requests when both images are
displayed because now only one has to be downloaded and then benefit from cache.
The difference between the two is typically around 1.5kB which is negligible
these days, especially when the request overhead is around 0.5kB already, not
even taking into account other factors such as latency.
If a 64px image must absolutely be returned, it is still possible to pass the
size parameters to the image route. But the current guideline is to handle
resizing in the views when necessary.
Views
=====
- remove width and height attributes when existing CSS rules are overriding them
(eg. `.oe_kanban_avatar` in the right context)
- add CSS rules instead of width and height attributes when possible
- use `object-fit: cover;` where width and height are forced to avoid distortion
of non-square images
- for products, use `object-fit: contain;` instead, keep ratio but without crop
- add new CSS rules where the expected size was max 64px*64px before due to the
image size itself
- remove `img-fluid` where using size classes to avoid conflicting rules
task-2060865
closes odoo/odoo#36147
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
|
|
PURPOSE
Previously when the 'SAVE & NEW' button was pressed in the 'create and
edit...' menu of the many2many_tags widget was pressed, the modal window
would close and the button would act exactly like the 'SAVE & CLOSE'
button. This was due to the fact that whenever a new record was created
and added to the field, it would reset the many2one field it uses for
display, which would destroy the edit modal.
This commit fixes that by not notifying the underlying many2one field of
any change until the modal is closed by the user. This has the
disadvantage that tags display, if visible behind the modal 'shade',
will not be updated until the modal is closed, but restores the
functionality of the save&new button. It also adds a test for this
behaviour
task-2070454
closes odoo/odoo#37114
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Gives time to the user to enter an actual value in m2o in list views.
Before this commit, emptying a many2one field (selecting all > BACKSPACE or DELETE)
triggered instantly a field_change. This was an issue in multi edition as a field
changed triggered instantly a save on selected records without giving time to the
user to enter a new value.
Now, many2ones only trigger a fieldChange when selecting a new valid value.
Task 2068280
|
|
Let's assume an editable list with a many2one and a char, the many2one
being readonly. Before this rev., if the user clicked on the many2one,
the row was switched in edit more, and the many2one link was given the
focus.
Now, in the same scenario, the focus is given to the char field which
can be edited (i.e. its input).
Task 2068280
|
|
closes odoo/odoo#36721
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
Purpose
========
In expense, we now allow any simple employee (no sales access rights) to
select sales order. Technically, the name_search is done in sudo mode,
to allow simply fetching the name_get of record.
The problem is that the m2o field widget displays the "search more"
option and click on that will open a modal executing a "search_read"
which is causing access error as the user doesn't have read access on
SO.
As we want to restrict the visible information from the SO(only name_get)
to all user, we can't hack the search_read too.
Specification
=============
To prevent user frustration, we need to remove the "search more" option.
Thus, make a private function which one have 'search more..' option
related stuff and create a new widget for sale_expense, override that
function which one is returing values as it is without any modification.
task-2057714
closes odoo/odoo#36152
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
|
|
Part of task 2005972
It is used in account_asset, when the o2m field is hidden and at the end of the form, but we need the user to see it at the beginning of the form
closes odoo/odoo#36315
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
|
|
|
|
|
|
|
|
Before this commit, a field selection which was required
did not have an empty option
ref: 4dfabb8f7adde06a7936502af61534c9958ed4f7
This is fine, but overlooked the fact that modules can modify
the required attribute, or even views can do it
So, we may end up in a situation where the field is required but set to false
This configuration is problematic, at least for the timezone selection field
(see OPW)
After this commit, the empty option is just not visible
note that `disabled = True` would not work because val is not accessible
Because of commits:
- 4dfabb8f7adde06a7936502af61534c9958ed4f7 for the selection feature
- d77ce4c2a92c1da48150e4e84b714dd93f64847d overriding the required attribute of tz in res.user form
OPW 2057913
closes odoo/odoo#35989
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
|
|
currently widget selection is not working in m2o in editable list view and
to fix this issue it need a lots of changes to make it work properly,
i.e. make '_fetchSpecialRelation' use correct domain for each record,
batch requests as much as possible, also make all '_fetchSpecial...'
work in the list case.
So to avoid major changes remove supportedTypes from selection widget
so user can not tempted to apply selection widget on many2one field.
task-1871698
closes odoo/odoo#33485
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
closes odoo/odoo#36491
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
Mainly, when adding the first record to the list, as this is when
we switch from forcing the column's widths (when there is no data),
to letting the browser optimally divide the available space.
Some other cases had to be handled, like the multi edition.
|
|
This rev. refines the way we compute column's widths in editable
list views.
When there are displayed records, we let the browser compute the
width of each column (which is thus optimal with respect to the
content), and we then freeze those widths s.t. it doesn't flicker
when we switch a row in edition.
When there is no record, we keep the former heuristic based on
absolute and relative widths (depending on field types). However,
we set the same weight for all fields having a relative width (i.e.
all but boolean, date(time) and numeric), such that the remaining
space is evenly distributed between them.
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
