**Issue:**
When a copy clipboard field is empty, there is no way to edit it
because the Field component is not shown.
This issue can be reproduced using any type of copy clipboard field:
- CopyClipboardChar
- CopyClipboardText
- CopyClipboardURL
Check the following video for illustration:
https://youtu.be/CTzqJRtwqv0
**Solution:**
This PR proposes a fix of *always* showing the copy clipboard field
(together with the copy button) even if the content is empty.
For illustration, check: https://youtu.be/jMM7zn_mFCU
**Notable changes:**
- The modified tests were using a wrong class name. But since they were
asserting the "non-existence" of the copy button, they were working.
- We are casting null text field to empty string (just like char field)
so that we avoid crash (in dev mode) when passing a "boolean" as 'content'
props to the 'CopyButton' component. This is asserted in the augmented
test case where we also try to render an empty text field.
closesodoo/odoo#104248
Task-id: 2861388
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Even if a many2many field is forcely set to be sortable, it should
not be included in the list of custom groupby options if it's
an un-stored field.
closesodoo/odoo#104978
X-original-commit: 9ba52387481bb0720c5d4f5d8a86c3ad6e801137
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
**Issue:** The aggregate row of the list renderer doesn't take into
account the fields with zero values. As a result, average values are
not correctly computed. E.g. average of [2, 0] => 2 instead of 1.
**Solution:** Make sure 0s are included in the valid values to
aggregate.
**Change note:** We took the opportunity to make a simple refactor
in the affected test. Instead of asserting contents of the row
with multiple strictEquals (one per cell), we use deepEqual to
check the cells in the aggregate row.
closesodoo/odoo#104968
X-original-commit: 2dcb71aab911a47d8d3a5db6f68a28d1c6d8c9fb
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Steps:
- Open studio in any form view
- Add Binary Field
- Close Studio
- Upload a file in the previously added binary field
- We can't download it because of always edit
This commit adds a new download button near edit and clear button
opw-3028094
closesodoo/odoo#104961
X-original-commit: 73a2329b8bf4e887890cae7669bc568ae0be7147
Signed-off-by: Luca Vitali <luvi@odoo.com>
Custom grouping by m2m field is introduced here: https://github.com/odoo/odoo/pull/74985.
However, after refactoring in https://github.com/odoo/odoo/pull/73311,
users are unable to add custom groups based on stored m2m fields.
This is because the stored m2m fields are not included in the list of
"Add Custom Group" options.
In this commit, we are now again including the stored m2m in the options
for "Add Custom Group".
closesodoo/odoo#104873
Task-id: 3046183
X-original-commit: 5087d9011be7f46a4a3e05b1e951f2556f254b4c
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit, accessing parent in a button context broke the button
throwing `EvaluationError: Name 'parent' is not defined`.
to fix,the proxy object `params.evalContext` was passed to `evaluateExpr`
similar to examples seen in `list_renderer.js`
closesodoo/odoo#102293
X-original-commit: 90afb529969ce7de83a20060f5c35a64ce4cf971
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Ahmed Khalaf <ahkh@odoo.com>
The Race concurrency promise never settles if the first settled promise
rejects and therefore you can't catch the rejected promise.
closesodoo/odoo#104733
X-original-commit: 24cc8cdb440a5af944d82a25d98b0239e72e2625
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
As in odoo#97378, the css isn't correctly applied to the extended
`upgrade_boolean` field.
Since its class is automatically set to `o_field_upgrade_boolean`, it
doesn't take the modifications made to `o_field_boolean`.
So we add `o_field_boolean` to its additionnalClasses.
Part of task-2985735
closesodoo/odoo#104708
X-original-commit: 06b99fe293bf6d3c9cd902501d9e221dfd2a70e7
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
**Issue:**
When a group contains more than 10k items, its pager only shows
10k as limit, even if the group already knows it's total count.
**Solution:**
We now allow creation of `DynamicRecordList` with 'countLimit' as
one of the params. It will be used in the instantiation of the
class but will default to WEB_SEARCH_READ_COUNT_LIMIT if not
provided. This way, pager's limit will be properly set to the
group's count.
closesodoo/odoo#104698
X-original-commit: 4751f85ac9d430528106de05bcdc484ae0c7079b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Purpose
=======
Some models might use the properties field in the kanban view, some
other no. For that purpose, we want to add an option in order to
hide the "View In Kanban" checkbox in the properties definition.
Task-3012780
X-original-commit: c6fcaa53683c470158e4661aec2575bd06ee3c1e
Part-of: odoo/odoo#104252
In the PR #97692, writing empty str `''` to a model term field no longer removes
all translations. Instead, only the translation for the current language is set
to empty str `''`.
Before this fix, if a web user sets a translation to emtpy str, and reopens
the translation dialog, the translation will be reverted to the 'en_US' value
which is wrong.
closesodoo/odoo#104181
X-original-commit: f97ff6308d472121e65a34d30b4dc5ab35065220
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
Before this commit, the arrows in the daterange picker to switch months
wasn't correctly displayed in light mode.
This visual bug was introduced due to styling changes made for
the dark-mode.
This commit fixes this.
closesodoo/odoo#104151
X-original-commit: caa5604fbf99f6cba763109e7c26fed6e2042642
Signed-off-by: Samuel Degueldre <sad@odoo.com>
As of now, if a user clicks on the "Save & New" button while the form is
not valid, it will disable all buttons without any options to make them
enabled again. The only solution then is to close the form and re-open
it.
Steps to reproduce:
Inventory -> Configuration -> Route -> Select any route -> Add a line to
the rules.
As soon as you click on the "Save & New" button and the form isn't
valid, you can't use any buttons anymore.
Part of task-2985735
closesodoo/odoo#102315
X-original-commit: 6d63d1035b28f2004774a99a7be84b92a1cb1883
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Before this commit, in the list view, clicking on the "export all"
button created an xslx file that did not reproduce the order of the
columns in the view.
Why is this?
The order used was based on the data fetched by a
rpc("/web/export/get_fields".
Solution:
Do not do a rpc("/web/export/get_fields") and use the order of the
columns in archInfo.
How to reproduce:
- Go to a list view
- Click on the "export all" button
Before this commit:
The order of the columns in the created file may be different from the
order in the list view.
After this commit:
The order of the columns in the created file is the same as in the
list view.
closesodoo/odoo#104541
X-original-commit: 734eee368d548fddc6c516ff559d09e853d1ab74
Signed-off-by: Luca Vitali <luvi@odoo.com>
Before this commit, if a translation dialog was open, and the view where
the button is unmounted, the dialog stays open.
Now, the dialog closes, when the view is unmounted.
closesodoo/odoo#104543
X-original-commit: 40596ed1eccdf0f37b4fa3a8a337e7a7cc3461ce
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Since commit, odoo/odoo@f2b71d51aa
the text ellipsis is working again with long breadcrumb.
But in form view when there is a long breadcrumb, the
'form status indicator' (save, discard) is not visible anymore.
In this commit, we move the 'form status indicator' outside the
breadcrumb, so it can't be hidden anymore.
Note: we also changed the `align-items` to `flex-start` to keep all
buttons aligned on the top ('form status indicator', action menu, pager,
create button, send message, ...).
Steps to reproduce:
* Go to Sales
* Select a Quotation
* Click on the customer (to go to customer form view)
* Change its name to have a long breadcrumb
* Go back to the home menu
* Go to Sales
* Select the same Quotation as before
* Click on the customer (to go to customer form view)
* Change some data in the customer form => BUG
'form status indicator' isn't visible
closesodoo/odoo#104476
X-original-commit: df41c270b2372cd28226a16e089b71db32307159
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
"div" as a child of "tr" is not really allowed. Because of this,
custom widgets in a list_renderer are not properly styled resulting
to issue where a widget doesn't take the full height of the
parent "tr" element.
This was missed during initial wowl porting so in this commit,
we are putting the widget inside a "td" element.
closesodoo/odoo#104475
X-original-commit: 092b6b66d998795a03de82be4d33990a138396e1
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
removeContextUserInfo was a Spreadsheet asset, which is not a dependency of
Knowledge.
In order to make this feature available for all modules, it is moved in web as
an object util, that needs to be used alongside the user service in order to
dynamically remove user context information (no hardcoding).
Task-3017349
closesodoo/odoo#104304
X-original-commit: fd88fc1bbad4c0cdb44cf634b6a5621eb7597e0d
Related: odoo/enterprise#33322
Signed-off-by: David Beguin (dbe) <dbe@odoo.com>
Previously, if there were module loading errors, they would typically
happen before the error service was ready, and so there is almost always
no user-facing error that shows up even though the application state may
be severely corrupted. This can be very confusing for developers who are
not used to working with JS and might not check the devtools console.
This commit makes it so that the module system will replace the contents
of the body with an error when some modules were unable to be loaded,
with the list of modules and the reason, so that the developer is not
confused as to why things aren't working as expected.
closesodoo/odoo#104155
Signed-off-by: Samuel Degueldre <sad@odoo.com>
This is done so that using owl features and functions is done using
the standard import syntax, instead of destructuring properties out
of the owl global object.
So instead of just:
`const { Component } = owl;`
inside an odoo-module, we now do:
`import { Component } from "@odoo/owl";`
Note that we haven't removed the global `owl` object so existing
code will work as is.
Furthermore, we also augmented the tsconfig.json that's generated
from the tsconfig subcommand to take into account the path
of owl.js.
Task-id: 3032274
Part-of: odoo/odoo#104260
ISSUE: When in debug mode, user have access to the "External
Identifiers" view. The search bar allows searching using "Record
ID" which is a `many2one_reference` field. When user inputs
a search query that can't be converted to number, "Record ID"
option is still available to the user. It results to traceback
when it's selected because the UI is creating an invalid "domain"
which makes the server search for a string on an integer
(many2one_reference) field.
Check the video for illustration: https://youtu.be/XEPUXHcjeRI
SOLUTION: We make sure that many2one_reference field is properly
converted when generating the domain from the search_bar by
using the integer parser. This basically excludes many2one_reference
field from the search options when the input query is not a valid
integer. See it in action: https://youtu.be/NQ-YrK6tDH0closesodoo/odoo#104183
Task-id: 3005837
X-original-commit: bc9e8709309379bdd9191323cb015c89be7da1f9
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Apps store menus currently don't work and they are redirected to local Apps
menu. Because the warning message says "Odoo Apps will be available soon", user
may click such menu few times and notice growing breadcrumps, which looks buggy:
Apps / Apps / Apps / Apps / Apps / Apps / Apps / Apps / Apps / Apps / Apps
To reproduce: activate debug mode and click menu Apps / Updates
opw-2985389
closesodoo/odoo#104158
X-original-commit: a8481b73449db65eaca0b1e34a49a15a46d3d1f9
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
UI improvements for form control panel to correctly display long breadcrumbs.
It touches both desktop and mobile views.
Before this commit Action menu, Pager and Create button shifted by long breadcrumbs outside the screen.
closesodoo/odoo#104208
X-original-commit: f2b71d51aa409eae435f31d433dac4290c2b80ab
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Steps:
Go to timesheet (grid view).
Launch the timer.
Got to list view and check the new line.
Issue:
Few seconds before the minute, the seconds are negative.
Fix:
Convert hours decimals in milliseconds before calculating minutes and
seconds.
Also deleted the unnecessary condition for abs().
Also changes some `${...}` to String(...) to reduce noise.
closesodoo/odoo#104209
X-original-commit: 9d3e7ab4e903d2ada99693aa23e024d3ff84f5fb
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit, the Datefield dropdown did not close when you
scrolled on the page.
How to reproduce:
- Go to a form view with a date field
- Click on the date field input (datepicker is opened)
- Scroll down the page
Before this commit:
The datepicker is still open
After this commit:
The datepicker is closed.
closesodoo/odoo#104160
X-original-commit: d93ed838fdf0a721426dc56e26b5a83b3af6a66f
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
*: base_automation, lunch, mail, mrp, project, web_editor, website
This commit adds a warning if the props validation is not set for a
component.
The props validation is important to tell how a component should be
used, by looking at its code, it's a good documentation of the component.
It's also critical, to test if the component is correctly used, if all
the obligatory props are passed and that there are of the correct type.
For more information, see: https://github.com/odoo/owl/blob/master/doc/reference/props.md#props-validationclosesodoo/odoo#103723
Related: odoo/enterprise#33044
Signed-off-by: Géry Debongnie <ged@odoo.com>
Since the generated payment link is not editable, it is hidden behind
the wizard copy button.
To help the users understand the button, the text on the button can now
be edited in the xml with a `label` attribute.
task-2683480
closesodoo/odoo#100261
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Co-authored-by: Valentin Chevalier <vcr@odoo.com>
The web client exposes an utility function that converts the tokens
of a luxon's DateTime format into a moment.js format.
While this function is not false (still it is uncomplete), the strategy
of using it to convert a luxon's DateTime object into a moment.js moment
is not good.
The daterange field make use of this bad strategy.
Because of the differences between luxon and moment.js locale handling.
Luxon relies on the native JavaScript Intl API.
Moment has its own implementation of locale handling.
So having to pass through formatters/parsers may yield to unexpected
results. For instance, when a locale does not have the same way (in
moment.js and Intl) to express i.e. months and we try to convert a
luxon's DateTime into a moment by formatting the first and then
parsing into the second, the second will be invalid. This is the same
the other way around.
This was in fact encountered with some locales, i.e.
- syrian arabic (ar-SY)
- albanian shqip (sq-AL)
This commit brings an alternative strategy by providing other utility
functions to directly convert a moment into a luxon's DateTime
and vice versa.
This is a better strategy for various reasons:
- it abstracts the way the conversions are done
- no need to play with timezone's offsets
- probably all libs that has moment as a dependency accept a moment
object in their options, that may not be the case for formats
- The daterange field now use the new strategy
- The datepicker component now use the new utility functions as it had
implemented locally something similar.
closesodoo/odoo#104138
X-original-commit: 9dedfcaa4ad1fb5ea24f604b40df1bf0830617cb
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Change CSS rules for the sign frame to make it more responsive
task-id : 2993103
closesodoo/odoo#104109
X-original-commit: a77f4f24c374254e1c13d9d5b5b538c7562eb96d
Related: odoo/enterprise#33209
Signed-off-by: Arnaud Joset <arj@odoo.com>
This makes sure that the handler is properly assigned/removed
to/from the added/removed input elements.
closesodoo/odoo#104114
X-original-commit: d88b5e96a4d4a80dd14a271538a4669a6efd2d48
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
When NumpadDecimal is triggered, appending the decimalPoint to the
input field value is not enough, rather, we should replace the selected
range.
Also, we should ignore this for input field of type="number" because
it's natively taken into account.
X-original-commit: 3389cd2226ec82df9aa015637ac2d6a405936a4a
Part-of: odoo/odoo#104114
Reimplementation of 74fa91e0b3 on top of
new version of pdfjs. See previous commit for explanation.
Ideally we would set that behaviour from the outside using
e.g. `PDFViewerApplicationOptions.set` but there are multiple
locations from which we embed the viewer, which makes that a difficult
proposition. There should probably be a clean component which handles
loading the library, configuring it to our specifications (possibly on
a per-embed basis), and exposing both manipulations methods and events
which pdfjs triggers on its eventBus.
Part-of: odoo/odoo#100067
Our current version is getting rather outdated. Replace by
the *legacy* bundle: pdfjs now provides a non-polyfilled version of
the library, which is probably faster though it doesn't save overly
much (for the entire bundle anyway). Use polyfilled version for
safety, though it's unclear whether non-chromium Edge is still
supported by Odoo. If not, we could just use the non-polyfilled
version.
The difference is quite large for pdf.js (+32.5%), however it is much
less consequential for the sandbox (+1%) or for the much larger
worker (+5.6%). The biggest difference is likely performances
but... who knows?
Notes:
- The main reason for this change is that automated vulnerability
scanner have apparently started scanning for `postMessage(..., '*')`
and the previous bundles includes a version of corejs polyfills
without zloirock/core-js#542), therefore triggering those scans. As
the PR notes this is almost certainly not a concern because of the
innocuous payload, but there is no reason to waste time on those
reports if we don't *have* to.
- The bundle now includes "standard fonts", those were removed as
they're heavy and may not be necessary for our usage (?).
- All the bitmap images were dropped and replaced by svgs, which is
nice.
- The local changes since the previous update were *not* impacted in
this, the entire thing was just reset to upstream. This means
changes which were backported (922c7c72, 6943714f) are superseded
but more odoo-specific changes will have to be reapplied in further
commits.
Part-of: odoo/odoo#100067
This commit adapts the codebase to match its enterprise counterpart
where calls to legacy cookie api (cf. web.utils.cookies) are replaced by
cookie_service ones.
closesodoo/odoo#104080
X-original-commit: 724469e19ff83e91a41c6721e334df1ad8d1c02c
Related: odoo/enterprise#33189
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit, if an invalid list view is left, then a "View can't
be saved" error dialog is displayed.
The expected behaviour is a notification indicating the invalid fields.
How to reproduce:
- Go to a list view with at least one required field
- Create a new record
- Edit this record while leaving the required field empty
- Leave the view
Before this commit:
You stay on the view and get the "View can't be saved" error dialog.
After this commit:
You stay in the view and you get a notification "Invalid fields: "
with the invalid fields displayed.
closesodoo/odoo#104082
X-original-commit: 98fbacd8511594ca7a8cc9f0afa5d199a9b2ff20
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit, in a list view, if you click on a readonly field of
a record in edit mode, then it switches to readonly mode.
Why ?
The "pe-none" class added to readonly fields will prevent clicking on it.
Our click will then be applied to the table causing a unselectRecord
on the list.
How to reproduce:
- Going into an editable list view with a readonly field
- Click on a field to switch the record to edit mode
- Click on the readonly field
Before this commit
The record switches to read mode
After this commit
The record stays in edit mode
closesodoo/odoo#104070
X-original-commit: 52c817b88b5c799322a19f49807126928d9f28e1
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
Before this commit, in a multi_edit list view, if you click twice on
a readonly field, the focus is placed on the readonly field.
How to reproduce ?
- Go to a list view in multi_edit="true" mode with a readonly field
- Select a record
- Click on the readonly field of the selected record
- The record goes into edit mode and the focus is placed on the editable
field following the readonly field
- Click a second time on the readonly field of the selected record
Before this commit:
The focus is placed on the readonly field.
After this commit:
The focus is placed on the next editable field.
X-original-commit: aac7e6e4de371dcd01028a3a9ab66eed022c1ef0
Part-of: odoo/odoo#104070
In a kanban arch, have a dropdown that don't have a toggler, just an
explicit menu.
Before this commit, there was a crash.
After this commit, the kanban and the dropdown are correctly rendered.
closesodoo/odoo#104019
X-original-commit: 01418c474cb02455660156cf47822588f0554376
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Have a kanban arch with a field in display full in the kanban card template
```<field name="fieldName" display="full" />```
Before this commit, the class that should endup in the DOM was wrongly computed.
Technically, it was quoted in the owl template as if we passed it to a Component.
After this commit, a field having display="full" is correctly rendered.
X-original-commit: 526eb4f875ec6736d4b76da1fbdbcc99a8c33a9b
Part-of: odoo/odoo#104019
Before this commit, the usage that KanbanRecord makes of useViewCompiler was faulty in that
it did not respect the hook's API (the last argument is a dict params, not a string).
After this commit, the usage of useViewCompiler by KanbanRecord is correct.
X-original-commit: 8dbf7c88742e4603543005a1d5a158e5e0db2feb
Part-of: odoo/odoo#104019
The new WOWL Kanban view supports that luxon be used in the archs.
Legacy kanban had a similar support but for moment.js
Obviously, new archs can't work with legacy implementation because of this.
This commit aims at providing some sort of hackish support, only valid in
the transition phase.
At least one use case has popped up, that is, when editing such kanban view with Studio.
In that case, there was a crash, which is fixed with this commit.
closesodoo/odoo#103821
X-original-commit: 14f56b324d241f35b742781424535cecf26a218e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, fields using Many2OneField in their template (for
example, the many2one_avatar field) had a wrong style for the external
button (the arrow on the right to open the record in form view).
closesodoo/odoo#103981
X-original-commit: c63493ab7b19a238304b2d7791c28bf1a52c0d2f
Signed-off-by: Luca Vitali <luvi@odoo.com>
The goal of this commit is to restore the behaviour of the legacy
attach_document widget.
How to reproduce :
- clicking on the attach_document button and selecting a file
In legacy:
We have a full reload of the view (Render and reload the record).
Before this commit:
Render the view without reloading the record.
After this commit:
We reload the model which causes a rendering of the view and a reload of
the record.
Why do we have to reload the record ?
If the action linked to the attach_document button modifies the record,
we want this modification to be applied in the view and not only on the
server side. To do this, we need to reload the record data to ensure
that all the changes are displayed in the view.
closesodoo/odoo#103891
X-original-commit: 82d4f0cd2f0265393cf66cd7be1a0a714584400c
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
Similar to the html field widget, this commit add the display: block
class to the pdf viewer widget in order to make it use the whole area of
a notebook zone:
Task: 2991906
X-original-commit: a1407975c2fafedef5f5eb7d4597cfcd88117e49
Part-of: odoo/odoo#103872
Before this commit, in a list view in multi_edit mode and editable="0",
it was possible to edit a required field with an invalid value.
Why:
In the PR 101924, we decided to no longer pass readonly/required of fields
in non-editable views (if no editable="1").
Solution:
To know if a view is editable, you should not only look if it is
editable="1" but also if it is multi_edit="1".
So we want to pass the readonly/required fields if the view is
editable="1" or multi_edit="1".
How to reproduce:
- Go to a multi_edit="1" and editable="0" list view with at least one
required field on the server side
- Select the checkbox of the record you want to edit
- Edit that field with an invalid value (e.g. clearing a text field)
- Click outside the line being edited
Before this commit:
The record is saved with the invalid value
After this commit:
An alert dialog is displayed to warn us that the value is invalid.
The record returns to readonly mode with the old value.
closesodoo/odoo#103790
Related: odoo/enterprise#33066
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Since odoo/odoo#95729
nodes with a `groups=` are completely removed from the views when
the user is not part of the group, instead of being made invisible.
In that PR, views have been adapted to add back fields, with invisible="1",
when they were required, for instance when they were used in a domain
of another field which was still there despite the user is not part
of the given group.
As `tree` views having `multi_edit="1"` where not considered
as editable views, the domain of fields in these views were not
validated:
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1460
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1321-L1322
while they are well required for the web client,
in `multi_edit="1"` this is possible to edit relational/many2one field,
and therefore it will do `name_search` calls using the domain of the
field, and therefore the fields used in these domains must always
be present in the views. Without it, a crash in the web client occurs
when attempting to edit the relational/many2one field.
This revision targets to consider the `multi_edit="1"` tree views
as editable, to make the field domains validated as they should be.
Hence, views are adapted to add back fields with `invisible="1"`
when they are required in domains of other fields.
Part-of: odoo/odoo#103790
Release notes: https://github.com/odoo/owl/releases/tag/v2.0.1
- fix: runtime: correctly throw an error for duplicate object keys
- fix: parser: give t-set-slot="default" priority over the content
- fix: blockdom: correctly reorder children in heterogeneous t-foreach
- fix: portal: correctly move portal content when target is after it
- fix: blockdom: fix event_catcher traceback when a parent component has an empty child
closesodoo/odoo#103847
X-original-commit: be996cf423ce09be4e4661c0b42a97d92a4dcdb4
Related: odoo/enterprise#33097
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Joseph Caburnay