| Age | Commit message (Collapse) | Author |
|---|
|
with this commit we disables autofill of autocomplete by setting
autocomplete=off, this was previously done in commit: 64293fbdb0a247f689c1b0b0c580d9ce577af510
but it was not working because we were setting autocomplete=none
it seems that none does not work all the time.
task-2462676
closes odoo/odoo#68271
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
The underscore (_) library has a bug in which the _.each method does not
work with object which contains a "length" property. This is because it
does look for that key and if it is a number, it will assume that it is
an array with that length value. Nicely done...
If that length value is set to 0, then it will just do nothing, since it
thinks that it is dealing with an empty array.
Note that if the value is set to an object, _.each is smart enough to
notice that it cannot be an array, and will do the correct thing in this
case.
Usually, our _.each calls are safe, since we usually iterate on arrays,
or on object with safe keys, or on object with values that cannot be a
number.
But there was 2 unsafe calls in basic_model, which leads to strange
bugs: some code is skipped, and the form view is then confused. The
motivation for this fix is the fact that onchanges are not applied at
all, if there is a length field set to 0.
To fix this, we can just avoid using _.each. Note to every Odoo JS
developers reading this: new Odoo code should avoid using the _ and $
libraries, because we do not really need them, and we want to keep our
dependencies to the strict mininum.
OPW: #2465808
closes odoo/odoo#66126
closes odoo/odoo#67138
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
before this commit: when there is only one page in the notebook tag and
there is a boolean field in form to show/hide that notebook page based on
invisibility attrs, if we toggle boolean field notebook hides, that's OK
but when we toggle boolean field again then notebook page is displayed but
it is not active and due to that content of notebook page is not displayed.
after this commit: when there is only one page in notebook and it has attrs
for invisibilty, when we toggle boolean field to hide/show notebook page
then notebook page as well as content is toggled.
task-2449053
closes odoo/odoo#66338
X-original-commit: a0b5ecd344d6ac79d8e4d194cfabf3d639259c73
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Before this commit, the form renderer would call "on_attach_callback"
only when the whole _render process was over. The problem was that this
process is asynchronous and this callback should be invoked as soon as
the widgets are appended.
As such, any asynchronous operation is performed before appending the
content in a new function "__renderView".
Task 2346540
closes odoo/odoo#60791
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Issue
- Install Sales
- In Sales > Configuration > Settings -> Enable "Sale Warnings"
- Go to Sales > Orders > Customers
- Pick a customer/company
- Go in Edit mode and go to "Internal Notes" tab
- Switch "Warning on the Sales Order" from "No Message" to "Warning" and add any warning message then save
- Press the "$ X Sales" smart button
- Create a new Quotation
- Validate the warning message
- Go back to the previous menu (using the breadcrumb) or save the quotation
- Create a new quotation
The quotation form editor does not appear.
Cause
If we use the breadcrumb (or save then create), it will call the `_reload` function
(instead of `load` when the form view hasn't been opened yet).
In this case, creating a new record, it will call `_makeDefaultRecord` without
setting `allowWarning` param to true (like it is done in the ref. commit bellow).
Solution
Set `allowWarning` param to true before calling `_makeDefaultRecord`.
related commit : https://github.com/odoo/odoo/commit/a41db9a2cf410bb233b021651a5633180eaddf18
opw-2374857
closes odoo/odoo#62534
X-original-commit: 5c8101102f999cfac6aec7658b98e376d4ed0596
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.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>
|
|
And other reported English mistakes in source string
Courtesy of Transifex translators
And remove leftover from gengo
closes odoo/odoo#59002
Related: odoo/enterprise#13776
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
This issue only occurred in community.
Steps to produce:
1) Create/Edit any record.
2) Change the menu using menu switcher
3) You will get the discard dialog at the instance and after some
time it will also display another duplicate discard dialog.
So, we have one extra redundant discard dialog on menu switching.
It is working fine when we have dirty form and then click on the
breadcrumb or click on any internal child menu.
Task : 2312437
closes odoo/odoo#57343
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
Before this commit, when being in a form view without active field
(the field is defined on the model, but not present in the view),
the action "Unarchive" was available in the Actions menu, even
though the record was actually active.
The issue has been introduced by [1]. This commit restores the
previous behavior: when the active field isn't in the view, the
Archive/Unarchive action isn't available in the Actions menu.
[1] 220eb4db391d8ba49dd26bdd3d8af1c27b433d78
closes odoo/odoo#57038
X-original-commit: 97b70aab69b491443d862847fbff69c4e29274af
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
This commit adapts the BasicModel to combine calls to `default_get` and
(first) `onchange`. When creating a new record, we now only call
`onchange`, which thus return default values and potential onchange
values.
Tests (and the MockServer) have been adapted accordingly.
NOTE 1. If the `default_get` within the `onchange` returns a value for
a field that is not in the view, we ignore it, and it won't be saved.
Before, that value was kept and sent upon save. This change in behavior
may prove problematic, although the overall risk is small. Decision has
been made to keep heavy comments and code snippets if we were to revert
back somehow to the previous situation.
NOTE 2. Putting a context on a many2one field may change the value
returned by `name_get` for that field. By default, the calls to
`name_get` are done by `onchange`. If the context on a field must be
used for `name_get`, one has to set the option `always_reload` to `True`
on the field. In that case, every `onchange` that changes the value
will trigger an extra `name_get`.
NOTE 3. Suppose that a one2many field has a list view with field A, and
a form view without field A. When adding a line, we now send all known
fields (main view and inline views) to the `onchange`, which may return
a default value for A. The value will appear on the list view, but not
in the form view. The former behavior was to call `default_get` with
the fields that occur in the form view only, and therefore field A would
be left to value `False`.
NOTE 4. A test surprisingly adds an extra call to `read`. The test was
actually wrong before. With the changes in MockServer, we now correctly
receive a command `[6, false, [1]]`, whereas before we received `[1]`,
which isn't a valid command, and which was ignored. As a consequence,
an extra `read` is done, whereas the test asserts it shouldn't. But it
already didn't work before (I checked by sending the correct command).
This needs to be bugfixed elsewhere (task-id-2323491): in a o2m with a
onchange and default order records on an other page than the first
should not trigger a `read`.
Task 2261084
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
Before this commit: if there are modifiers based on field which hides
one page and show another and if active page get invisible then instead
of first page second page gets focus, consider following example,
`<form>
<field name="boolean"/>
<page name="page1" attrs='{"invisible": [["bar", "=", false]]}'></page>
<page name="page2" attrs='{"invisible": [["bar", "=", true]]}'></page>
<page name="page3"></page>
</form>`
Consider the initial boolean value to be true; initially the first page
will be visible. But when "bar" is unchecked then page1 will be hidden
and page3 will get the focus as page2 is still not visible: it will be
after the computaion/application of all modifiers, which is currently
done after the rendering of a tab page.
Now: the first visible tab is focused on rendering (same as before) but
also after all modifiers have been updated.
closes odoo/odoo#56209
X-original-commit: 10365572aa3629e9b19d2b29726b351275de9f52
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Ipsita Borisagar <ibo@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
|
|
Improve mock server:
- add support for mocked `fetch`
- add support for `active_test`
- add support for x2m `in` in domains
- add support for default values computed from a function
- implement a more natural "next id" compute
- allow initial data without ids
- ensure write and x2m commands integrity
- improve bad data/bad commands error messages
- always warn for failing RPC, not only in debug mode
- fix all existing tests that had inconsistency data
Other changes done in mail (or dependents) that are not just related to tests:
- remove `direct_partner` from formatter result
->`correspondent` can be computed from other keys, especially `members`
- fix `livechat_visitor` convertData
-> only process if there is value
- add `current_partner` and `current_user_id` as `init_messaging` result
-> easier to mock than session
- remove usage of `need_moderation`
-> that was just a search indirection to `moderation_status`
- adapt `partner_id` -> `res_partner_id` key in `_notification_format`
-> to be consistent with field name
- add name in result of `mail_partner_format`
-> sometimes display_name is not the same
- remove usage of `is_moderator`
-> that was just an indirection to `moderation_channel_ids`
Enterprise counterpart: https://github.com/odoo/enterprise/pull/11523
task-2287171
closes odoo/odoo#55854
X-original-commit: 7ba3fecb3377a720d1eb70e7515a0c45da73836d
Related: odoo/enterprise#12391
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
|
|
With this commit, the FormRenderer no longer directly extends
the WidgetAdapterMixin. It doesn't need to as its parent class
(the BasicRenderer) already uses it. Worse, they both called
WidgetAdapterMixin.on_attach_callback, and thus mounted
was called twice on Components in form views.
closes odoo/odoo#55401
X-original-commit: 4c627abd310a131a4828e9ee6be451aeee4708db
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Large form views (containing a lot of fields), e.g. the crm.lead
form view, take a while to render (~ 250 ms). Most form views
contain several (sometimes a lot) invisible fields (invisible="1"),
whose only purpose in the view is to be fetched, so that they can
be used to evalute domains and contexts.
This commit implements a trivial optimization of the form renderer,
which consists in skipping the rendering of those invisible fields.
With this change, we gain ~25% of rendering time on the crm.lead
form view.
closes odoo/odoo#54368
Related: odoo/enterprise#11875
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
|
|
Before this commit, when the same field occurred multiple times in
a form view, all occurrences were associated with the same id, and
all occurrences of the corresponding label (if any) had the same
'for' attribute. As a consequence, besides the fact that there were
warnings in the chrome console, clicking on any occurrence of the
duplicated label focuses the first occurrence of the field.
This commit generates a unique id for each pair label/field, when
possible. However, there is a case that can't be handled
automatically: when the label isn't automatically generated (field
located outside a group, or with nolabel attribute set to "1").
Typically, in this case, there is a <label> node with "for"
attribute referencing the associated field. In this situation, the
id must be defined in the arch, and used in the "for" attribute:
<form>
<label for="phone"/><field name="phone"/>
<label for="phone_2"/><field name="phone" id="phone_2"/>
</form>
Task 2261697
|
|
The on_attach_callback methods on the widgets (comming from a tag
'widget') of a form renderer were not called at an appropriate time.
They were not called at all or called before the widgets were actually
in the dom. This was made manifest in the dashboards that generally use
pie charts widgets. Each time a pie chart widget is renderered,
a new canvas with a unique id is created. The above mentioned problem
explains why Chart.js was not able to acquire the canvas contexts: they
are obtained by looking for a specific id in the dom.
The present commit fixes that problem by doing in the class FormRenderer
what was already done correctly in the child class DashboardRenderer and
remove the unapropriate calls to on_attach_callback in _renderWidget.
Task ID: 2278717
closes odoo/odoo#53853
X-original-commit: 7641c7074616b4375f1eb4f1fcb5a96e2ed39f94
Related: odoo/enterprise#11537
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Before this commit, when archiving a record through the action
menu, the 'Archive' link was not updated to 'Unarchive' and same
when unarchive was clicked, the link was not updated to 'Archive'.
After this commit, when archiving a record through the action menu,
the 'Archive' link is updated to 'Unarchive', same way when
unarchiving a record link is updated to 'Archive'.
This commit also introduces a new prop 'closeOnSelected' to the
Dropdown component, to specify whether the dropdown should be
closed when an item is selected, and makes Action Menu dropdown
closed on item selected.
task-2251739
closes odoo/odoo#53835
X-original-commit: dc5d02ade7747c74c31566c74932ef45c30e9356
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
|
|
On a re-render, when:
- a field is not yet started (still in willStart because of RPC)
- then an action is executed
we can get a traceback because we try to save the field before it is
started and `this.el` is not set.
eg. in MRP on a work order:
- click on + to get new serial number
=> page is re-rendered with RPC call to update duration to
mrp.workcenter.productivity().search_read to update time
counter
- click on "Record production" before RPC is finished
=> traceback because we try to save `duration` that is not already
started (`this.$el.toggleClass` when `this.$el` is `undefined`)
Without change, added test fails with:
"Cannot read property 'toggleClass' of undefined"
in BasicRenderer.canBeSaved
"Expected 6 assertions, but 5 were run"
Before saas-11.3 5faec34a3c this.el was always set in `init` so this
issue did not happen.
opw-2272117
closes #53532
closes odoo/odoo#53612
X-original-commit: befcad51fd236fdaf284f76cea5624d21c070b0e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
This commit adapts tests following recent changes on the helpers.
The main change is that addMockEnvironment (and all functions using
it) are now async, as they need to wait for services to be started.
|
|
closes odoo/odoo#52826
Related: odoo/enterprise#11084
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
PURPOSE
The purpose of this task is to improve the interface by removing the
fa-building icon which is automatically appended by the property field
(i.e. company-dependent) and, instead, indicates that a field has
company-specific values in the tooltip of the field.
closes odoo/odoo#52313
Taskid: 2266519
Signed-off-by: Aaron Bohy (aab) <aab@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>
|
|
before this commit,
tabbing into the date or datetime field input it has only focus, value is not
selected.
after this commit,
navigate through a view in edit mode with the TAB key, when focus comes into
date/dateetime field input then input is focused and value of date/datetime
field is also get selected.
task-2246593
closes odoo/odoo#51062
X-original-commit: 962e4e18b559d90aa3456c77035659ac8017501d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
|
|
... when there is no data and user clicks anywhere in the no content
helper.
Task 2239617
Co-authored-by: Jinal Patel <jip@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
Before this commit, when re-activating a previously active notebook tab, the form
renderer would assume that a tab was actually active. However this does not happen
if no tab is visible or defined and it results in a crash instead.
Now, if no active tab is found, a default active tab (0 = first) is set. This only
helps to prevent the crash and does not affect the current behaviour.
closes odoo/odoo#50006
X-original-commit: 73e0c0a1395ebd0e2b4ac7f857c863a0358c5e17
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
|
|
In a form view, nodes with classname "oe_read_only" (resp.
"oe_edit_only") are only visible in readonly (resp. edit) mode.
Moreover, fields inside a group automatically have an associated
label.
Before this commit, when one of these classnames was set on a
field node inside a group, the effect wasn't applied on its label,
so the label was always visible, even if the field was hidden.
Bug reported in PR odoo/odoo#48699
closes odoo/odoo#48968
X-original-commit: 705f434f0f18a0e4d2fdb0f86d3e350d190b2a30
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
* account
This commit adds a new field registry for component fields.
This field registry is used to only register the new field components
and the other one should register the legacy fields.
Those two registries will be used together while all legacy fields are
not converted to owl component.
As the legacy registry now throws an error when adding a component
field the existing component fields (account.ShowGroupedList and
account.ShowResequenceRenderer) are moved into the new registry.
This commit also refactors some field managers (form renderer, list
editable renderer, calendar popover) to use the new registry and thus
support the component fields.
task id: 2193996
|
|
Purpose Of the task is, we need a visual cue on those fields to let
the user know that their value is company-specific.
So, in this commit On company depedent field we added a building
icon with title 'Values set here are company-specific' next to the
label in the form view.
closes odoo/odoo#47178
Taskid: 2001748
Closes: #47178
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
Use of the new control panel helpers to increase consistency and change the assertions
according to the new DOM/behaviour (e.g. components removed instead of turning invisible).
Part of task 2196029
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
|
|
This commit allows to pass a bin_size context to False.
Before this commit it wasn't possible because it was
always overriden.
OPW-2208232
closes odoo/odoo#47491
X-original-commit: 17d53cea1043054dfa9c39b16b430539c4082a9d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
|
|
How to reproduce
================
You must have
- a form view with a one2many list
- in this one2many list add a column of a reference field
How to reproduce
1. open the record associated to the reference field
2. edit this record in the form modal view
3. click on save
-> Traceback
Bug
===
In `basic_model` the attribute `localData` become inconsistent
because of the method `_fetchReferenceData`.
We want to store the ID of the parent and not the all dict.
closes odoo/odoo#47171
X-original-commit: af411b866aa2052c01168342f8f05ae3dabad83e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Currently when the company is created or updated the whole
web-client is reloaded
so write a qunit test case when a company is created or when
the data is written to the company for the web-client reload.
closes odoo/odoo#44714
Taskid: 2188789
Closes: #44714
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
The translation alert dialog was attached to the entire view in case no
status bar was found. This resulted in the following layout on large
screens:
chrome
--------------------------------------
| alert dialog | form view | chatter |
| | | |
--------------------------------------
Whereas when a status bar was set on the form view, the rendering was as
follow:
chrome
--------------------------------------
| status bar | chatter |
| alert dialog | |
| form view | |
--------------------------------------
The fix make sure the alert dialog is always placed just above the form
view just like when there is a status bar.
closes odoo/odoo#44878
Task: 2075172
X-original-commit: dacdc30681510e9c2db23610c5be5285a72a8949
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
|
|
If we have a many2many_tags widget that is writable then becomes
readonly, we can have in the code this chain of event:
- get list of widgets we need to reset some data for
- apply modifiers
- reset the widgets
but applying modifiers can delete a widget (eg. an editable field that
becomes readonly), so when resetting we could call code on a deleted
widget which caused an error.
For example, if we have an attribute:
`<field widget="many2many_tags" attrs="{'readonly': 'condition'}"/>`
if the field goes from editable to readonly and is affected by an
onchange, we will call `setIDForLabel` on the deleted instance of the
widget which will cause an error.
Added test without fix fails with error:
TypeError: Cannot read property 'attr' of undefined
at Class.setIDForLabel (/web/static/src/js/fields/abstract_field.js:324:35)
because as said, the function is called on the editable widget that is
removed and replaced with readonly widget at that point.
opw-2154471
closes #43137
closes odoo/odoo#43244
X-original-commit: 6f5ca16524be7c5bb45b03e7421154a20edc4cf6
Signed-off-by: Nicolas Lempereur (nle) <nle@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>
|
|
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>
|
|
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
|
|
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
|
|
We don't want the browser to fill inputs in the backend.
Most of the time this is useless but sometimes it is
even problematic. For example, focusing an input in a
modal can trigger autofill not only in the modal but
also in the whole page. If there is an input outside
the modal and it is recognized by the browser as a
candidate to fill, bad things occur.
For that reason, we set the attribute autocomplete to
"none" by default for input elements.
Note that "off" does not work all the time because
the browsers sometimes decide to ignore it.
Task ID: 2076730
closes odoo/odoo#38039
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
|
|
closes odoo/odoo#36721
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
Before this commit, translations were edited in a list view with a filter
on the field that needed to be translated.
After this commit, the translations for each fields are translated in a
dedicated dialog. The changes done to the current language are taken
into account immediately, both ways, from the dialog to the form and
from the form to the dialog.
Translating terms is also available in create mode, the user will be
prompted to save before editing a translation
Task ID: 2028152
closes odoo/odoo#36185
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
|
|
closes odoo/odoo#36491
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
|
|
... and switching to 'edit' mode before the write RPC returns.
For instance, on a project task form view, in readonly, change the
state by clicking on the bullet, and directly switch to 'edit'
mode: when the RPC returns, the view is switched back in readonly.
Task 2065443
closes odoo/odoo#36400
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
|
|
|
|
Let's assume an action with 'create': 0 in the context, and a non
inline subview in the form view. Before this rev., the 'create': 0
was applied to both the form view and the subview.
This rev. applies the same logic as what the server does for inline
subviews: the rule is applied to the subview iff its model is the
same as the one of the form view (with key 'base_model_name' set
in the context).
Task 2035653
closes odoo/odoo#36109
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
Back-ported from the master,
commit ca9a733b27a1680403961eaa13cc62e5aa58a8fb
Before this rev., classNames 'oe_read_only' (only display in
readonly mode) and 'oe_edit_only' (only display in edit mode)
didn't work in x2m lists inside form views (only the cells in the
tbody were hidden, but not the header). This rev. makes this work.
Task 1949618
closes odoo/odoo#36117
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
closes odoo/odoo#36285
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
When we have an onchange that modify items in One2many's lines (for
example the quantity of each line based on general quantity) and
we click on a record immediately after changing the field that
trigger the onchange, we have the the old value in the dialog box.
Indeed the dialog opens before the onchange has return the new
values, so the old one are used. This case appears only if the
One2many's line was never saved.
With this fix, we wait that the model is free of mutex, and so the
onchange is terminated before displaying it.
closes odoo/odoo#35306
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
|
|
|
|
Since the renderer does not know the view id, we moved the local
storage key computation up to the basic controller, which makes
more sense since the renderer is supposed to be inert.
The _processColumns function had to be moved in willStart however,
since it now needs the controller to respond to the trigger_up
and the controller is not present during the init of the renderer.
closes odoo/odoo#34051
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
|
