Currently, if the first week day was Saturday the calendar week view
would possibly get the wrong week.
This is because current heuristic would get date of current week from 6
(Saturday) to 12 (Sunday).
Thus if we were:
- on Friday 14th, we would have a week day ranges: 15-21 (wrong)
- on Saturday 15th, we would have a week day ranges: 15-21 (ok)
- on Sunday 16th, we would have a week day ranges: 22-28 (wrong)
So it would only get the right range when getting range from saturday.
If a week:
- start on monday, the week range would only be wrong on sunday.
- start on sunday, the week range would always be alright.
Added test without the fix fail:
- CalendarView: Saturday week start week mode
The domain to search events in should be correct
(domain range 14-20 instead of correct 07-13 whilst the day was 12th)
- CalendarView: Monday week start week mode
The domain to search events in should be correct
(domain range 16-22 instead of correct 09-15 whilst the day was 15th)
opw-2091448
closes#40244closesodoo/odoo#40327
X-original-commit: 6c3d74846581d6c1bfc0c6e3a7104440515ddbc5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In editable list view, moving to next cell using TAB key crash when the
following field is read-only (i.e non-focusable) and an onchange() event
is triggered.
Consider an editable tree view like this:
<form>
<field name="o2m" onchange="1">
<tree>
<field name="description"/>
<field name="date" readonly="1"/>
<field name="type"/>
</tree>
</field>
</form>
1. Adding a new line will give focus to `description` field widget
(currentFieldIndex is 0)
2. issuing a TAB keypress, will call _onNavigationMove which calls
_selectCell() with fieldIndex of 1
3. The _selectCell() method set widget currentFieldIndex to the new value
(currentFieldIndex is 1) add call _activateFieldWidget() to activate
on the corresponding widget.
4. _activateFieldWidget() will fail to activate the `date` field as it's
readonly, then try for next ones and succeed to activate the `type` field
cell
5. When focus is given a `type`, the `description` field is blurred which
trigger an onchange() and the controller apply those changes to the
editable list rendererd using the confirmUpdate() method.
The confirmUpdate() will try to get the current selection, but that
field is actually set to the `date` field (currentFieldIndex = 1),
which is readonly and so has no focusedElement - triggering the crash.
This commit ensure we don't try to call getSelectionRange() it current widget
has no focusable element.
OPW-2075229
closesodoo/odoo#39976
X-original-commit: 93c7ae9ba5309810c41c58fc8f2fafb3c3dac76e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In this commit, we remove the lazy loading currently used by the mobile
kanban view to avoid the poor user experience. We had to wait each time
we swiped between kanban columns.
Now all data are fetched like in desktop. Note that it might still have
loading during the swipe for folded columns.
Task ID: 1896614
closesodoo/odoo#28142
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
In form views, when the window size is too small, a "More" button
appears and it should contain the overflow buttons.
On all browsers, the "More" dropdown doesn't contain the expected
amount of buttons, so it is shifted on the second line.
Before this commit:
- The "More" dropdown doesn't contain the expected amount of
buttons, so it is shifted on the second line.
After this commit:
- The "More" dropdown contains the expected amount of buttons
and it is not shifted on the second line anymore.
OPW-2079694
X-original-commit: 2bda8230fba07a229fcda77a1528694a0e317917
Be in RTL mode, on a list view
Click on the button to set up optional fields
Before this commit, the dropdown expanded to the right, and was partly invisible
After this commit, we dynamically set to which direction the dropdown should expand
depending on RTL/LTR
Consequently the dropdown is fully visible in either mode, and expands to the list
rather than away from it
closes#39402closesodoo/odoo#39628
X-original-commit: fb914d176de5a4711f11de32945ebaec0164f62e
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the calendar searched records on the wrong time ranges
which did not take into account the timezone of the user
It obviously resulted in some records not being there
After this commit, all the relevant records are fetched according to the right
time range in UTC, corresponding to start/end of the week/month/day of the calendar
OPW 2076114
closesodoo/odoo#39466
X-original-commit: 0f10927efe490bd82e7c23e0fc646dd6c8de2d27
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, all the computation of the default widths for column
headers was done before the list was attached to the DOM, meaning that no
column was actually visible. This was a problem since columns that are
meant to stay unseen were taken into account in the calculation of relative
column widths.
Now, the same algorithm runs once the columns are visible so that invisible
columns can be properly excluded.
fixes#38744
Task 2076721
X-original-commit: 4bf98b47898b075049975dfe597f0fb92c7c14d1
Before this commit, the `width` attribute was interpreted by a jQuery node generator
function as a `style="width"` property and gave an incorrect width value to the affected node.
Now, the `width` attribute is automatically plucked in the list renderer in the
specific function used to render buttons.
Task 2076721
X-original-commit: c67b36c00ca263f51e0dd49d6e38702c4d614289
In a list view, create a custom filter involving a date or datetime field
Before this commit, the domain that was sent to the server
contained the date or datetime as the pure string
representation that Moment.js constructs
that is a ISO compliant one, containing info on timezone
After this commit, the format is the one of the server, in UTC
and NOT ISO compliant. Also, the format for date is dealt with
OPW 2085936
X-original-commit: 1f1fa173c38dae105637edeb3a1e856e9748a14f
Before this commit, when we have a list (editable top) in a form
with some mandatory fields and some existing rows. If we click on
'add a line', a new empty line appear on the top, then we click on
the last row, the empty row will disappear and we will have a
traceback.
After this commit, if we repeat this scenario, we click on the last
row, we will be able to edit this last row.
closesodoo/odoo#38471
X-original-commit: 996f77b03eaf6dd646b1816e7f70209d5ee6f8df
Signed-off-by: jbm-odoo <jbm-odoo@users.noreply.github.com>
Allows the quick create on m2o in list views
Before this commit, when entering a new value in a many2one in a list and
exiting the cell through a click, the quick-create modal appeared for the
duration of the mousedown.
Now, the modal remains and allow to edit the new many2one value
Task 2076380
closesodoo/odoo#38289
X-original-commit: c00f84eb0a176b8d23927080078eb02dc2e5d806
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
We don't want the browser to fill inputs in the backend.
Most of the time this is useless but sometimes it is
even problematic. For example, focusing an input in a
modal can trigger autofill not only in the modal but
also in the whole page. If there is an input outside
the modal and it is recognized by the browser as a
candidate to fill, bad things occur.
For that reason, we set the attribute autocomplete to
"none" by default for input elements.
Note that "off" does not work all the time because
the browsers sometimes decide to ignore it.
Task ID: 2076730
closesodoo/odoo#38039
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
This commit adds a test case for the recently introduced 'records_draggable' option in the kanban
view.
Initial test was not written because of social app rush before 13.0 release.
'records_draggable' feature introduced by 869a5b83a5
Task#2082068
closesodoo/odoo#38166
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The feature that allows res.lang's first day of week parameter
to be the reference point of web calendar
has been introduced at 27b30daea5
A few other came on top of it to fix a few things
Before this current commit though, only Fullcalendar was
rendered using that initial value, nothing was done
to actually fetch the right data
After this current commit, we fetch data from the server
according to the range displayed by the calendar
OPW 2072872
closesodoo/odoo#38131
X-original-commit: 0bd82ef6489f3ea1da26fb6ee337b15e3f13d4e5
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, invisible filters were rendered by
QWeb but hidden in the filter menu. This used to break
the keyboard navigation in the filter menu.
Now we don't render at all those filters since they were
completely useless anyway. This fixes the original
problem.
Task ID: 2057012
closesodoo/odoo#37567
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Changes the behaviour of many2ones when their value is changed via a form dialog.
Before this commit, when editing a m2o with a form dialog opened by an external button,
the field triggered an onchange with its old value before reloading its widget.
This caused the edition in list views to display outdated information when
saving multiple records.
Now, the reload is executed first, then the onchange occurs so that the value is
the newly updated one.
Part of task 2078807
closesodoo/odoo#37576
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, m2m fields were not updated when multi editing
in a grouped list.
Now, the fields are updated no matter how many levels of groupBys
are applied to the list.
Part of task 2078807
closesodoo/odoo#37589
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
only activate multi-edit on list with specific attribute.
When the attribute multi_edit="1" is set on the tree view the user
can select a/some records and it will activate the multi-edit
with confirmation dialog (even for a single record).
Also, on-change are not applied when using multi-edit
closesodoo/odoo#37525
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Create a simple subclass of AbstractAction (a client action), with
property hasControlPanel set to true. By default, the name of the
action should be displayed in the breadcrumb. Before this rev.,
it wasn't the case, as it displayed 'Unnamed' instead.
Bug spotted when doing an exercice for the JS smartclass.
closesodoo/odoo#37465
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
*:board,hr_skills
Hold on tight, this is a tricky one.
Allows *any* readonly list view (only plain lists, not x2manies) to
become partially editable when checking records.
This means that once checked, a record line acts just like it was
in an editable list. You can click on it, edit any of its values as long as
they're not constrained by readonly modifiers, and save them on the fly.
Clicking on an unchecked record will have the same effect as before:
it will open the record, regardless of the other selected records.
You can also check multiple records and edit them all at once by
changing the value of one selected record (just like standard multi edition).
Keyboard navigation is also allowed between selected records (TAB and SHIFT+TAB
to navigate and ENTER to save).
/!\ If a list is only made of records having all of their fields locked by
readonly modifiers, checking a record and clicking on it will do absolutely
nothing. This is to keep consistency with the rest of the specs.
Task 1967602
Changed the information dipslayed by the confirmation modal in multi edition
in list views.
Before this commit, the modal simply showed a one-line message with the amount of valid records.
Now, there are 3 elements:
- If all of the fields cannot be changed, a first line warns the amount of valid records.
- A second (or first if all fields can be updated) line ensuring that the user is aware of
the occuring changes.
- A table displaying the affected field and the updated value (readonly widget with the new value).
Part of task 1967602
In an editable list, select a very long value in a many2one...
Before this commit, the table stretched as much as it needed to to
display all of the columns content.
Now, the largest columns are trimmed in order to keep the table
as wide as the list container (meaning it won't overflow anymore
unless there is a huge load of columns).
Also ensured that values trimmed by this feature are followed
by an ellipsis.
Task 2068261
Co-authored-by: Aaron Bohy <aab@odoo.com>
Before this commit, resizing a column would cause the
list to develop a mind of its own and to grow/shrink random
columns according to its own will.
Now, resizing a column does not "freeze" the list anymore and simply
gives a static width to the resized column.
Let's assume an editable list view with at least two rows. Before
this rev., the column widths were re-computed and frozen each time
a record was switched into 'edit' mode. As a consequence, if the
user clicked on a row, and then on another one, column widths might
slightly change.
Task 2068261
This commit fixes:
- body of a email.template in a small field
- translation of website_description of a product does not show the
source of the translation
- translation of website_description of a product shows the full
content for the current language
HTML fields are typically fields with longer of content.
If the field is an HTML field, it should be displayed in a textarea,
like the text fields.
Most of HTML fields are split in meaningful chunks of content (using
xml_translate or html_translate method).
For these fields, the source must be displayed.
Also sort the entries on the source to have a consistent order
closesodoo/odoo#37215
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Since fbbfa6d it's not longer possible
to write a date without separator (e.g., 0102 for 01/02/2019; 121298 for
12/12/1998; 02042018 for 02/04/2018), or a date without year (e.g.,
01/02 for 01/02/2019) in the datepicker widget.
In this commit we have decided to be as permissive as tempus dominus
that call moment.js with strict false. This allows moment.js to deduct a
date from a string in a more versatile way. This also allows a more
versatile autocomplete in the search views.
opw-2070464
opw-2070931
closesodoo/odoo#37095
Forward-port-of: odoo/odoo#36821
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Changed the way the header selector behave when the selection changes.
Before this commit, the header selector was only checked when clicked and
was unchecked as soon as any other record was unchecked.
Now, the header selector reflects the current visible selection:
if all of the other visible selectors are checked, it will be checked.
Folded records are not considered visible, thus only records from active groups
and from the current pager will be taken into account.
closesodoo/odoo#36522
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Added handling of invalid format types in multiple edition in list views.
Before this commit, in multiple edition, a field that was edited with an invalid value format
(e.g. a numeric field receiving a string value) didn't trigger a field_changed and no prompt
was shown; the record was simply idle with an dirty value.
Now, the list controller also listents for set_dirty events and automatically triggers
an error modal + discards all changes when receiving one.
Onchanges make no sense in multi edition as they would be computed
on the 'reference' record (the one use to edit), but applied on all
selected records. This rev. simply disables them in that case.
Task 2068280
Gave back focus to the last edited cell to increase usability with key nav.
Before this commit, after saving several records with multi edition in a list,
focus was lost (given to the body).
Now, last edited cell is given back the focus after multi editing.
Having those inputs enabled can lead to weird situations where a
record has been modified but can't be saved anymore (because the
user clicked on one of those record selectors to focusout the edited
row). Also we don't want the user to start multi-editing a field,
then change the selection, and then validate the changes.
Task 2068280
Before this commit, if a record was selected and another one was edited,
it was considered as multi edition.
Now, the multi edition only works if the edited record is included in the
selection; else it will be the only edited record (single edition).
Task 2068280
...when validating last row by pressing ENTER.
In single edition, we automatically add a new row when the user
edits the last one and presses ENTER. This is something we don't
want in multi edition.
Task 2068280
Fixes the way many2one fields are rendered in editable list views.
Before this commit, many2ones in readonly mode would render as links
and their widget would be considered as active even though you couldn't
edit it.
Now, they are rendered as plain text and act the same way as readonly char fields.
Fixes the way records are discarded in list views
Before this commit, clicking the "Discard changes" button in a list view
after editing a record triggered both the "field changed" and the "discard changes"
methods (resulting in 2 modals opening).
Now, all fieldChanges are prevented when trying to click "Discard changes",
and are re-applied if the click was unsuccessful (lifted left mouse button somewhere else).
Task 2068280
Let's assume an editable list view with a many2one field and 2
records: the first one has value 1, the second value 2. The user
selects all records and wants to set their many2one to value 1. It
edits the first one, sets 1 and validates the confirm dialog.
Before this rev., it didn't save anything because the 'reference'
record (the one used to edit), didn't actually changed, as we reset
the same value.
This rev. forces the write the new value on all selected records in
that case.
Task 2068280
Backport of 10eaf74230
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
Backport of 1f2c64013
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
Have a model with a parent field
Set his parents like
Parent 0
|
-- Parent 1
|
-- Parent 2
Now, put the Parent 1 as inactive
Open a view with a search panel, which will fetch the parent field as categories
Before this commit, it crashed, because the inner record memory
did not contain a reference to the parent of Parent 2
After this commit, it doesn't crash, and the search panel
just doesn't display parents categories that are archived, nor any children of those
OPW 2070266
closesodoo/odoo#36699
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Purpose
=======
The commit 2849b5c introduces a new export mechanism of grouped
list views to xls files.
The issue with this development is mainly that the displayed records
are exported, instead of all the records that match the search
parameters.
To export all the records we cannot rely on the data from the web
client. This implies to revert 2849b5c, and implement it in a better
way.
Functional Spec
===============
Add the support of grouped exports.
Allow the user to export all records in one click from
the listview, without having to go through the export modal,
taking into account the domain, groupbys, and visible fields.
Technical Spec
==============
When exporting (whether it is from the modal or from the shortcut),
any groupby(s) set on the listview should be taken into account (all unfolded)
- UNLESS the export is import-compatible
- each subgroup header has an indentation compared to its parent
- the 'group headers' in the exported file should contain the
same info (label, field aggregates) as it has in the listview.
New secondary button on the tree view with label 'EXPORT' (to be confirmed...)
- the export shortcut disregard the selected records, it exports all records
according to the domain.
- the button is visible even if there is no selected records.
- essentially the export shortcut does the same thing as the following:
- select all records
- hit 'action' then 'export'
- hit 'export'
Define a boolean attribute on <tree> to specify whether or not the export
shortcut should be displayed
Task 2072910
closesodoo/odoo#37087
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Thought there was a bug, but it's actually working fine, so no fix
needed, but the test is written (and it doesn't exist yet), so we
keep it.
Also fixes a selector to make an assert relevant in an existing
test.
Nicolas Lempereur