In a grouped list view, click on the header of a column for a
sortable field. The record rows inside opened groups are correctly
sorted. However, before this commit, the icon indicating that the
column is sorted wasn't displayed. It worked fine if the list
wasn't grouped. This commit fixes that issue. It also adds a 1s
delay before opening the header tooltips (1s is the delay we have
for the other tooltips in the list view).
Issue reported in the feedback pad after migrating odoo.com to 16.0.
closesodoo/odoo#110351
X-original-commit: e68e13cfce8eb82248336361998b873f26096634
Signed-off-by: Georis François (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Commit [1] adds a limit on the search_count done to get the total
number of records matching the domain in a list or kanban view
(displayed in the pager).
When the limit is reached (10000), a `10000+` is displayed as
total. Clicking on it performs a search_count to get the actual
number of records.
Before this commit, from that point, the count limit was set to the
total number of records. It means that if a record was created or
modified to match the domain in the meantime, and the user clicked
on the pager to see the next page (for instance), a `+` was again
displayed next to the previously fetched search_count, which looks
like a bug.
To prevent this from happening, this commit simply removes the
count limit once the user has clicked on the total.
[1] 6acfad2651closesodoo/odoo#110348
X-original-commit: 9aab36bcfb682865b615c8fbbc107afeee3a24f4
Related: odoo/enterprise#36001
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
This reverts commit 8d437bf.
Because of the above commit, the sample server did not correctly group
the records when a date/datetime field was used as a groupby.
We revert id and add a test.
closesodoo/odoo#110321
X-original-commit: 1a0c688aee7682919b66492636f46eff481abd29
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Have a list or kanban view with 10k+ records (or manually change
`WEB_SEARCH_READ_COUNT_LIMIT` in the code). On a slow network,
click on the pager to go to the next page and click on `10OOO+` to
fetch the total number of records.
Before this commit, this might lead to a race condition where the
total number of records displayed in the pager is incorrect (if the
search_count returned before the web_search_read).
This commit fixes the issue at the pager level. We already disabled
it when clicking on next/previous or editing it. However, this
didn't prevent from fetching the count. Moreover, fetching the
count didn't disable the other features either. With this commit,
the pager is fully disabled when the user interacted with it, until
the view is reloaded.
closesodoo/odoo#110265
X-original-commit: 0ac84bda8de0c1a620d05469562932c0d04e8c3f
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the statusbar added a hotkey even if
it was readonly or non clickable.
Because of this, the user could change the status with a hotkey.
Now, if the statusbar is readonly or non clickable then
the hotkey won't be available.
closesodoo/odoo#110262
X-original-commit: 9569b4f463b6e82df3c8eafb8bd4329faac871b1
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
The `expand` attribute in list views can be dynamic (e.g.
`context.get("some_val_from_ctx", False)`). Before this commit, it
wasn't evaluated, so a dynamic value would always result as true,
as it isn't "O", "false" or "False". To instance, go to Invoices
and add a group by. This commit fixes that issue.
Task 3130159
closesodoo/odoo#110235
X-original-commit: 1072c4880fdd2835b0711869da06681dab20d33c
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Open a kanban view;
- Select a progress bar filter;
- Open a record;
- Came back to kanban using the breadcrumb.
Before this commit, the progress bar is selected, but the records aren't
filtered.
Now, the kanban is exactly the same as it was when we click on the
record, the progress bar is selected and the records filtered.
closesodoo/odoo#110224
X-original-commit: ca864d7e6d510ef6410898099364d854a15150d7
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
The mail code had to override both new and old form views to add the
chatter feature. Since we converted (almost) all uses of the legacy
form view to the new owl views, the old override is no longer necessary.
This commit removes it, and also removes the 'legacy_form' entry in the
registry so all screens should fall back to the new form view, which is
stable.
closesodoo/odoo#110168
Related: odoo/enterprise#35924
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Install two languages;
- Install Accounting;
- Active 'Default Terms & Conditions';
- Select 'Add a Note';
- Click on the translate button;
- Answer 'Ok' when asking for saving the settings before modify the
translation;
- Save or Discard the translations;
- Save the settings.
Before this commit, a backtrace is raised. This issue raise because we
create twice the settings record. One before opening the translation and
the second time juste before saving the settings. This is a normal
behaviour in settings, as we consider the settings view as always new, a
new record is always created. But, only the last one should be sent to
the python code on the resId array.
opw-3109677
closesodoo/odoo#109803
X-original-commit: 5394f4c82829f8c7e6aaf73ddb1590f316f87ee3
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Owl last update fixes the leaking `this` in rendering context of
templates called with `t-call-context` [1]. Since [2], we use the
`t-call-context` directive to control the rendering context of
templates compiled from an arch (e.g. in form and kanban views).
We can now better control what people use in archs, where we don't
want them to access js implementation details, as `this` is no
longer available.
However, the component instance still needs to be accessible in
the compiled template. We thus add the `__comp__` key in the
rendering context. Since we do not want people to access it in
archs, we add a check in the view validation that this string
isn't used in dynamic attributes.
[1] https://github.com/odoo/owl/commit/df59ec49aefce2e0913fdc1792d42b9680fb28b6
[2] https://github.com/odoo/odoo/commit/4c5b867ff6b0b674cb83d1a1262ae354ebaa6d57
X-original-commit: 264f313012aa99449d1576ae1110252c13755142
Part-of: odoo/odoo#110196
Before this commit, the confirmation dialog was opened
only when the user clicked on an action button.
Now, the dialog is also shown when the user clicks a
menu item in the navbar.
Of course this dialog is shown only if the user has
changed a setting.
closesodoo/odoo#110194
Task: 3102800
X-original-commit: a180178bfd73d6e5f95ee5a9e9cdc1b0d64fc574
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when unfiltering a column in a kanban view, a
flickering occurs and the show more button is visible for a moment.
closesodoo/odoo#110130
X-original-commit: 0cd9c7dbba12e362a6445f47d52b43c48dffdb61
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
This commit fixes the export when all records are selected (full domain).
Since many records ids might be present when an entire domain is selected,
the request should contains 'false' instead of a list of ids. As a limit
is set in session.active_ids_limit, not all the records were considered.
This means that only the limit was actually exported instead of the full
list that is present. As the legacy implementation of the ExportDialog
allowed to export all records, the behavior has been fixed.
A test has been added to verify the correct parameter during the download
call.
closesodoo/odoo#110126
X-original-commit: 7200e1c5875bc148fb64187fd67d58a7d6c13c7c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, exporting templates were not filtered as
expected. It means templates were visible even on other domains,
polluting the list of templates of a model.
This restores the legacy behavior by filtering the domain in the
rpc and only displaying the desired template list.
A test has been modified to verify the presence of the domain
filter in the parameters of the rpc.
task #3127779
X-original-commit: 30a673c044e53bfb1edc1e6733b2c83c67e0232c
Part-of: odoo/odoo#110126
Before this change, if a user left a string value in a m2m_tags
and removed it afterward without selecting a tag, the update method
of Many2XAutoComplete would be called with false.
As the update method for m2m_tags expects a record or record list
this caused a traceback.
The fix is to simply skip the update in that case.
task-3109811
closesodoo/odoo#110123
X-original-commit: 14f314feb7594dc888de6af4e4ad23a948044854
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
When a list or kanban view is grouped, at each reload, we try to
match the fetched groups with the previously created Group
datapoints, such that we can restore/keep the state of each group
(for instance, the fact that it is folded, the limit of the inner
list...).
Before this commit, this didn't work when the view was grouped by
a date or datetime field, because in those cases, the value of the
group was a luxon instance, and strict equality between two
different luxon instances, even if they represent the same value, is
always false.
This commit fixes the issue.
Issue reported in the feedback pad after migrating odoo.com to 16.0.
closesodoo/odoo#110046
X-original-commit: 80fa8f187939d78ea644a49ec17c112bcc97b32b
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The goal of this commit is to fix the problem introduced by the PR 106519.
How to reproduce the problem:
- Go to the "Email Marketing" app
- Go to the "Mailing Lists" menu
- Click on a "Mailing List"
- Click on the "Recipients" stat button
- Click on the "Import" button
Before this commit:
A dialog opens and no mailing list is selected.
After this commit:
A dialog opens and the mailing list we are in is selected.
closesodoo/odoo#106732
Related: odoo/enterprise#34453
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adds the possibility to define buttons that are always
present in the arch of a kanban view.
Purpose:
Several customisations of the kanban view consist in adding an always
present button in the control panel that performs an action/calls a
model's method.
We want to support this feature directly in the framework to remove
these customisations.
The task 3082303 has added the same functionality to the list view.
Solution:
Add a "display" option that lets you know when to display a button.
The different values that can be assigned to "display":
- "selection": the button is only displayed if at least one record is selected.
- "always": the button is always displayed.
The default value of "display" is "selection".
Currently, only the value "always" is implemented because it is not
possible to select a record in a kanban. The selection of a record in a
kanban view will be implemented soon, so we decided to use the same API
as in the list view.
Exemple:
<kanban>
<header>
<button name="to_do" type="object" string="Do" display="always"/>
</header>
...
</kaban>
Taskid: 3082390
Part-of: odoo/odoo#106732
This commit makes the kanban group header sticky, it means that when
the user scrolls the headers will still be visible on top of the view.
closesodoo/odoo#109060
Task: 2050014
Related: odoo/enterprise#35611
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Because of an issue with converting bool values, read_progress_bar didn't work
on grouping by bool fields (e.g. Active).
Related tests worked fine because mocked server responses were different from
real server responses. So, we need to adjust mocked server too.
opw-2870937
closesodoo/odoo#103926closesodoo/odoo#104613
X-original-commit: e6ca3ef1b38dec964dab416c6058d4c1b7161614
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Before this commit, there was no way to instanciate a Record component and be
able to handle changes occuring in that record.
After this commit, a simple props is added, making this use case possible.
closesodoo/odoo#109846
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In a list view containing n records, apply or remove a filter.
Then edit the pager to reduce the limit to m, with m < n.
Before this commit, the pager was indeed updated, but the list
still contained the same number of records as before applying the
filter.
This was due to a kanban specific logic to handle the "load more"
feature. We stored the number of loaded records, and forced the
limit to be at least that number.
This commit fixes the issue by changing the way the "Load more"
works. Instead of loading the "limit" next records (i.e. with a
limit and an offset), we now reload the previously loaded records
+ the "limit" next ones (i.e. we leave the offset to 0, and
increase the limit).
This also prevent potential weird behaviors where the same record
appears twice, or records are skipped, when the recordset changes
between the first load and the first load more, or between 2 load
more.
closesodoo/odoo#109693
X-original-commit: 217d1191750d03918055610ba0e61f0f7522f475
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since the rewrite of this dialog, some inconsistent behaviors were
present compared to the legacy implementation. This commit fixes some
of them.
First, many2many fields couldn't be expanded as it was the case before.
Secondly, the export list generated by default was wrong, and it has been
fixed by this commit. The defaultExportList that was computed in the as
expected for the direct export is now also used to display the right
fields from the right pane as it ignores the fields that are explicitly
not exportable.
Finally, minor UI issues have been fixed, like a wrong title.
Tests have been added to assert the correct behavior of the dialog when
selecting records.
closesodoo/odoo#109670
X-original-commit: 86b634a120de0843fbd90079e9e457818fd4acde
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
Before this commit, when a user was on a form view with pending changes
and would click on the browser back button. If the previous action was
the same action, the user would be redirected to the form view but a
traceback would be raised because the form view was not able to handle
the pending changes "in time".
Here "in time" means before the form view is rendered. The form view
when rendered will try to update its display name through its controller
config, but as the new controller will be in fact the same as the
previous one, its config is currently being changed while the previous
form view is still using it. This leads to a traceback.
This commit fixes this issue by making sure that the changes are
properly commited before changing the config for the new controller.
The same kind of issue has been fixed in the action service for the
restore function, but there are no sensible ways to test this particular
use case.
closesodoo/odoo#109653
X-original-commit: e8a95c37e4e9ee4e4a65a3bfb216d3fa55544933
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: hr_holidays, hr_work_entry_contract
The commit introduces a new standard view component made to implement
in a consistant way the scale/select the appropriate period to display
in a view. This component is currently used by the Calendar view.
Tests have been added for this new component, as its behavior specs must
remain comprehensive. When there is no options or only one, the button is
removed from the view to keep space available, as its purpose is reduced.
This component gives the opportunity to keep the same style and behaviors
for views implementing it (eg: Calendar, Gantt) and should be used in
other views as well as soon as they are converted to Owl.
Other modules have been adapted to use the component name in xpath instead
of the span with the o_calendar_scale_buttons element. Tests have been
adapted as well.
A scss file has been modified to prevent the arrow to be misplaced on touch
devices due to a higher padding in the dropdown item element.
part of task #2867569closesodoo/odoo#109090
Related: odoo/enterprise#35435
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
`fields.Json` is introduced in v16. There are just few usage of it in standard
code. It's usually used via `widget="analytic_distribution"`. However, user may
add the field to list view via a Studio. To prevent errors, this commits adds
basic formatter for the field.
STEPS:
-In the Purchase app, add a new Menu based on the existing Model "Purchase Order Lines"
-In the list view of that new Menu, add the existing field "Analytic
-Distribution"
opw-3055926
closesodoo/odoo#109573
X-original-commit: d0621a2aec9cdc4bad348804fe5ada974b75f322
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Before this commit, setting a disabled attribute on a <button> tag in
the arch of a list view was ignored.
How to reproduce:
Going into a list view with a <button disabled="1"> tag.
Click on the button
Before this commit:
The button is not disabled and a crash is displayed on click.
After this commit:
The button is correctly disabled and there is no crash on click.
closesodoo/odoo#109337
X-original-commit: c8ef3262e3aa167a520dcb0d1b229e61e5e2e362
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- go to "Link Tracker" app;
- go to "Campaigns" tab (UTMs);
- create a new campaign;
- leave and return in this record.
Issue:
A traceback appears.
Error message:
`Invalid props for component 'Notebook': 'defaultPage' is not a string`
Cause:
The `defaultPage` prop must be a string.
When the record is new, it will be `undefined`,
so it will pass props validation because this prop is optional.
But when we try to calculate it and it does not return a value,
the `defaultPage` is null.
The variable is therefore declared but it is empty
(and therefore not a string).
`null` value does not pass the props validation test.
The problem appears in the "Campaigns" tab
because there is a notebook without content.
Solution:
Test if it is possible to have a value.
If not, set the `defaultPage` prop to be `undefined`.
opw-3109327
closesodoo/odoo#109533
X-original-commit: 402b1a822c3983af33aa1d3a3c7e93d8836c60d8
Signed-off-by: Dardenne Florent (dafl) <dafl@odoo.com>
Since the rewriting of the views in OWL2, it is not possible to clear a
set many2one field.
In this commit, we restore the clear button.
Steps to reproduce:
* Go to Sales (on Mobile)
* Create a new Quotation
* Select a customer
* Try to remove the selected customer => BUG
closesodoo/odoo#109531
X-original-commit: 57cb2a34c8211352baa439ee784dc370cc6abb1b
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Before this commit it is not possible to add default
groupBy in list if users want default groupBy a list
then they have to pass default groupBy in action and
passing default groupBy in action groupBy other views
in action, so priorer to this commit users cannot add
default groupBy in list view without impacting other
view.
In, this commit add default_group_by in list view
attribute so users can add default groupBy in list
view without impacting other views in action.
task-3084850
Part-of: odoo/odoo#109281
**Issue:**
- Try resizing a column.
- Bug: After releasing the resize, the column being resized is also reordered.
- This results to automatic resizing of the columns, not respecting
the current resize made by the user.
**Solution:**
1. Keep the size of the columns after reordering. Better UX because any resize
made by the user won't change when reordering the list (accidentally or purposely).
2. During resize, we track state variables - `resizing` and `preventReorder`.
- When resize starts, `resizing` is set to `true`.
- When the mouse pointer is released (mouseup), and before the `mouseup` event
reaches the `window`'s `mouseup` listener, the column title handles the `mouseup`
first, setting another state variable `preventReorder` to `true`.
- `mouseup` will eventually reached `window` which stops the resize, setting
`resizing` to false.
- Then, click event happens on the column header. And since the `preventSort` is
true, it will return early but resets the `preventReorder` to `false`.
- If the click event happened to be in the resizer span element, we should not
prevent it from bubbling so that `preventReorder` is properly reset.
**TASK-ID:** 3109501
closesodoo/odoo#109518
X-original-commit: 7a71a0974164277ac7fd382391684b078b71bf7d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit is to convert the client actions in misc.js into the new
architecture.
We remove the client actions login and logout because they are no
longer used in the code base.
closesodoo/odoo#109332
Task-id: 3099992
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when trying to change the menu from an invalid form
view, you would stay on the form view but the navbar would be modified
to dispaly the menu you had selected.
How to reproduce:
- Go to a form view
- Edit the fields so that the record is invalid
- Change the menu using the menu app or the palette command
Before this commit:
The form view has not changed but the navbar has been modified, it shows
the menu you selected.
After this commit:
The form view and the navbar have not changed.
closesodoo/odoo#109460
X-original-commit: bd7e36edcd2f9d33a72cc25b030f91c20da78387
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce
==================
- Install mrp_product_expiry
- Go to Inventory > Products > Lots/Serial Numbers
- Add the column "Expiration date"
- Remove the groupby if any
- Select 2 records, set an expiration date
- Confirm
- Select the same records, remove the expiration date
-> TypeError: value.setZone is not a function
Cause of the issue
==================
When entering the readonly mode after changing the date, the function
`formattedValue` is called. But `this.props.value` is equal to `""`.
`formatDateTime` only handles `DateTime | false`
The field is rendered from this template https://github.com/odoo/odoo/blob/1d8f6359bbf55983a9582282d12a187c67cdf509/addons/web/static/src/views/list/list_renderer.xml#L233-L236
When `canUseFormatter` returns true, formatDateTime is called with
false, coming from `record.data[fieldName]`
opw-3111869
closesodoo/odoo#109436
X-original-commit: 5b26a080ae28fab2a78e92a838472578591eef17
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in the form view, the date range picker field was
not updated correctly when switching pages.
How to reproduce:
- Go to a form view with a date range picker field
- Open the date range picker
- Close the date range picker
- Next page
- Open new date range picker
Before this commit:
The dates selected in the date range picker correspond to those on the
previous page.
After this commit:
The dates selected in the date range picker correspond to the current
page.
closesodoo/odoo#109423
X-original-commit: da5c4fb5a363158bcdef17f593ab8a556415a65d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- Go to the eCommerce app > eCOmmerce Categories.
- Select any categorie or try to create a new one.
Issue:
The box containing the fields it's not displayed properly.
Solution:
Added the class `clearfix` to the sheet component as it used to be in
previous versions.
opw-3080099
closesodoo/odoo#109408
X-original-commit: 4373cf2901b8db61592eba7cff2fae60ff68348a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
On first focus in an autocomplete field, the text content of the input element
is automatically highlighted.
closesodoo/odoo#109025
Task-id: 3117420
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit separate the templates, one for the card and another one for
the menu (the ellipsis dropdown).
The new template, called 'kanban-menu', will only contain the dropdown.
Note that, this behaviour is the same as the one used for the kanban
tooltips.
closesodoo/odoo#107589
Task-id: 3096776
Related: odoo/documentation#3284
Related: odoo/enterprise#34962
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When some true groups have been fetched, the sample server use them to
construct the value returned by _mockWebReadGroup, i.e. construct some
fake groups. It also populate those groups by assigning them some
previously created fake records. It turns out that those fake records did
not have the right type when the first group by is a date/datetime field.
The record values created (during the group assignation) for that field
were luxon.DateTime instances instead of strings like "2022-12-15".
This was the root cause of the following problem.
Have a kanban view in sample mode and grouped on a date field, then
switch to a pivot view grouped on the same date field. A crash occures.
That crash is linked to the above mentionned problem in the following
way:
- open the kanban view (with sample="1" in its arch)
- some existing groups are fetched by the relation model but no records
exist
- the kanban view switches to sample mode and some fake invalid records
are created in the sample server (the invalidity of records do not
cause visible problems at that time)
- switch to the pivot view
- the sample server is reused but existingGroups is set to be null, so
that _mockWebReadGroup uses the invalid records to create the groups
it needs. The crash occures at that step.
Forward-Port-Of:: cdd583f74f51086c8d5f243a2a761622229ccc26
closesodoo/odoo#109031
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
When some true groups have been fetched, the sample server use them to
construct the value returned by _mockWebReadGroup. It turns out that
this construction was invalid: the value returned for the first group by
in each group had the wrong type in many cases. For instance, when the
first group by is a date field, the value returned could be an array
with a luxon.Datetime instance as first element and a description as
second element while it should be a description only (e.g. "December 2022).
We fix that problem.
Forward-port-of: 59c7c8c9adcad468ad9d985113a2b88e745b7414
Part-of: odoo/odoo#109031
Before this commit, the modified test sometimes failed on runbot,
because it might happen that the hashchange event is triggered in
the next animation frame (the event isn't triggered synchronously).
This commit ensures that we wait for the hashchange event, and for
a nextTick before checking that the next action is in the DOM.
Fixes runbot issue 6946
closesodoo/odoo#109028
X-original-commit: 6aba445e2b4a1f6321cefb04fb07584df615dfa2
Signed-off-by: Samuel Degueldre <sad@odoo.com>
*calendar,test_main_flows
This commit tries to unify the name of the create buttons in different
apps. "New" is used over "Create" to avoid confusion regarding its effect.
"Create" could be interpreted as we want the current record to create a new one.
But "New" implies that the user will land on an empty page that can be filled.
task id: 3074472
closesodoo/odoo#108439
Related: odoo/enterprise#35139
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
**Before this commit**
When a breadcrumb is restored, the props resId is overwritten by the
res_id of the action.
**After this commit**
The props resId is kept if it is defined.
closesodoo/odoo#108996
X-original-commit: 810a1d29bfa7c497627a37e0cec64df51b75bb4b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit moves the tooltip from the parent element of the list
aggregate to the value itself to avoid having a tooltip that is
not connected to its intended target (here the tootlip's arrow does
not point at the value at all before this commit).
Task-3106190
closesodoo/odoo#108894
Related: odoo/enterprise#35351
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The mock server's mockReadGroup function would not properly compute the
range and domain of the returned groups for datetime fields with groupby
hour.
The year of the range/domain should be the same as the record and not
the current year.
Consider the following:
- a record with a datetime field of value "2016-12-14 12:34:56".
- a read_group with groupby "['datetime:hour']"
The corresponding group would have had the following metadata (considering current year is 2022):
- value: `"13:00 14 Dec"`
- domain: `[["datetime", ">=", "2022-12-14 12:00:00"], ["datetime", "<", "2022-12-14 13:00:00"]]`
- range: `{ from: "2022-12-14 12:00:00", to: "2022-12-14 13:00:00" }`
It now has the following valid metadata:
- value: `"13:00 14 Dec"`
- domain: `[["datetime", ">=", "2016-12-14 12:00:00"], ["datetime", "<", "2016-12-14 13:00:00"]]`
- range: `{ from: "2016-12-14 12:00:00", to: "2016-12-14 13:00:00" }`
X-original-commit: cca1fad650efc13cd1695acb723b9aa9a54ba184
Part-of: odoo/odoo#108947
Co-authored-by: Bruno Boi <boi@odoo.com>
Steps to reproduce:
- install "sale_management" module;
- create a quotation;
- add a product;
- click on "Search More...";
- create a favorite filter;
- leave and return to the Dialog window.
Issue:
No previously saved filter appears.
Cause:
The `loadIrFilters` parameter has a default value equal to `false`.
Solution:
Set the value of the `loadIrFilters` parameter to `true`.
opw-3105096
closesodoo/odoo#108946
X-original-commit: 7b60ee37e31d92d79108bd4e472553a452c2b0be
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Steps to reproduce
==================
- Use a mobile viewport
- Go to Expenses
- Create a record
- Enter a description and a category
- Click on Action
- Click on Attach Receipt
-> Nothing happens
Cause of the issue
==================
When the button is clicked, the dropdown is closed. This means that the
AttachDocumentWidget and FileInput Components are both destroyed.
Solution
========
Instead of using the FileInput Component, use an input element outside
the DOM.
We also use `this.env.services.orm` instead of `useService("orm")`
because the last one does nothing when the widget is destroyed
opw-3065590
closesodoo/odoo#108897
X-original-commit: 84d50b40f150f251a81e128fa9645d7fcc729dab
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Before this commit, domain selector did not support
selection field with "in/not in" operator because the
field does not accept these operators.
This commit adds the support as the operators can still be used.
closesodoo/odoo#108628
X-original-commit: 8ddd5e60f34f2ae9ca52fe936dc8da7054d1dc5e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the domain selector did not list the
operator if it is not accepted by the field
i.e. [['state', 'in', ['draft']]] is not listed in the domain
selector because "in" is not accepted by a selection field.
Now, the domain selector shows the operator even if it
is not accepted by the field.
X-original-commit: 2ae3adbce8cae17116f96f0a86296e41faf55246
Part-of: odoo/odoo#108628
Breaking on 2022->2033 transition
Those tests should be adapted to work without hardcoded dates.
closesodoo/odoo#108884
X-original-commit: 6945966b49a58ce3c0976dce37e324b37af8367a
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Aaron Bohy