Since 43463a1 it was not possible anymore to trigger hotkeys
from an editable element excepted through
the hotkey option "bypassEditableProtection".
But there are cases where the editable element may want to always
allow any hotkey: e.g. the command palette search input.
Before This Commit
Impossible to trigger hotkeys from the command palette.
After This Commit
The command palette search input now allows any hotkeys.
closesodoo/odoo#90578
X-original-commit: 72dfe16ec8453ff299c2525431db619ccfdbfdec
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi <boi@odoo.com>
the patchDate function had these issues:
./addons/web/static/tests/helpers/utils.js
29:5 error Read-only global 'Date' should not be modified no-global-assign
58:21 error 'date' is already defined no-redeclare
Part-of: odoo/odoo#90578
This commit uses params.displayName instead of params.action.name for calendar views titles.
This allows us, among other things, to use the project name as a title
for the project's tasks calendar view, which is more consistent with other views.
Task-2741733
Part-of: odoo/odoo#86008
Prior to this commit branded UI components were styled exclusively in
raw SCSS using the '$o-brand-odoo' variable.
This leaded to unnecessary code repetitions since, to achieve the same
visual result, each module defined its own classes.
Visual inconsistencies were frequent too since each module defined its
own variations for interactive states (eg :hover).
This commit injects '$o-brand-odoo' into bootstrap's default
'$theme-color' map, allowing the framework to automatically generate
odoo utility/contextual classes.
These classes can be used to handle text, backgrounds, borders and
buttons wherever needed.
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2800721
closesodoo/odoo#87448
Related: odoo/enterprise#25700
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This commit improves consistency between jQueryUI dropdowns and the
overall UI. It also address inconsistencies between versions allowing
to remove 'dropdown_extra.scss' [1].
Part of the overall v16 SCSS optimization/restyle, task-2704984.
[1] enterprise adaptations: https://github.com/odoo/enterprise/pull/25700
task-2800721
Part-of: odoo/odoo#87448
Review 'o_searchview' menu entries design, improving consistency within
the overall UI.
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2800721
Part-of: odoo/odoo#87448
The recordId parameter was not necessary in the _updateComodelRelationalFields method
of the legacy mock_server
closesodoo/odoo#90497
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit
An open dropdown stays opened if any other element stop a click event
closesodoo/odoo#90363
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the gap between `$border-radius` and
`$border-radius-lg` was too small and couldn't be differentiated easily.
After this commit, the value of `$border-radius-lg` is higher and can be
used for elements that need larger rounded corners
(e.g. Discuss components).
enterprise: https://github.com/odoo/enterprise/pull/25737
task-2810274
closesodoo/odoo#87521
Related: odoo/enterprise#25737
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
With this commit, if realpath is not available (for exemple on macos),
the script is directly stopped.
closesodoo/odoo#90522
X-original-commit: 7857c577948d55842a5697ca6d91bb6ea656ef6e
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Since fcf2e2210a639adfcdb9236c24cfb31046b6dead, the path of enterprise
is derived from the tooling path instead of the community path.
X-original-commit: 4ff8f62aa1e10d27189ebbdd22a01711c700ea32
Part-of: odoo/odoo#90522
Before this commit, when spawning a LegacyWidget with the standaloneAdapter,
the legacyWidget couldn't re-trigger an OdooEvent (trigger_up) in the DOM
forbidding any attempts to, for instance, execute an action button (a stat button in form view)
After this commit, not only standaloneAdapter takes an optional owl ref to trigger onto
(defaults to document.body), but the last resort legacy_provider handles execute-action
DOM event.
closesodoo/odoo#90172
X-original-commit: 616d0761a8e15dfe49db9bacdfa6f7df75587dff
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The current datepicker implementation uses Luxon to send and receive
dates from the client and Moment to create and communicate with the
bootstrap datepicker.
Before this commit: the current database date/time format was used to
convert dates from one system to the other. However there are
inconsistencies in notation for some formats, for which the conversion
could not be made properly.
Now: a static format is used to translate dates and the actual database
format is applied only after both systems have been notified of a date
change.
Tasks 2794506, 2797949
closesodoo/odoo#90422
X-original-commit: 174bc1dfa7b2894f35c288373f5130ec2992a8e8
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When clickbot opens a modal dialog, it should be detected and closed
properly. The `open` attribute was removed from the modal dialogs but
the clickbot test were successful by accident. Even though the modal was
not found, the script was still able to continue by clicking on other
elements.
By disabling the ability to click on other elements while a dialog is
open , this 590fa18cafe2c commit revealed the truth.
closesodoo/odoo#90393
X-original-commit: c5e2300cbb89519e002cf1784a8d6c6f68197742
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Previously, we were setting the ref to a component on ComponentWrapper
inside the onPatched hook, however, when mounting a component outside
the document (eg in a fragment) the patched hook is not supposed to be
called, but we need the ref to be set.
This commit fixes the issue by setting the componentRef in onRendered so
that it's available even when the component is mounted in a fragment.
closesodoo/odoo#90375
X-original-commit: 3013d89bcfe04be0207932b237d0e8ff8fb1d52b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Previously, the useAssets hook would load the templates from the given
bundles into the qweb instance that was in the environment. In owl 2,
qweb is no longer in the environment, and templates need to be loaded in
the app.
This commit fixes that by exporting a function to load templates in the
main app from assets.js, when the main app is created, it should be
written on the function in a similar vein to renderToString, so that all
further calls to the function will load the templates in that app.
This commit also adds an actual lazy-loading test in the
test_assetsbundle module, as we don't want to pollute the manifest of
web with bundles that only exist for one specific test.
closesodoo/odoo#90122
Related: odoo/enterprise#26776
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Previously, the "debounce" util function was broken when passing
immediate=true, this was caused by the fact that the timeout was not set
to null after being executed, leading the function to always act as
though a call is already scheduled.
This commit basically rewrites the entire debounce function to fix this
problem, simplify the code, and make the API of debounce as close as
possible to underscorejs' debounce utility (with the exception that our
debounce function returns a Promise that gets resolved if and when the
call eventually goes through, and with the extra feature that the
debounced function has a cancel method to cancel the currently scheduled
call)
closesodoo/odoo#90297
X-original-commit: 24c39ba1744d83ef9712ef4d3df7db5baf35bc2e
Related: odoo/enterprise#26821
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Earlier in Odoo, JS views were defined by defining 4 elements: View,
Controller, Model, Renderer. This was complex in some way, because we
wanted to inherit behaviour as well, so it was necessary to think along
multiple dimensions to understand how the code was running.
Then, with Owl, we rewrote some views, and simplified them: views were
now just a Component. Most of the common behaviour now came from the
generic View component that instantiated the concrete view with the
proper informations. In practice, views were still split in views
(which was the equivalent of the Controller of earlier views), Model and
Renderer
Now, this commit reintroduce the Controller, and change the way views
are defined: by an object with multiple metadata, and an (optional)
props function to compute the actual props used by the view.
As a result, views are now much easier to extend/modify.
closesodoo/odoo#89889
Related: odoo/enterprise#26728
Signed-off-by: Géry Debongnie <ged@odoo.com>
A call to get_views returns an object with a "models" key, which is
a mapping from model names to their fields_get. There is an entry
for the main model, and an entry for each model for which there's
an inline x2many view inside the form view.
Before this commit, this was processed in the view service, s.t.
we generated a "fields" object and we added a "relatedFields" key
for x2manys fields, pointing to the fields_get of the related model.
This can create a structure with cycles, which can lead to problems
e.g. if we try to stringify it.
This commit prevents this by no longer nesting the related fields,
but rather keeping them in another structure.
closesodoo/odoo#90271
Signed-off-by: Géry Debongnie <ged@odoo.com>
When a doAction is done, the action service stringifies the given
action and writes it in the session storage, s.t. it can be
restored on F5 even if it's a dynamic action (i.e. not in DB).
However, the stringify operation may crash (e.g. if there is a
cycle in the action description). As we do not control what is
given to doAction, it can happen, and we have to properly handle
it.
This commit simply catches the error, and there's nothing more to
do in this case.
Part-of: odoo/odoo#90271
Since commit odoo/odoo@9c41002b39, the
`.oi-fw` width value contained the `$oi-fw-ratio` variable name instead
of its value once compiled.
This commit fixes it by using SCSS interpolation, as expected.
To use SCSS variable in CSS `calc()`, the variable should use
interpolation to be properly evaluated at compile time.
Note: this apply only for LibSass, Ruby Sass and Dart Sass prior to
1.40.0.
Reference:
https://sass-lang.com/documentation/values/calculationsclosesodoo/odoo#90125
X-original-commit: 2465c9206a78289b294599451959c6cbc2c938d3
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Since https://github.com/odoo/odoo/pull/87584
with `date` field, pressing enter will removes 1 day to the value.
To fix it we have to ignore the offset suppression used for `datetime`
opw-2818927
closesodoo/odoo#90115
X-original-commit: 46e6475708c7ba8289345c4f7c125f60fc77d08c
Signed-off-by: Achraf <abz@odoo.com>
Since those tests are related to the legacy mockServer, they have been
moved to the legacy folder.
task-2582313
closesodoo/odoo#89883
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, py_js was unabled to evaluate expressions
containing "true" or "false" (boolean values, JS syntax), which
seems reasonnable for a python interpreter. However in Odoo, we
often use that syntax in modifiers (e.g. required="true"). For
that reason, we need to add those two keywords in the evaluation
context.
Part-of: odoo/odoo#87522
Before this commit, the makeView test helper processed the given
arch and generated the fields to pass to the View component. This
led us to do a similar work as what is done in the view service,
i.e. duplicate code, or factorize/reuse code.
An alternative is to let the View component fetch whatever it needs
(view arch, fields, search view...). This is the purpose of this
commit. That way, the code of the view service is executed (and
thus tested as well) in each test doing a "makeView".
This commit makes that change, and adapts some tests accordingly
(mainly, tests doing assertions in mockRPC, since we do a get_view
in every test).
Part-of: odoo/odoo#87522
Refactor the `load_views` API so it no longer sends multiple times the same
fields description.
e.g.
When `load_views` is called to get the kanban, tree and form views,
the list of fields of the model was sent 4 times:
- Once for each view, with only the fields used in the view,
in `['fields_views']['kanban']['fields']` for instance
- Once globally, with all the fields of the model, in `['fields']`
The goal of this revision is to change that so it sends the list of all fields
only once.
In addition, if a view contains x2many fields,
the fields description of the comodel is also sent.
It was sent in the `views` key of the view fields dict.
e.g.
When calling `load_views` of `res.partner` to get the kanban,
tree and form views,
the `res.partner` fields description was actually sent 6 times:
- Once for each view
- Once globally
- Once for each view of the many2many field `child_ids` of the form view, in
- `['fields_views']['form']['fields']['child_ids']['views']['kanban']['fields']`
- `['fields_views']['form']['fields']['child_ids']['views']['form']['fields']`
The change suggested in this revision is to:
- Remove the fields description for each view in `['fields_views']`.
As it no longer contains the fields,
the key becomes `['views']` instead of `['fields_views']`.
- Replace the dict key `['fields']` by `['models']`,
which is a dict with as key the model name and as values
the model fields description. It contains the fields description
for all models implied in the view:
the model of the main view and the model of all one2many and many2many fields.
With this change, the fields description will only be sent once by model
implied in the view.
In addition, the web client was getting the information about the fields
sometimes in the global fields description list (e.g. `['fields']`),
sometimes in the fields description list of the view type
(e.g. `['fields_views']['form']['fields']`),
making it a pain to try to make changes / performance gain
in these field description dictionaries, because you never knew in which dict
the web client was getting its info.
Now, as there is only one place to get the fields description from,
it's clearer and cleaner.
- one2many and many2many fields views are passed directly in the main view
architecture rather than being put in the `views` key
of the field description.
This is actually easier to treat by the web client,
and this will allow in a future work to cache an entire view in one block
of text rather than having to combine multiple cached blocks of text
to return one view.
- one2many and many2many fields which do not have directly embedded views
have their views directly injected in the architecture,
so the web client doesn't have to do RPC calls to `load_views`
for each one2many and many2many fields not having embedded views.
For instance, this allow to reduce the number of RPC calls to `load_views`
from 8 to 1 when loading the form of `product.product`.
Currently, this behavior is limited to 1 level deep but we consider making it
go all the way down in future works. We did not do it for the moment because
in certain cases it rises the processing time and the size (bytes) too much.
e.g. the sale.order view can be 5 levels deep,
meaning you can reach 4 dialogs on top the main view.
```
sale.order form > order_line > sale.order.line form > invoice_lines >
account.move.line form > asset_ids > account.asset form >
depreciation_move_ids > account.move form.
```
This will also benefit in future works to cache an entire view in one block
of text rather to having to combine multiple cached block of text
to get one view.
- `fields_view_get` becomes `get_view`.
As it no longer returns the fields description,
keeping the `fields` in the name `fields_view_get` no longer makes sense.
Hence removing `fields` from the method name, it becomes `view_get`.
As it gets renamed anyway, we take the opportunity to rename it `get_view`,
which is more in line with the general getter/setter guidelines
in the model object world.
- `_fields_view_get` becomes `_get_view`. For the same reasons than above.
- `load_views` becomes `get_views`.
This is not mandatory, there is no technical reason to rename `load_views` as
it practically sends the same info as before,
the view architectures and their fields description. Just in another way.
We just take the opportunity of this pull request to suggest a cleaner API:
`_get_view`, `get_view` and `get_views`.
- Arguments `toolbar=False, submenu=False` fo the methods
`_fields_view_get` and `fields_view_get` are converted to a kwargs `**options`
in `_get_view` and `get_view`.
The rationale is that submenu was already no longer used (deprecated)
and the mobile options is introduced.
The mobile options is necessary to tell the server to send the mobile views
for x2many fields (kanban instead of tree).
Instead of adding a new argument each time we add a new option to
`fields_view_get`, it seems wiser to have a kwargs `**options` to avoid
to re-write all overrides each time a new option is introduced.
- `_fields_view_get` returned a dict containing the arch in text and some of the
view information. Now, `get_view` returns a tuple with the view architecture
as an `etree` node, and the view as a browse record. The rationale is that all
overrides of `_fields_view_get` were about modifying the arch only
(e.g. changing the address format/re-organizing the address related field
nodes of the partner according to the company country).
To do so, all these overrides were doing `etree.fromstring` to parse the arch
which was sent in text to convert it to an `etree`,
then operations were done on the `etree`,
and then `etree.tostring` was called to convert back the arch to string.
With this change of signature to send the arch as an `etree`,
all these back and forth `etree.fromstring` -> `etree.tostring` are avoided,
allowing some performance gain and less code in the end.
- A cleanup of the keys returned in the dict of `fields_view_get`
has been performed in `get_view`:
- `fields` is removed, as explained above,
- `view_id` is renamed `id`,
- `name` is removed, it was unused by the web client,
- `type` is removed, it was unused by the web client,
- `field_parent` is removed, it was unused by the web client,
- `base_model` is removed, it was unused by the web client.
- `filters` is moved from the global dict returned by `load_views`
(now `get_views`) to the dict returned by `fields_view_get` (now `get_view`)
as it applies only to the `search` view type.
- Retro-compatible methods for the 3 methods
`fields_view_get`, `_fields_view_get` and `load_views` are provided,
with deprecation warnings in them.
- The web client could cache the model fields description
(as it already caches the views),
so it doesn't need to fetch them again if it asks for another view of a model
for which he already has the fields description.
If we do so, `get_views` could return only the list of models used by
the views, without the fields description as of now,
and the web client would then call `fields_get` independently only for
the models for which it doesn't have yet the fields description.
This would avoid the server to return the fields description
and to call `fields_get`, which is costly, for each `get_views`,
therefore gaining performances.
- Inject the views of the one2many and many2many fields all the way down,
unlimited depth level, as explained above.
- Cache with `ormcache` the architecture of back-end views.
This is already done for qweb views, it's not done for back-end views.
Therefore the postprocessing of the views is performed for each `get_views`,
which is costly, while the view architecture doesn't change for users
belonging to the same groups, according to the groups implied by the view.
This pull request is co-authored by
Aaron Bohy (aab) for the web client part and
Denis Ledoux (dle) for the server part.
Part-of: odoo/odoo#87522
Previously, updating a component that was mounted out of the DOM would
rerender it and patch it. In owl 1, patched was not called when a
component was mounted outside of the document. This caused crashes when
something done in onPatched depended on something done in onMounted (as
mounted is also not called when not it the DOM, which was handled
correctly by the compatibility layer).
This commit fixes that by ignoring requests to render a component that
is not yet in the DOM as a new render will be initiated anyway when
mounting the component in the document for real.
closesodoo/odoo#89935
X-original-commit: fc6a843abe52cfee084ed476f00a12a8ba1d1669
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Without this, `user_has_group` does not work in a frontend context.
The frontend session info seems to have been introduced with minimal
requirements with [1].
It was later populated with more keys, each time when facing a special
need. See [2].
Somehow, the `uid` need was never faced, thus never added, thus
`user_has_group` never worked in the frontend, apparently.
The fact that this method is not working in a frontend context is
something that comes back from time to time without really going
further.
The chance is here taken to fix that once and for all.
Note that we don't want to add the `uid` key in the session frontend
context as that would not be stable friendly, some users might now
relate to that attribute not being set in the frontend context.
This fix is then patching that method to work everywhere.
[1]: https://github.com/odoo/odoo/commit/0980546f4115ff7d072371d1b57d30000d07ce2c
[2]: https://github.com/odoo/odoo/blame/da8d418ff08aa55c7378887c9a5a06a5d12b72c0/addons/website/views/website_templates.xml#L128closesodoo/odoo#89890
X-original-commit: 9aafec4ed94b9f7f2af42970dd14142ee5ca70dc
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
To reproduce
============
- Create a company with a complete Swiss address (street, city, zip and country).
- Install the l10n_ch modules and install the Swiss plan comptable in the Settings of the Accounting app.
- Go to Accounting > Configuration > Settings > Activate the "QR codes" > Save
- Go to Accounting > Configuration > Journals > Choose the journal for the invoices > In "Advanced settings" verify that the communication type is "Based on invoice" and the communication standard is "Switzerland"
- Go to Accounting > Configuration > Journals > Select your bank journal(s) > Verify that you have set up your bank account number and the name of the bank
- Go to the Contact app > Configuration > Bank Accounts > Choose the one you use for the QR-bills > Edit > In "ISR Client Identification Number" refer a client number and make sure account type is 'IBAN' > Save.
- Verify that you have a complete address on the contact form of the customer (street, city, zip and country).
- create multiple invoices for this client
- try to print QR-bill for these invoices at once -> and assert error is raised
Purpose
=======
the `assert len(outlines_pages) == len(res_ids)` fails because the generated pdf
contains only a single invoice.
this issue is caused by the line `<script>document.body.className += " l10n_ch_qr";</script>` in `swissqr_report.xml`,
when `wkhtmltopdf` generates the pdf from html, it doesn't wait for all javascript to finish before rendering the page,
which lead to not execute the script `<script>document.body.className += " l10n_ch_qr";</script>` for some pages then the final pdf
is missing some pages.
Specification
=============
To solve the issue we removed the javascript block `<script>document.body.className += " l10n_ch_qr";</script>` from the template
and move it to python, by setting the body style when generating the html.
opw-2772396
closesodoo/odoo#89835
X-original-commit: a669b4c5f78aa18b87f5adcfc5acca3ce0a76040
Signed-off-by: abla001 <abla@odoo.com>
Issues found using a mobile device only.
On the planning module, go to the gantt view and select a shift with a long name.
The title of the modal that appears will be displayed in three separate lines, and
not all the information is visible. This was fixed globally to avoid having the same
issues in other modules as well.
On the industry fsm module, the worksheet info when signing a document
is not correctly structured.
task-2755200
closesodoo/odoo#89630
X-original-commit: 297eca04fb85ccf95cd0daab9d7062bf46cd6f04
Related: odoo/enterprise#26588
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Currently, the timezone offset is taken from the date with reverse
timezone offset applied.
So if there is a change of timezone offset between the wrong date and
the local date, we apply the wrong timezone.
Example:
- be in "Australia/Sydney" timezone
- select date in datetime field 2021-04-03 16:12:34 (at UTC+11)
- save => time becomes 17:12:34
- change time to 17:12:35 and save => time becomes 18:12:35
- change time to 18:12:36 and save => time becomes 19:12:36
- ...
- this issue is happening until 01:59:59 of the following day
Fix:
When we are selecting "2021-04-03 16:01:23" we will get the timezone
offset from the date "Sun Apr 04 2021 02:01:23 GMT+1000" (at UTC+10)
but the DST change was at "2021-04-04 03:00:00 (UTC+11)" with time
becoming "2021-04-04 02:00:00 (UTC+10)".
With this changeset, we are getting the timezone from the local time,
not from local time with reverse timezone offset applied.
opw-2735369
closesodoo/odoo#89619
X-original-commit: 84eb850af614887f7040bffa71cbb7fd239ba857
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The problem is generally due to the use of `var`, this one
https://github.com/odoo-dev/odoo/blob/58a046d2146e884d467cde827f89fa603ed98a3b/addons/web/static/src/js/views/basic/basic_model.js#L1780 followed by an asynchronous call to a function using it
We can therefore summarize the part of the `_applyOnChange` function
that interests us by
```js
for () {
if (field. type === 'one2many' || field. type === 'many2many') {
var list;
...
//using list
...
promiseFunction(list).then(function(){
//using list
})
}
}
```
In the case where we have two one2many which follow each other,
this scenario occurs:
- `list` is initially the first o2m
- the `promiseFunction` is called with `list` (first o2m)
- before the promise is resolved the loop continues
- `list` is `Promise.then()` the second o2m
- the first call to `promiseFunction` with `list` (first o2m) is done
- we enter in `Promise.then()`
- `list` is currently worth the value of the second o2m because
`list` is a `var`
- the second call to `promiseFunction` with `list` is finished
- we enter the `Promise.then()`
- `list` is currently worth the value of the second o2m because
`list` is a `var`
Result: `Promise.then()` is called twice with the first o2m and never
with the second
We can see what happened with this code example:
```js
const array = ["a", "b"];
const asyncRead = async(value) => {
console.log("async function arg", value)
setTimeout(()=>{
return Promise. resolve(value);
}, 100)
}
const forFunction = () => {
for (let i = 0; i < array.length; i++){
var list = array[i];
asyncRead(list).then(function (){
console.log("then async function arg", list)
})
}
}
forFunction()
/*
async function arg a
async function arg b
then async function arg b
then async function arg b
*/
```
While if:
We use `let`
by replacing `var list = array[i];` with `let list = array[i];`
OR
We force the use of `Promise.resolve()` argument
by replacing `.then(function (){}` with `.then(function (list){}`
We will get:
```js
/*
async function arg a
async function arg b
then async function arg a
then async function arg b
*/
```
opw-2694855
closesodoo/odoo#89160
X-original-commit: 99cb2f52e109ccf94ac8bd735cd776e84ef04260
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Have an action with target="new" and a list or kanban view as
first view. This view is displayed in a dialog. Click on a record.
Before this commit, the action service tried to switch view, but
in the action displayed in the background (since we cannot switch
view inside the dialog anyway). As a consequence, if the action in
the background was a window action with a form view, we opened that
form view, which is absolutely not what we want (different action,
different model...). And if the action in the background was a client
action, it crashed, because we can't switch view in those actions.
With this commit, we simply ignore calls to switchView when there's
a dialog opened.
opw 2791201 and 2793678
closesodoo/odoo#89539
X-original-commit: 81f8de82daa47a31e4a33478aeb537f2c9c1519c
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have an action with target="new" and a list or kanban view as
first view. It is displayed in a dialog, and a there is a control
panel. Before this commit, the breadcrumbs in that control panel
contained the complete history of controllers displayed in
background, which isn't what we want. For instance, clicking on
an element of the breadcrumbs crashed. After this commit, there's
only one element in the breadcrumbs, which corresponds to the
controller displayed in the dialog.
Spotted when investigating on opw 2791201 and 2793678
X-original-commit: 9838bb3a35e8b205fe30ceb5f86dcd81d536d1d0
Part-of: odoo/odoo#89539
*: base_automation, iap, web_tour
Previously, when trying to create a custom dialog, one would need to
extend the base Dialog class and configure it directly on the class,
using separate templates for the body and footer as necessary. This is
very unidiomatic owl code, and it is much more natural to simply extend
Component, and use Dialog at the root of the template, giving it slots
and props to configure its properties and contents.
This commit changes the dialog API to work as described and adapts code
that uses it.
closesodoo/odoo#89113
Enterprise: https://github.com/odoo/enterprise/pull/26462
Related: odoo/enterprise#26462
Signed-off-by: Géry Debongnie <ged@odoo.com>
When having a subview for a 2many field, if an onchange is triggered for
that field, the default values of the parent are still in the request
context.
To reproduce the issue:
(Need helpdesk_repair. Use demo data)
1. Helpdesk > Configuration > Helpdesk Teams, edit "Customer Care":
- Enable "Repairs"
2. Create a storable and tracked-by-usn product P
3. Update the on-hand quantity:
- 1 x P with serial S
4. Helpdesk > Customer Care (Tickets), create a ticket:
- Product: P
- Lot/Serial number: S
5. Click on Repair and save the repair order R
6. Edit R and add a line in "Parts"
Error: on the new line, both Product and Lot/Serial fields are already
filled with values P and S, which does not make sens
On step 5, when clicking on Repair, the form views of a repair order is
loaded with a specific context:
https://github.com/odoo/enterprise/blob/deef3c967d43862edf02dbcfc461fb89b064731e/helpdesk_repair/views/helpdesk_views.xml#L31-L34
Therefore, when editing the form and trying to add a new line in Parts,
an onchange is triggered but the default values are not removed from the
context. As a result, since the model `repair.line` also has two fields
called `product_id` and `lot_id`, the default values of the parent
(`repair.order`) are used.
When computing the context of a subview, the default values of the
parent should be removed.
OPW-2752436
closesodoo/odoo#89366
X-original-commit: db7423a97fd812fe6df95296fd7a6ca18854933b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
This commit adds missing translations in the 'Print' and
'Action' items of the action menu. It also fixes the
current translation (env._t must not be used in the
template directly).
closesodoo/odoo#89094
X-original-commit: c16194c1449edaaf994cb49d2173bdb27253c0cc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: SplashS <sergey@shebanin.ru>
- The dashboard list view is replaced by a kanban view.
- When you have a time off with a joined document when you click on it, the attachment view is now kanban and not list. The dropdown in the kanban card allows to download the file.
taskID #2658415 [Time Off] Mobile experience
closesodoo/odoo#84667
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce:
- Set a new DB without demo data
- Install Ecommerce
- Switch language to Arabic
- Try to open website module
Issue:
Traceback raised.
Cause:
When generating random sample data for website dashboard, it will use
the current local to generate dates (in the given format), who in this
case have a non-latin numbering system, and therefore will break when
trying to parse field value.
Solution:
Use `serializeDate` or `serializeDateTime` to format datetime (with
`latn` as `numberingSystem`).
opw-2743243
closesodoo/odoo#88840
X-original-commit: 5597912ad65e0b98c498f95ba884b9581a737211
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Co-authored-by: Nasreddin Boulif (bon)<bon@odoo.com>
Steps to follow
- Go to Accounting > Accounting > Sales (account.move.line model)
- Remove any existing group by
- Group by Products
- Select multiples lines of the same product
- Try to modify the account of the select line
-> `this.localData[value] is undefined
Cause of the issue
When grouping by a field not in the view, `list.__data` contains the
groupedBy field value because we fetched the group through a web_read_group
Solution
Filter out absent fields before creating the group datapoint
opw-2784995
closesodoo/odoo#88634
X-original-commit: d65852352ee4163f7097c19ac3c4a479922f32b8
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
This owl update is significant: it introduces a change in the way
components are rendered: now, child components check if there is a
current rendering somewhere in their ancestors. If this is the case, the
rendering will be delayed. This prevents lots of issues where a
child components may be in some kind of corrupted state after some state
changes.
closesodoo/odoo#88572
X-original-commit: 93710d082bf860d0ea576fe99db9506af9bb42b0
Related: odoo/enterprise#26135
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Géry Debongnie <ged@odoo.com>
Bruno Boi