| Age | Commit message (Collapse) | Author |
|---|
|
When using the "Send & Print" functionality, if the user adds an
attachment, the latter won't be linked to the record.
To reproduce the error:
1. Open a posted invoice
2. Send & Print
3. Attach a file > Select a file on your device
4. Send the email
Error: The invoice's PDF is added to record's attachments, but not the
other file (from step 3).
When the module selects the attachments that need to be linked to the
invoice, it only keeps the ones currently linked to `mail.compose.message`:
https://github.com/odoo/odoo/blob/6441ab71cb68648aa735057952bf757677a20ee3/addons/mail/models/mail_thread.py#L1719-L1725
This is correct when the user creates a message directly in the chatter.
However, when the mail is created thanks to `Send & Print` functionality,
the attachment is linked to `account.invoice.send`.
Another flow have a similar issue: from invoices list, select few ones,
Action > Send & Print: the generated PDF won't be attached to their
invoice. In such a situation, here is the source of the problem:
https://github.com/odoo/odoo/blob/05ad6c477f7da2a495e5baf5b4629323b9d11fa0/addons/mail/wizard/mail_compose_message.py#L363-L367
There isn't any information about the invoice, therefore it is not
possible to linked the attachment to it.
OPW-2438457
closes odoo/odoo#71425
X-original-commit: e87f599d4eb22250b628d650b9f59b54db8d043c
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
|
|
closes odoo/odoo#70936
Taskid: 2412172
Related: odoo/enterprise#18366
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
- `parseDateTime` util: we now caches "without zero" date and time formats
Taskid: 2412172
|
|
|
|
Infinite number of records cannot be exported, so after some limit we will get a
timeout error. If you need to export more records than that limit, you should be
able to filter records into batches. The easiest way to do it is making a
filter by ID:
```
[Y| ID Greater than 100000] [Y| ID less than or equal to 200000]
```
---
opw-2517946
closes odoo/odoo#71345
X-original-commit: 2e0127af0d283d1d9bdb033de356e2ddf0973cce
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
|
|
Steps to reproduce the bug:
- Install Accounting
- Connect with a user who has a default company (e.g: Company A) and allowed companies (e.g: “Company A” and “Company B”)
- Choose in the company selector “Company B”
- Make sure that the onboarding panel in the default company has not been closed
- Go to accounting and close the onboarding panel
- Refresh the page
Problem:
The onboarding panel is still open because in the `account/account_dashboard_onboarding` method we check the`account_dashboard_onboarding_state` field of the default company instead of the current company because "allowed_company_ids" is not in the context
This problem is also present in all the other views where an onboarding panel is present
Solution:
Add the context in the parameters of the rpc in the _renderBanner
opw-2477148
closes odoo/odoo#71384
X-original-commit: 902950541f8c361e03821314aab4bf4f304ac37d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
|
|
|
|
Before, the "Company name" placeholder was hardcoded in the frontend
layout template, and the user had to change it with his company name
from the website view, which was not user-friendly if the website module
was not installed.
Now, by default, the frontend layout template displays the user's
company name. If the website module is installed, it is editable.
task-2468472
closes odoo/odoo#69943
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
|
|
This is a forward-port of commit https://github.com/odoo/odoo/commit/970387f91fea0cb47404612f7d519ffba2c9ad3b
In editable list view, moving to next cell using TAB key crash when the
following field is becoming 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" attrs="{'readonly': [('description', '!=', False)]}"/>
<field name="type"/>
</tree>
</field>
</form>
1. Edit 'description'
2. Issue a TAB keypress before 'date' becomes read-only
It will crash while calling getSelectionRange() on an empty element.
opw-2523630
closes odoo/odoo#71122
X-original-commit: bd6ba50e073ffff0bd51b1a02d51260f09e36357
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
|
|
This commit updates owl to the latest release. It only contains a small
fix to the router (route params handling)
Release on github: https://github.com/odoo/owl/releases/tag/v1.2.6
closes odoo/odoo#71023
Signed-off-by: Samuel Degueldre <sdegueldre@users.noreply.github.com>
|
|
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>
|
|
This commit update owl to the latest release. It only contains a small
fix on the order of lookup for the t-component directive.
Release on github: https://github.com/odoo/owl/releases/tag/v1.2.5
closes odoo/odoo#70935
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Before this commit, evaluating a domain containing a like/ilike
operator with an evaluation context in which the value was false
crashed.
Moreover, those operators were wrong w.r.t. the case sensitivity:
like was case insensitive, whereas ilike was case sensitive, and
both =like and =ilike were case insensitive.
This commit fixes thoses issues.
The first issue was spotted on our prod, as we tried to add an
invisible attrs in a form view, using the ilike operator (it thus
crashed in create mode).
The second issue was spotted while writting the test cases.
To the best of our knowledge, those operators aren't used in attrs
(for now), explaining why those issues haven't been found before.
closes odoo/odoo#70876
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
the documentation in 12.0+, the majority of the documents have been moved and their old links are no longer valid. Some redirection rules will soon be deployed, but those rules might be dropped in some years and we want the links to still work, which is why we still replace the links to the new ones.
FW-Port of odoo/odoo#70675 (13.0)
closes odoo/odoo#70728
X-original-commit: 85c24961ab9ff5c1c79eb7415c97c46d9a77cca3
Related: odoo/enterprise#18283
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
|
|
When using the boxed layout, if the business document has a table, its
first row (after the table head) will have a bottom border and the last
cell in the row has a white background.
To reproduce the error:
(Need timesheet_grid. Use demo data)
1. In Settings > General Settings, Change Document Template:
- Select the second template
2. In Timesheets, select list view
3. Select several lines
4. Print > Timesheet Entries
Error: In PDF, the first timesheet line has a bottom line and its last
cell has a white background (instead of grey).
The bottom line should only be applied on row in table header. The
background color should also be applied on first row in table body.
OPW-2478311
closes odoo/odoo#70746
X-original-commit: 88a10bdd8f1d46a8b52be59fe3284cbe284a74f2
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
|
|
|
|
What are the steps to reproduce your issue ?
1. From the product form, go to the website version, edit it to add tabs
2. Using studio, add the field "Description for website" to a tab of the notebook
3. Save, click Edit, go to the tab that has the field
What is currently happening ?
Traceback:
form_renderer.js:258 Uncaught (in promise) TypeError: Cannot read property 'querySelector' of undefined
at Class.setLocalState (form_renderer.js:258)
at Class.setLocalState (form_editor.js:131)
at Class.prototype.<computed> [as setLocalState] (class.js:90)
at view_editor_manager.js:184
What are you expecting to happen ?
Correctly add product description without tracebacks
Why is this happening ?
Because the number of tab is not equal to the number of pages
How to fix the bug ?
Before accessing the element, check if it exists
opw-2378743
closes odoo/odoo#70513
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
|
|
(groupby:week)
* IMPACTED VERSIONS
12.0+
* HOW TO REPRODUCE
locale : Locale is en_US (or other SUNDAY based)
view: CRM - My Pipeline - Kanban view
groupBy: date_deadline:week (Expected closing)
records: one record with a planned activity, on date_deadline = 2021-05-02 (SUNDAY)
one record with no planned activity, on date_deadline = 2021-05-09 (SUNDAY)
remark: don't keep any other record in MAY for better visibility
* PROBLEM
The progressbar of the week containing 2021-05-09 displays information about the record
from the week containing 2021-05-02
* CAUSE
1. PostgreSQL `date_trunc` function follows ISO8601 which essentially means that
the start of a WEEK is always MONDAY. There is no argument to change this.
2. _read_group_format_result
https://github.com/odoo/odoo/blob/27da86a138089c1838e4b94f8a6976995b9c1fff/odoo/models.py#L2210-L2219
- Computes a label for a group of records.
- Follows the locale for the label of the week, based on a date which is
always a MONDAY because of `date_trunc`.
3. read_progress_bar
https://github.com/odoo/odoo/blob/88957afca09662af7eaa19df1e40b3699e45e79e/addons/web/models/models.py#L167-L175
- Associates a group label to a record.
- Follows the locale for the label of the week, based on the date of a record
which can be any day of the week. If the record is related to a SUNDAY and
SUNDAY is the first day of the week, it would have been in a group with a
different label in (2.) than in (3.) prior to this change.
* FIX
In 3., before associating a label to a record, we truncate the date to the
ISO start of the period, so that the label is determined for a record in the
same conditions than in 2. The locale is still used to get language-dependent
outputs with babel, but the grouping will always follows ISO8601 (date_trunc).
* TEST
Added a test for this problem case
TASK-ID : 2517848
closes odoo/odoo#70453
X-original-commit: c08f6e3e9a084944ea711d33b2421f845c560d3f
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
Some aria attributes were missing or incorrectly set on these new
buttons:
- The button "Export All" was missing an `aria-label` attribute
- The button to show/hide optional columns was also missing an
`aria-label` attribute, and its menu items (checkboxes to show/hide
columns) were missing a proper role
- Ever since the debug manager was added in frontend on 73327db0656b,
the `aria-label` attribute was not being rendered correctly on the
button to open developer tools
closes odoo/odoo#70390
X-original-commit: 620e4cc28cefed6f4a3b5ca89b11cc37222acfaf
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
In eg. 13.0 when refreshing sales analysis action of a product, we would
get an error because we have a single active_ids which is not expected
by the code.
With this commit, we use .toString() on the jQuery BBQ parsed active_ids
as it was done before 32b8cec5 refactoring (january 2018).
The added test with the fix fails with an error:
TypeError: state.active_ids.split is not a function
at Class.loadState (/web/static/src/js/chrome/action_manager_act_window.js)
opw-2471982
closes odoo/odoo#70279
X-original-commit: bf9a985f4b62cc6f1eef4f9fcca2a8dfbd453004
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: pvh-odoo <SwagSamaSempai@users.noreply.github.com>
Co-authored-by: Nicolas Lempereur <nle@odoo.com>
|
|
|
|
Some features of the PDF.js library doesn't work in the
webview of the mobile apps.
Initially 'window.print' is defined as an empty function in
webviews unlike browsers where it is already ready.
After that, PDF.js needs to monkey patch 'window.print' and
saves a reference to the original definition, which is not
yet fulfilled in by the mobile app (Java part).
So the print of PDF.js doesn't work in webviews and end
users will need to download the file before printing it.
Regarding the Download button, the 'download' attribute is
not supported by the webview as you can see in:
https://bugs.chromium.org/p/chromium/issues/detail?id=432414
As there's many ways to download a file in Odoo it's not
a big deal to simply hide it in PDF.js.
Because it's quite complicated to fix this, we decided
to hide the features that don't work (Download / Print)
or don't make sense (Open file).
Note that a refactoring is already in progress in order to
avoid to patch this library in master.
closes odoo/odoo#70092
Task-id: 2200168
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
|
|
`_(xyz)` will wrap them in an underscore.js object, which when used in
a string context will just return the string. So it's basically a
no-op, but it certainly doesn't translate the terms.
closes odoo/odoo#70000
Related: odoo/enterprise#18001
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
|
|
The changed test uses the drag&drop helper, and an operation does
not work as expected with the given params on chrome 90. The runbot
currently uses chrome 80, so it is not an issue, but if your chrome
is up-to-date, and you try to run the test suite, this test would
fail.
closes odoo/odoo#70008
X-original-commit: 43994da9980e4133274984f720bb58f3546ea0f9
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
This mostly an issue when trying to run just the tests of `web` (aka
`-iweb`) with only community modules available,
`TestMenusDemoLight.test_01_click_apps_menus_as_demo`, wait for the
ready code times out:
AssertionError: False is not true : The ready "odoo.isReady === true" code was always falsy
and the test suite fails.
The ready code simply checks that `odoo.isReady` is set. The web
client sets `isReady` when `webclient_started` is
triggered (specifically in `_onWebClientStarted`, which is the handler
for that event).
[The community web client only triggers `webclient_started` at the end
of `doAction`][0] meaning the community client is considered ready
until after the first action has executed.
[The first action is executed by `show_application`][1] whose process
is the following:
1. load and initialize the menus
2. if an action is specified in the URL, run that
3. otherwise if the user has a home action, run that
4. otherwise run the first menu's action
When installing only `web`, the only menus which could be available
are Apps and Settings, and the demo user has access to neither. This
means the demo user has no applications, and opening the first app is
a no-op ([`openFirstApp` has a case just for that situation to ensure
it does nothing][2]). As a result, `webclient_started` is never
triggered, `_onWebClientStarted` is never called, `odoo.isReady` is
never set, and the tour never runs.
Fix by updating `openFirstApp` to return *whether* it opened an
application, and in `show_application` the last fallback if even
opening the first application failed is to just declare the web client
ready.
While at it, rewrite `show_application` using ES6 facilities and
flatten and linearize it using guards. This means the code pretty much
tracks the process described above, with one step added:
5. otherwise complete the webclient's startup
[0]: https://github.com/odoo/odoo/blob/1eb474243b55f1b9e10c70d199bbe022e68b51d0/addons/web/static/src/js/chrome/action_manager.js#L174
[1]: https://github.com/odoo/odoo/blob/d1c56ec7c435c5baba8604feccc6116e4c25ca96/addons/web/static/src/js/chrome/web_client.js#L77-L107
[2]: https://github.com/odoo/odoo/blob/e24ab17d38fb049404f04112990e8b2fe1dd7727/addons/web/static/src/js/chrome/apps_menu.js#L44-L46
closes odoo/odoo#69962
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
|
|
|
|
In mass mailing edition, in some configuration of:
- being in a modal or not
- size of window
- zoom level
we might get an error when getting the scrolling element.
For example when editing a mass mailing, if I set my viewport to 595
pixels height and have a 90% zoom, the editor is broken.
This is because in SnippetsMenu.starts `$().getScrollingElement()`
doesn't find an element that has the height of body. In my use case body
height is 329.111 pixels, and scroll height is 328 pixels.
Testing different zoom level and viewport height, the maximum difference
I was able to get was 1.25 so this commit increase to 1.5 the maxmimum
difference.
opw-2455727
opw-2469174
closes odoo/odoo#69592
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
Before this commit, `getTZOffset` and `user_has_group` weren't
correctly reset to their initial values after tests. As a
consequence tests executed afterwards might behave unexpectedly.
closes odoo/odoo#69485
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
|
|
When loading translations from Session, if no lang is defined in context or html,
it is loading translations of en_US lang by default.
No default should be used to fallback on the language of the current user.
opw-2501708
closes odoo/odoo#69318
X-original-commit: a93a0a33c7447505403097c7ba0707d55d252e64
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
|
|
Commit [1] recently fixed an issue with nested x2many fields and
onchanges: in some cases, all field values weren't sent to the
server as they should.
However, there is a small issue with this fix. We didn't correctly
apply the default value to option `changesOnly`: when not given,
it was considered false, whereas in this particular function it
should have been true.
It caused an issue in the following scenario:
Have a form view with an x2many field (say A) displayed as a list.
In the list, there is another x2many field (say B), and (whatever
its type) a field C with an onchange. When the user changes C, the
onchange is performed, and we send to the server the value of all
fields. In particular, in the row, we send the value for the
many2one field pointing to the main record (the inverse field of
the x2many relation). The value for that field is basically the
whole record, containing itself field A. For field A, the value is
a list of commands, and for the updated record, it is a command 1.
Before this commit, in the values sent for this command, field B
was the empty array, even if it wasn't empty.
This issue was reproducible in account.move, on an existing record
having already a line in invoice_line_ids (this is field A). In
that line, tax_ids (this is field B) must have a tax which is
included in the price. When changing the quantity of the product,
the subtotal wasn't correctly computed.
[1] https://github.com/odoo/odoo/commit/a8b43d02066b2299ac2f4b88056c37725e9ce6cd
opw~2489755
closes odoo/odoo#69167
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
|
|
|
|
This should hopefully fix the race condition that is described in the related
task. The issue is that our mounted callbacks are legitimately relying on the
component to be actually rendered.
task-2481713
closes odoo/odoo#68711
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
|
|
|
|
One might design a custom field widget to display/interact with a
one2many field. Before this commit, if this field widget triggered
a field_changed event to update a related record, it crashed,
because the code assumed that there was a view associated with the
field.
Closes #68276
opw~2468238
closes odoo/odoo#68294
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
- Create a product with:
Cost: 60.80
Quantity On Hand: 999.0
- Go to Inventory / Reporting / Inventory Valuation
- Click on export all (little button next to "Inventory at date")
The field "Total value" have too many decimals: 60739.2000000004
This occur because of the multiplication: it yield the correct value
(60739.2), but every rounding attempt done, even in the ORM, will
mess up the representation
https://github.com/odoo/odoo/blob/042298f8c949fba470eda6ad90f94c95ca291030/odoo/fields.py#L1333
opw-2438384
closes odoo/odoo#67543
X-original-commit: 67cf82962688360cfe25c6b2118a7dbd17a6ee95
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
|
|
|
|
Open Calendar weekly view
Scroll the weeks
The 'Responsible' filter will accumulate entries from the events and not
deleting them.
This create issue with the view in db with heavy calendar use and a lot
of responsibles
This reverts commit 64d0fe411840fb43c96f0252a7ff5e74bd7cdc90, coming from
task 2146842, addressing the following issue in calendar view (i.e. in planning
app) not reproducible anymore
"
In calendar view, when you unselect all filters of a category, all
events disappear (it's expected), but all filters also disappear.
So you can't selectd anything, you must reload the view to unlock
the situation.
"
opw-2479920
closes odoo/odoo#67710
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
closes odoo/odoo#68085
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
|
|
Issue
- Install "Accounting"
- Change user language to arabic
- Go to Customer Invoices list view
- Try to filter on field "Created On"
Traceback is raised from the DatePicker Component
Cause
The cause is two fold:
There is an issue in moment that behaves abnormally when its internals
are not able to extract the month in a locale, and, instead of returning an
invalid moment, it returns a valid moment with the month set to January
which just happens to be the first month of moment's default locale
ref: https://github.com/moment/moment/issues/5600
Secondly, the defaultProps "locale" of the DatePicker was set to moment.locale()
at the file's initial loading, that is, before any user locale parameters were loaded
The bootstrap datepicker was then set with the wrong locale, and the case fell under moment's issue
After this commit, the locale of the DatePicker is always the one of the user, and there is no traceback
opw-2460156
closes odoo/odoo#67320
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
|
|
To find the main element which scrolls in the page, we rely on its
height being as tall as the body one. The code which checks that was
making a comparison between a rounded value and floating value without
care of the rounding errors that might induce, especially on zoomed
pages.
Fixes https://github.com/odoo/odoo/issues/63306
closes odoo/odoo#67961
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
Issue
- Install "Sales"
- Switch to "German" language
- Go to Sales -> Products -> Products
- Try to filter on "Public Price" is equal to "2,3"
Not possible to add decimal point at the end (only in middle of number).
Cause
In case the 'decimal point' in DB params is not a dot '.',
the filter input will be considered as 'text' instead of
'number'.
In case of the 'number' type; HTML do already a pre and post
processing, including managing decimal point (who, for example,
is not included in ev.target.value if last char is a '.').
Unfortunalty, the library is not well working with other
language and not supported on every browser, therefore,
must use own logic.
In case of a 'text' type, the value will be send to 'parseFloat'
,then `parseNumber` will replace decimal_point by dot (also one the
issues since needed to display decimal_point according user language),
and `Number` will remove the decimal_point in case of '123,' -> '123',
and therefore we will not be able to write decimals ( apart of adding
the decimal point after writing the whole number...)
Solution
If user input is well parsed, store parsed value in condition.value and
set condition.displayedValue to the input value (an so without updating
input value). Else, replace input value with previous value (who should
be the condition.DisplayedValue).
opw-2463441
closes odoo/odoo#67767
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
|
|
Without this commit, all tests executed after that one would use
the patched version of the FormViewDialog.
Issue spotted in the assets revamp branch, by moving form_tests.js
after calendar_tests.js
closes odoo/odoo#67865
X-original-commit: ff19ee8d8b39a719a09dd9f6060faa3afa474da3
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
*: web
task-2276974
closes odoo/odoo#66049
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
|
|
The left css property computation wasn't usefull for ltr mode and
even worse, it introduced a bug when a horizontal bar was present
(as often on mobile).
The entire width of the table was used to compute the offset even
though we only saw part of it (scroll bar). It's why this left css
property was too high.
We can simply remove this logic as "right: 0" on .o_optional_columns
already do the job for the ltr mode.
Note that we still need to compute the left property for the rtl mode
to put the dropdown menu above the table. Otherwise it will be on his left!
Steps to reproduce:
- Go to Subscription
- Open an existing record
- Try to open subscription lines column dropdown
=> You need to scroll on the right to see it.
Related PR: https://github.com/odoo/odoo/pull/62472
Related Task ID: 1929043
closes odoo/odoo#67738
X-original-commit: 87c6f6338d267acaab90705f9d5ca8ad27ae30fd
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
|
|
These are throttled/debounced so the handlers are sometimes called after the
component has been destroyed.
opw-2451752
closes odoo/odoo#67723
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Let's assume the following situation. We have a form view with a
one2many field A displayed as a list. In the list, there is a
one2many field B. B can't be edited, its value is computed by
an onchange. By default, it contains a single record (i.e. the
first value returned by the onchange is [[5], [0, 0, {...}]]).
When another field (say C) changes, B's value is re-computed to
[[5]]. Moreover, there is an onchange on A.
In this form view, let's assume the following scenario. Create a
new record and add a line to A. In this new line, B already
contains a record. Change C. This triggers an onchange that
returns [[5]], and B is now empty. It triggers a second onchange,
on the main record (as field A changed).
Before this commit, in this second onchange, B's value wasn't sent
among the other values of the new line.
The spec says that for onchanges, we must send all data, not only
what has really changed. From that perspective, the above scenario
highlights an issue.
That issue had two root causes. First, commit [1] wrongly fixed
another issue, and as a consequence, when building what to send
for the onchange, we didn't generate the values for fields that
hadn't changed inside an x2many (for added subrecords at least).
This commit reverts the fix of [1], and fixes it differently by
only sending a command 1 (update) after a command 4 (link to)
when the record is dirty (i.e. when it has been modified). See
[1] for context and details.
Second, the code that generates the values to send to onchanges is
the same as the one that generates the values to save records
(write or create). However, when saving, we only send what has
really changed. The values are at some point processed to remove
empty command lists from the list of changes (as it means that
nothing changed). However, here we ignored the flag that stated
whether we want all field values or just what has changed. This
commit takes the flag into account before removing the field's
value.
[1] https://github.com/odoo/odoo/commit/3e3a244e1afc4d74920a6302a14fa2590e8b6648
Issue reported in task~2352524
Model: account.move
One2Many (A): account.move.lines
Nested computed One2Many (B): tax_detail_ids
Field triggering the onchange (C): tax_ids
closes odoo/odoo#67679
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
|
