| Age | Commit message (Collapse) | Author |
|---|
|
closes odoo/odoo#68085
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
|
|
Commit [1] altered the way the FieldMany2Many behaves with respect
to 'create' and 'delete' options. Indeed, for many2many fields,
adding or removing records doesn't mean "creating" or "deleting"
records, as it is only about adding/removing records to/from a
relation. This is completely fine and correct.
Unfortunately, a feature has been lost in the process: it is no
longer possible to state that a many2many field should be editable
but should not allow to add (or remove) record to the relation.
This commit fixes the issue by adding two new options: 'link' and
'unlink' for that purpose.
[1] https://github.com/odoo/odoo/commit/c98579d25af01c14df4baf57fb4652f3e7469096
opw~2466213
closes odoo/odoo#67358
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
|
|
The Many2ManyCheckboxes widget displays all values that could be
in the many2many relation, with a checkbox indicating whether each
value is in the relation or not. It is designed to be set on fields
where the comodel contains a few records (typically, we don't want
to see dozens of checkboxes in the form view). This widget shouldn't
be used on many2manys with a large comodel, as we have better tools
to handle them (like a tree view).
We deal with extreme cases (when the widget is, by mistake, set on
a field where the comodel is huge) by using the name_search limit
of 100: at most 100 checkboxes are displayed.
Before this commit, this extreme situation wasn't correctly handled.
If there were in the relation records that weren't displayed
(because they weren't inside the 100 limit), then, editing the value
by (un)selecting a checkbox would automatically remove all non
displayed values from the relation.
This commit ensures that we keep in the relation all values that
aren't displayed.
Issue spotted when working on opw~2439041
closes odoo/odoo#67373
X-original-commit: fa324ef071952d749f635f878bee0fa462cfa011
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Before this commit, if the widget "many2many_checkboxes" was set on
a field with more than 40 values in the comodel (i.e. more than 40
checkboxes displayed), (un)selecting a checkbox that wasn't in the
first 40 checkboxes crashed. This was due to the default x2many
limit of 40: we only created a datapoint for the first 40 values,
whereas we could have up to 100 values to process (name_search
server-side limit). Note that this limit of 40 had no other impact
than limitating the number of records processed by the BasicModel,
the maximum number of checkboxes displayed being ruled by the
name_search server-side limit.
This commit ensures that all values returned by the server (at most
100 when this message is written) are processed and can be edited
as expected.
opw~2439041
X-original-commit: be5e5bc49cb9744c26ca75dcee74caf11447f250
|
|
Commit [1] adds an override of the getFocusableElement of
AbstractField in FieldRadio, but this function was already defined.
Even though it doesn't crash, this is obviously not something to
do. This commit removes the first occurence (which was overriden
by the second).
[1] https://github.com/odoo/odoo/commit/ebe118fc607391737adc37e18c3278a3d2c87b5e
closes odoo/odoo#65372
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
Let's assume the following scenario with 'purchase_product_matrix'
module installed:
- create a new Purchase Order
- add a line in the one2many
- select "Customizable desk" as product
- [the desk matrix opens]
- close the matrix
- select "Conference chair" instead
- [the desk matrix opens, whereas it should be the chair one]
It didn't work because of a small bug in the FieldOne2Many. This
field is configured to be reset when any other field in the view
changes. The product configurator feature relies on that. However,
when another field changes, the One2Many didn't update its internal
state with the new record (and it skipped the rendering, which is
fine). The matrix product configurator thus read an obsolete value
in the internal of the one2many.
Since the internal state is now always up-to-date, we can directly
read there the grid information, instead of looking inside other
fields that have been updated (attempt done in [1])
It would be nice to rethink the whole product configurator stuff
in master, to make it more robust, maybe when converting it to owl?
[1] https://github.com/odoo/odoo/commit/21bcafc053be7f80eed7a684fee2dc1e3caaafa5
opw~2421798
closes odoo/odoo#64552
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
The ControlPanel has been converted in Owl [1], and the code using
it has been adapted accordingly. However, in the FieldX2Many, we
didn't properly wait for the ControlPanel to be updated (an update
of the ControlPanel was synchronous before owl, and is now async,
like every Owl renderings, as it waits for the nextAnimationFrame).
As a consequence, we might have tricky issues because the mounted
hook of the control panel might be called multiple times for a
single call to willUnmount later on. In mobile, we bind a global
event handler (on scroll) in mounted, and unbind it in willUnmount,
so we had leftover event handlers, that crashed when called after
the ControlPanel was destroyed. Note that even if the issue popped
in mobile, calling mounted on already mounted Components isn't a
good idea, and this should be fixed anyway.
The issue could be reproduced for instance in FieldService (with
collaborative pads activated in Project), in mobile, by opening
a task in Edit mode. Then, you might get a traceback by scrolling
after having discarded the edition
Here is a description of what technically happened:
- when clicking on Edit, all widgets (including the FieldX2Many
are destroyed and re-instantiated in 'edit' mode).
- the pad widget directly triggers a field_changed event which
causes a reset of the FieldX2Many (i.e. 'render' is called
again)
- the FieldX2Many detects that it already has a renderer (and a
ControlPanel) so it updates them
- it first updates the renderer, and when it's done, it updates
the ControlPanel BUT doesn't wait for its promise, so the
promise returned by that call to 'render' in FieldX2Many is
resolved before the ControlPanel is actually updated
- note that at this point, all thoses new widgets are not in the
DOM yet
- when all widgets are ready, the renderer patches the view (i.e.
the former content is removed from the DOM, and the new one is
attached into the DOM). As soon as this is done, the renderer
calls 'on_attach_callback' on its children, including the
FieldX2Many, which leads to a call to 'mounted' on the CP.
- then, just before the nextAnimationFrame, Owl complete the
rendering of the CP, and detects that it is now in the DOM (it
wasn't at the beginning), so 'mounted' is called a second time,
will cause the issue described above.
This commit fixes the issue by properly waiting for the CP to be
rendered in the FieldX2Many. However, this required on cascade
changes:
- Form view renderings with a FieldX2Many are now *really* async
(+- 16ms), meaning that the user can easily trigger concurrent
renderings by, e.g. clicking quickly several times on 'Edit',
'Save' or 'Discard'. Concurrent renderings are properly handled
so to prevent this from happening, we disable the buttons and
re-enable them when the rendering is done (like already done in
[2])
- in the FieldX2Many, '_updateControlPanel' was called at several
placed, but we never waited for it. As this method was
originally sync, its calls have probably been naively adapted,
whereas their should have been deeply rethought (for instance,
as it is async, and we need to wait for it, we don't want it
to be called multiple times sequentially when something happens).
This commit does that work, i.e. we clean the places where this
function is called such that it is (hopefully) never called
sequentially twice. To do so, we changed a bit the spec of the
pager in multi page, and we also fixed a paging-related bug.
In a few words, here is what we did/do when adding a new row
in the bottom of a full page:
- before: tweak the count in the data to fool the pager and
make it think that no new record has been added (so
basically, let it display something wrong)
- now: temporarily increase the pager limit so that the new
record is displayed on the current pager, and the pager
values are correct w.r.t. the displayed records.
Some tests needed to be adapted accordingly.
- By waiting for the ControlPanel when updating the FieldX2Many,
a bunch of QUnit tests failed. Those tests have something in
common: they spawn an X2Many (list or kanban theoretically,
but always list in practice) containing a FieldBoolean (only
field widget of /web converted in owl). When the FieldX2Many
is updated, we update the renderer (i.e. re-renderer the
FieldBoolean, so we have to wait for the nextAnimationFrame),
and when this is done, we update the page (again, we have
to wait for the nextAnimationFrame). So basically, we have
to wait for two nextAnimationFrames to see the result in the
DOM. For this, we added a new test util which basically does
a nextTick ('owlCompatibilityNextTick'), and called it
everywhere it was necessary. When everything will be written
in Owl, we could get rid of this util and its calls.
[1] https://github.com/odoo/odoo/commit/fbf347498f1cc7b74ef373179b7bcae201715c24
[2] https://github.com/odoo/odoo/commit/39f08950d6e20460e3a20a5b9c33e4ddf66dce78
closes odoo/odoo#61593
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
|
|
When navigating fields using the keyboard, it's not possible to reach
most of widgets for selection fields. That is because most of them
consist of one main element containing several other ones, one per
possible selectable value (e.g. buttons). When their focusable element
is computed, the main element is taken, instead of its sub-elements,
which causes the field to be skipped when navigating.
This commit fixes the above, as well as some missing aria attributes and
keyboard events, for the following widgets:
- `priority`
- `state_selection`
- `statusbar`
- `radio`
opw-231112
closes #58302
closes odoo/odoo#58418
X-original-commit: 2471e7c176c5df0f310f2939f8a6cf6948c0ac0c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
Task 2327599
It is used in the selector of a tour to know the type of a document.
|
|
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>
|
