purpose of this commit is to remove ID from the fields to group by on the
searchview as it does not work nor does it make sense.
removed field 'ID' from custom group by on search view.
task-2028105
closesodoo/odoo#34752
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit: nocontent tooltip was not diplayed in center
After this commit: nocontent tooltip will be displayed in center,
toggle o_list_view class which should not be added if nocontent
help is displayed, as there is no listview to display so remove
o_list_view class
task-2008371
closesodoo/odoo#34178
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adds two methods as hooks to customize the way Dialog deals
with its buttons :
* _setButtonsTo() : to render and set the buttons into a container
element;
* _setRemoveButtonOption() : to define the remove button and
set its destination zone (header, footer)
Task ID: 2038324
closesodoo/odoo#35474
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Co-authored-by: Dharmang Soni <dpr@odoo.com>
Added a resizing feature to all non-empty editable lists:
- added a handle to each column header, allowing resize
- column width will expand/shrink the table width
- resized columns will reset when reloading the list or sorting columns
- only available when the list contains data
closesodoo/odoo#35975
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Gery Debongnie <ged@odoo.com>
Let's assume the following situation:
- an empty editable x2many list with date field (or any other
fixed width field) and optional fields
- add a record to the list, but discard it directly
- toggle an optional field
After those steps, the date field doesn't have its hardcoded,
absolute width anymore.
This rev. fixes this issue by clarifying the way the stored widths
are erased when the columns change, preventing to reach a corner
case in which we have stored widths, but we can't apply them, and
thus let the browser uniformly divide the space amongst columns.
Columns with an absolute width (e.g. '120px') must always have a
width of at least that value. When there are records in the list
the column's widths are computed by the browser according to the
content (in readonly). However, for some field types, the rendering
in edition is a bit wider (e.g. date(time) fields because of the
caret).
This rev. sets a min-width to those fields such that the rendering
is also correct in edition.
Before this rev., a grouped list view with all groups folded
behaved like a list with records w.r.t. the computation of column
widths, whereas it should behave like an empty list, as there is
no record to help the browser to compute the optimal width for each
record.
When there were records in the list (and the browser computed the
optimal column widths according to them), and the user removes
them, we want to keep the widths as they are instead of forcing
them according to the field's types.
Mainly, when adding the first record to the list, as this is when
we switch from forcing the column's widths (when there is no data),
to letting the browser optimally divide the available space.
Some other cases had to be handled, like the multi edition.
Having two attributes for this was probably overkill. We now have
a single attribute 'width' which can specify either a fixed width
(e.g. '120px') or a factor (e.g. '2.5').
On a list with no data, the width of each column is determined by
a heuristic. Before this rev., the heuristic was based on the field
type. It now takes the potential widget set in the arch into
account, and fallbacks on the field type.
This rev. refines the way we compute column's widths in editable
list views.
When there are displayed records, we let the browser compute the
width of each column (which is thus optimal with respect to the
content), and we then freeze those widths s.t. it doesn't flicker
when we switch a row in edition.
When there is no record, we keep the former heuristic based on
absolute and relative widths (depending on field types). However,
we set the same weight for all fields having a relative width (i.e.
all but boolean, date(time) and numeric), such that the remaining
space is evenly distributed between them.
Co-authored-by: Aaron Bohy <aab@odoo.com>
Before this commit, a simple optimization was done: if a field was
modified in such a way that the new value is the same as the initial
value, then it is not considered changed.
However, with the new changes in the ORM, it may be an issue, because
doing so loses the intent of the user. If an onchange changes a field,
then the user changes it back, the server is not aware of that fact.
With this commit, we simply keep the field in the list of changes to
send to the server.
opw #2057230closesodoo/odoo#35890
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
- Change the company's country to Finland;
- Go to Contacts and click on Create;
- Tick the Company box above the Name field;
- Start typing into the Name field;
- Click on a company with a VAT number under its name.
Before this commit, a Traceback appears. This occurs because the
response of the request with the suggested company has the fields
'company_name' and 'company_code' and these fields are not in
res_partner.
Now, the suggested company is parsed to correctly field the country
field.
opw-2049636
closesodoo/odoo#35631
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
before this commit, domain selector widget does not support
TRUE_LEAF and FALSE_LEAF i.e. [(1, '=', 1)] and [(0, '=', 1)] respectively,
the reason is the chain part of the domain i.e. field name has value 1/0 and
we don't have field name like 1 and 0 in domain and hence ModelFieldSelector
don't accept it
after this commit, domain selector can handle this special two domains which is
[(1, '=', 1)] and [(0, '=', 1)], add support for chain with 1/0 in ModelFieldSelector
task- 1998145
closesodoo/odoo#35603
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
In the favorites menu, it was possible to create two
favorites with the same name (contrarily to the
specifications). The root cause of the problem was that
the submenus of the favorites menu were not updated at
all. This commit fixes that situation.
closesodoo/odoo#35495
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
When toggling a favorite filter, the options used by
the active date filters/groupbys and the field created
via autocompletion were not correctly cleared, leading
to strange situations. This is fixed by this commit.
Bug introduced with
https://github.com/odoo/odoo/commit/1f5c9e363b6f7cb9a2770e6247536803fd13e3f0
Before this commit, the public/website root was started as soon as
the bundle it is in was lazy loaded. It then started all the registered
public widgets. The problem was that some of those may be registered
by other lazy-loaded bundles. The public root would then not start
those if those bundles were lazy-loaded with a too long delay.
This commit fixes the bug by starting the public/website root once all
known bundles are fully lazy-loaded.
closesodoo/odoo#35118
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- Set the user language to a RTL language, e.g. Arabic
- Open a list view containing float or monetary fields, e.g. the invoice
list view
The numbers are left aligned while the corresponding columns headers are
right aligned, making the list view confusing.
The header alignment is hardcoded at rendering rather than in the SCSS.
Therefore, `rtlcss` doesn't affect it.
Instead of hardcoding the alignment, we use a proper CSS class so it is
adapted by `rtlcss`.
opw-2044019
closesodoo/odoo#35414
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
On the Time Off, spam click to create a new event, each click opens a
new event form modal.
When the modal form fields have not been cached yet, the frontend
fetches them and delay the modal form opening after those fields have
been fetched. As the interface is still available. It is possible to
re-click multiple time during the fetch, each click schedules a new
modal form. When the first finally shows, they all stack on screen.
opw-203577
closesodoo/odoo#35098
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Looks like the race condition dates back to the introduction of
"default" export fields but #32339 made it into a hard error (rather
than silently not load the fields): setting / selecting the default
fields waited in the exports lists to be loaded, but the exports lists
are just predefined lists of fields, that's got no relation to the
loaded or default fields, which are loaded (somewhat implicitly) by
_onChangeCompatibleInput.
As a result, if the lookup of the ir.exports was faster than fetching
the model's fields, we'd execute "select the fields from the list
view" before the exports widget knew anyting about the model's own
fields.
Because the old code iterated on the loaded fields and checked if they
were to enable it would just do nothing (as it would iterate an empty
object). Because the new code iterates on the defaults fields and
looks them up in the records map, it gets an undefined and triggers an
error.
Fix by waiting on the proper RPC call.
Reported-by: Andreas Stauder (@BT-astauder)
closesodoo/odoo#35837
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This commit move some code to be able to override
Bootstrap popover in web_enterprise for mobile.
Task ID: 2052506
closesodoo/odoo#35727
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
After editing multiple record, we want don't want any
record selected. This commit ensures that.
closesodoo/odoo#35678
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Fixed crashes/incorrect behaviours in multi edition in the list views.
The solution to these problems was mainly to refactor the function
used to save multiple records.
Before this commit:
- Cancelling the confirmation dialog in multi edition caused
the edited record to be editable but disabled
- Saving an empty field in multi edition triggered a JS error
- Static confirmation message ("saving 0 valid records")
After this commit:
- Ability to cancel confirmation
- Proper error display when trying to save empty fields
- Message consistent with the situation
Adding a line in grouped listviews caused a crash in some cases.
Steps to reproduce:
- go in any grouped editable list view
- click on any "Add a line" cell, but not on the link itself
- press ENTER
Before this commit:
A crash occured. Unable to add a new line. Needed to refresh the page.
After this commit:
Line addition functionnality properly working even when selecting the outer cell
In this commit:
- removed an unused event handler
- fixed an overriden variable used in a subfunction
- fixed a variable mismatch
No bug was induced by these issues until now so it doesn't impact
any behaviour. This is just an extra security for the future.
Pressing ENTER on a button element triggers an additionnal 'click' event.
Since this 'unwanted' click caused some issues in a few cases, we prevent it.
Moreover, there isn't currently any known case in which this event is useful.
Before this commit:
No modification of the initial behaviour on ENTER key
After this commit:
ENTER key pressed in abstract fields has its default behaviour suppressed
Before this commit, there was a slight offset preceding list selectors,
and the red border of invalid fields was not shown in community.
Now list selectors are correctly displayed as well as invalid fields.
Added an option in the Dialog class to give it a function to run
when it's closed by other ways than by its buttons.
Its default value is the "cancel" callback if given, or none.
Before this commit, there was no way to add any callback to run
when the modal wasn't closed by a button.
Now, when exiting the modal by other means (e.g.: "Escape" key),
it will run a given callback.
This change allows direct keyboard navigation between the current action
searchbar and renderer.
Focus can now be toggled using DOWN arrow when focusing the searchbar
or the UP arrow when focusing the top cell/record of a kanban or a list.
Priyanka Kakadiya