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>
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>
Previously, some lifecycle hooks were not called when using a
ComponentWrapper in an iframe, this is because to know whether we should
call mounted, we check whether the target/el is in the document, but
when using iframes, the document in question is not the top-level
document and so the check returns false.
This commit fixes that by checking if the elements are inside their
ownerDocument instead.
closesodoo/odoo#88435
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit, clicking on a x2m field when form view is not
editable (edit=0) did not open the dialog to show the related record.
After this commit, the dialog opens when clicking in a x2m field
of a non editable form view.
closesodoo/odoo#88378
X-original-commit: 80acf449bcaf5ff3d2ba81d84efc0498bc78c533
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Before this commit, when closing an action Dialog ( when the action is
wowl ) an error was raised. This occurs because we use the
LegacyAdaptedActionDialog, and an old function is called.
closesodoo/odoo#88118
X-original-commit: a6e45c53642003243e8a0f498e69ffddcac6e086
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
opw-2729810
closesodoo/odoo#87918
X-original-commit: 65f4c4f29a9c747f114eb6359d3ebb036efab9d6
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
When entering a date in a datetime field, it will be in the format
`08/01/2022 00:00:00`. If we place our cursor at the end of the
entry (after the hour) and each time we press enter, the timezone
offset is applied (so if offset is +1 it does +1 hour each time)
opw-2754116
closesodoo/odoo#87655
X-original-commit: 33e8540d64bb6e21debb7da9a121b706f551ab2e
Signed-off-by: Achraf <abz@odoo.com>
Current behavior:
In some particular cases bootstrap was throwing an error "Uncaught Error: Please use show on visible elements"
wich appeared on the users screens.
Steps to reproduce:
- Could only reproduce on copy of clients Db
- Go in CRM and go in any lead
- Create a new activity
- Swap to an activity with less fields
- Then quickly put your mouse on the top of a field that just disappeared
- The "Please use show on visible elements" error appears.
Here's a video where I reproduce it on clients Db : https://watch.screencastify.com/v/gksBwwF0McirZzSFwaAP
opw-2720853
closesodoo/odoo#87770
X-original-commit: 3404c9500fad4004d6d8beef6041ac51439078cd
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
This commit adds an information in the topbar (thus always visible)
to indicate the number of tests that have passed, failed and the
number of tests that have been skipped.
closesodoo/odoo#87713
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Currently in calendar if you double click an event in the calendar view, it
opens a dialog with the event title as undefined. This occurs, because the
title is not correctly passed in the context. This commit adds the correct
title to it, therefore fixing the error.
task-2685472
Part-of: odoo/odoo#79654
Define "Bootstrap v5 ready" utility-class to handle font-style.
This class definition can be safely removed after migrating to v5.
This class is needed for https://github.com/odoo/odoo/pull/87639
task-2811202
closesodoo/odoo#87637
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The target "main" feature has been lost during the conversion of
the ActionManager into the action service. An action with target
"main" should always clear the breadcrumbs. This commit
re-introduces the feature.
Fixes#83865closesodoo/odoo#87610
X-original-commit: 78ec7281ed550eb24629c1b81445b753314d292f
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>"
This commit renames the `Commands` object exported by the orm
service into `x2manyCommands`, and adds the magic numbers in that
object.
closesodoo/odoo#87582
Related: odoo/enterprise#25750
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit, the href attribute of menu elements didn't
contain the "action=xx" part but only the id of the menu.
closesodoo/odoo#87570
X-original-commit: 6b8242ee1918b784dfdb2160cca6df1c165a824b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to follow
- Go to the Sales app
- Search for a entry with a space at the end
-> No results are returned
The search input should be trimmed, it was in 13.0
opw-2803156
closesodoo/odoo#87529
X-original-commit: 06817417e190d64ab6b0fc6151e02b6090b1fd39
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Prior this commit the spinner was an image.
After this commit the spinner is an animated SVG. It also improves the
layout of the block_ui component.
task-2750837
closesodoo/odoo#83811
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit simplifies the SCSS of the command palette component.
task-2748052
closesodoo/odoo#83938
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This commit fixes a bug present in FieldEmail and
FieldPhone where the handler on the click event was
triggered twice and was not preventing the field to
turn into quick edit mode appropriately.
A test has been added for EmailField to ensure the
correct behavior
PR enterprise: odoo/enterprise#25506closesodoo/odoo#87196
X-original-commit: 852e084c355e9be77c693b32bf1119570e4d49d0
Related: odoo/enterprise#25558
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- Install accounting
- Create more than 6 analytical tags
- Create an invoice
- Create a payment
- Go in Accounting>Actions>Reconciliation, tab Manal Operations
- In the field Analytical Tag, click on 'Search More' and selected 1 or multiple tags
Issue:
Void tags are displayed
Solution:
Fetch the field `display_name`
ref commit: 84f0644802865c6454014059842eb6a9d4fd40e4
opw-2734029
closesodoo/odoo#87311
X-original-commit: 936bad32cf1024570da4880ccc5375b02b30c1c2
Related: odoo/enterprise#25631
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Current behavior:
If you activate the packaging options of the inventory
tab. The external link of the packaging type in the inventory tab of a
product is invisible.
Steps to reproduce:
- Have inventory module installed
- Activate the packages & product's packaging options
- Go on a product page and then go in the inventory tab
- Add a line in the packaging tree view
- There should be an exteral link next to the packaging type after you
selected one
- The external link is invisible
Note: similar issue was also present in the Document's workflow rules.
opw-2749832
closesodoo/odoo#87305
X-original-commit: 57a92e6a1178e3bd9d9f8995388cdc67a354c585
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
*: web, website_slides.
Specifying both side of a relation when seeding test data is cumbersome.
Let startServer method handle it.
task-2792108
closesodoo/odoo#86939
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Steps to follow
- Go to the product page
- Open studio
- Click on the picture and set the size to large
- Save and quit studio
-> The size doesn't change
Cause of the issue
Studio sets the size attribute on the field as `[0, 270]`
This means the picture should have a height of 270px and an unspecified width.
But for that to work, we need to handle the case were only one
dimension is set.
opw-2745625
closesodoo/odoo#87226
X-original-commit: 50368a9db8ac67986cf64ff84ee625cbf7a90a1f
Signed-off-by: Anh Thao PHAM <pta@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
There is a concurrency issue in the action service:
1) be in an action with several views
2) execute another action (e.g. by clicking on a menu)
-> [calls the route "/web/action/load", and it takes a while]
3) meanwhile, click on another view in the view switcher
If the call to "/web/action/load" is long enough, it may happen
that the view requested in step 3 is briefly shown before the
action associated with the menu clicked in step 2.
In this scenario, the action of step 2 should never be displayed,
because the user requested something else afterwards (in this
case a switch view).
One can produce a similar issue when restoring a previous action
of the breadcrumbs instead of switching view.
This commit fixes those two issues by registering a resolved
promise in the keepLast (concurrency utils), s.t. it "cancels"
the potential current operation (in this case, the call to
"/web/load/action").
closesodoo/odoo#87204
X-original-commit: fb9c8cd6fee476d2506b8c1338bf88c4520ea7b6
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the view service kept the same cache information
even thought favorite filters would be created or deleted. This caused
inconsistencies when the interface tried to reload views that would
access the cache and display outdated information.
Now the related views cache keys are invalidated when favorite filters
are created or deleted.
closesodoo/odoo#76507closesodoo/odoo#87031
X-original-commit: 84e260e4ecad5116def4d9dcdd0b35d7e87fa45d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
tsm-odoo