before this commit: when field is float type it display too much decimal
precision value, it should be fixed to 2 precision for sample data.
after this commit: float field will display 2 decimal precision value.
task-2318503
closesodoo/odoo#63643
X-original-commit: 61f8ced67992b20edfac139c749ec00939f408a3
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Kamesh Patel <kat@odoo.com>
Before this commit, if the image changed from the form view, it
wasn't updated when coming back to the kanban view (one must
refresh the page).
This commit makes this work by automatically adding the field
'__last_update' to the list of fields to read when there is an
image with kanban_image src in the template.
closesodoo/odoo#58313
Taskid: 2341493
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Before this commit, the "Import" button was available in the
favorite menus of dialogs opened from many2one and many2many field
widgets. It makes no sense from those dialogs.
Task 2376279
closesodoo/odoo#62079
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Issue: display the footer tag from snippet in the modal and replace the
save and cancel button.
Steps to see: Email marketing -> mailing lists -> option icon of a
kanban -> Edit -> Website popups -> add a line
X-original-commit: 073699749401adadeec029de6534b4d205e41067
model_field: name of the FieldMany2One('ir.model') containing the model of the records that can be selected. If its value is different from False, the select will not be displayed.
The purpose of adding this option is to allow the creation of a reference field having its model defined in another field (Many2One).
Task-2195019
A calendar filter's id is the concatenation of "o_cw_filter_collapse_" and the title of the filter.
When title has space (like "Time Off Type"), the id become "o_cw_filter_collapse_Time Off Type", which is invalid.
So, we can't collapse the filter.
With this fix, it replace space by nothing so if there is space in title (like "Time Off Type"), the id is "o_cw_filter_collapse_TimeOffType".
Task id: 2318645
- Resize Year view
- Add "is_hatched" field
- Scroll to current month in Year view
- Hide the sidebar if no filter is present
The goal with Year view is to display it in a single page without scroll bar.
Before this commit, a scrollbar was displayed on the right of the screen.
This results in some data wasn't displayed on the screen.
Now, the year view is scaled to the browser.
That means that all information are now on the screen (without scrollbar).
"is_hatched" is used to hatch date under specific conditions
The goal was that it was not possible to display some information differently depending on a variable.
Now, if a variable named "is_hatched" is set to true and passed to the calendar view, the specific date is hatched.
Task id #2318645
Before this commit, an event was triggered even when no change occurred.
Steps to reproduces:
* Go to Document
* Change to list view
* Go to app switcher
* Select another app that has enough content to be able to scroll
* Scroll the view => Bug
Task ID: 2347584
closesodoo/odoo#63021
X-original-commit: c6c4b9f0e4bae03b51d232ea920de9587d8e2b73
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: rfr-odoo <rfr-odoo@users.noreply.github.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
What are the steps to reproduce your issue?
1. Install "stock"
2. Go to Inventory/Inventory Overview/Internal Transfer
3. Create new record and set manually a date with year < 1000 like "0008-10-10 18:35:00"
4. Save
What is currently happening?
An error arises when saving the record, and it is then no longer
possible to reopen the records or any view containing it.
This also prevents us from correcting the date to no longer have the error
Why is this happening?
The root cause is an inconsistency in `strftime` for years < 1000 [1, 2]. To take it into
account, a zero-padding is needed in the DateTime parser.
How to fix the bug?
The missing padding is added.
However, such dates lead to problematic behaviors in Python:
```
DT_FORMAT = "%Y-%m-%d %H:%M:%S"
new_date = "0008-02-05 18:10:10"
datetime.strptime(
datetime.strptime(
new_date, DT_FORMAT
).strftime(DT_FORMAT),
DT_FORMAT
)
```
This raises:
```
ValueError: time data '8-02-05 18:10:10' does not match format '%Y-%m-%d %H:%M:%S'
```
As of today there was no reported business cases where dates with year < 1000 would be
necessary. Therefore, we limit the range to years >= 1000.
[1] https://bugs.python.org/issue13305
[2] https://docs.python.org/dev/library/datetime.html#strftime-strptime-behavior
opw-2408260
closesodoo/odoo#62889
X-original-commit: b873bda1e560bc49ab707aa238fdc962f23bc1e4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
Before this commit, when the user entered some text in a many2one
and then focused out (e.g. clicked outside), a dialog was shown to
ask him if he wanted to create such a value, no matter what he
wrote in the input.
After this commit, if the search triggered by the text he entered
returned records, the first one is automatically selected when the
focus is lost. However, if it matches no record, the dialog still
opens. The text in the dialog has been slightly reworded as well.
Task 2372480
Closes#61455closesodoo/odoo#62677
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Issue
- Install Sales
- In Sales > Configuration > Settings -> Enable "Sale Warnings"
- Go to Sales > Orders > Customers
- Pick a customer/company
- Go in Edit mode and go to "Internal Notes" tab
- Switch "Warning on the Sales Order" from "No Message" to "Warning" and add any warning message then save
- Press the "$ X Sales" smart button
- Create a new Quotation
- Validate the warning message
- Go back to the previous menu (using the breadcrumb) or save the quotation
- Create a new quotation
The quotation form editor does not appear.
Cause
If we use the breadcrumb (or save then create), it will call the `_reload` function
(instead of `load` when the form view hasn't been opened yet).
In this case, creating a new record, it will call `_makeDefaultRecord` without
setting `allowWarning` param to true (like it is done in the ref. commit bellow).
Solution
Set `allowWarning` param to true before calling `_makeDefaultRecord`.
related commit : https://github.com/odoo/odoo/commit/a41db9a2cf410bb233b021651a5633180eaddf18
opw-2374857
closesodoo/odoo#62608
X-original-commit: d5b5e7c8490e8de9e56f16cdef640dd733163175
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
The kanban quick create is meant to stay open if a click event is triggered
within a modal, which was working for most cases before this commit.
However, there are some specific tricky cases when the behavior is incorrect.
Issues were mainly observed when using the many2one widget inside a quick
create card.
When typing something into a many2one widget and then focusing out of it, the
widget has a built in feature that asks the user if he wants to create the
record (based on options and necessary create rights).
This implies to open a modal asking the user to create or discard his input.
When you combine a many2one widget IN a kanban quick create card, then type
something in the many2one and click outside of the quick create, it triggers
BOTH the focus out event of the many2one and the click event of the kanban
quick create that verifies if it should be closed.
This click event creates a race condition but the following behavior happens
most of the times:
- The many2one 'focusout' is triggered first, creating the modal to confirm
record creation (see FieldMany2One#_onInputFocusout) ;
- The click event is registered second, triggering the quick create check to
see if it should be discarded (see RecordQuickCreate#_onWindowClicked) ;
- The click is technically registered outside of the modal since the modal was
not created yet. This behavior differs a bit between browsers:
- On Firefox the click event correctly targets the actual element that was
clicked (ex: another kanban card) ;
- On Chrome it varies between the actual element (same as Firefox) and
sometimes the raw 'body' element.
- The quick create card will then incorrectly consider the click as outside of
any condition to keep itself open and will close and destroy itself ;
- Which in turn destroys the FieldMany2One and the record creation modal ;
- (If you look carefully on the screen you can see a slight flicker when that
happens).
During all my testing, only one condition will stay consistent when focusing
out of the FieldMany2One by clicking somewhere else: the body element will
always have the "modal-open" class by the time the click event is triggered in
the RecordQuickCreate.
This is why relying on the condition that an element exists with the
"modal-open" class to avoid closing the quick create card provides reliable
results and seems to suit all necessary conditions and behaviors.
Task 2388450
closesodoo/odoo#62561
X-original-commit: 4930871701da2e2792e73ae3941f336046876f0e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Consider the following situation:
- have a form view with an x2many field displayed as a list
- the x2many field has a form view that contains an x2many field,
which isn't in the list
- for that x2many field, we can also open a form view to see/edit
the related records.
As the x2many field isn't in the list, when we open a subrecord, we
modify the fieldsInfo to add the information about the x2many field
we didn't know before. Doing so automatically applies raw changes
that we might have stored earlier (from onchanges) for that field,
because we couldn't apply them before knowing the type of that
field.
Before this commit, the function that applies the raw changes was
called recursively on the dataPoint and all its children (thus on
the x2many list datapoint), which produced a crash as this function
is designed to work on dataPoints of type record.
Actually, calling it on sub datapoints is useless, as it properly
works recursively, and applies raw changes on x2many fields itself
when necessary.
This commit ensures that we don't call this function on list
datapoints anymore.
Closes#62334
OPW 2389991
closesodoo/odoo#62511
X-original-commit: 2b7670e6d709cd311c630c99cb9da7d3d6ae90f4
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The mock implementation of `name_get` does not fully reflect
the real server implementation.
The real implementation is described in tests added in
this commit.
Note: in my wildest dreams, the mock server tests would be run
against the real *and* the mock implementation to ensure they
do not diverge.
closesodoo/odoo#62430
X-original-commit: c8f59bfd5c8ddb7c7abf1108111507e667393208
Related: odoo/enterprise#15017
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
The ControlPanel has been converted in Owl [1], and the code using
it has been adapted accordingly. However, in the FieldX2Many, we
didn't properly wait for the ControlPanel to be updated (an update
of the ControlPanel was synchronous before owl, and is now async,
like every Owl renderings, as it waits for the nextAnimationFrame).
As a consequence, we might have tricky issues because the mounted
hook of the control panel might be called multiple times for a
single call to willUnmount later on. In mobile, we bind a global
event handler (on scroll) in mounted, and unbind it in willUnmount,
so we had leftover event handlers, that crashed when called after
the ControlPanel was destroyed. Note that even if the issue popped
in mobile, calling mounted on already mounted Components isn't a
good idea, and this should be fixed anyway.
The issue could be reproduced for instance in FieldService (with
collaborative pads activated in Project), in mobile, by opening
a task in Edit mode. Then, you might get a traceback by scrolling
after having discarded the edition
Here is a description of what technically happened:
- when clicking on Edit, all widgets (including the FieldX2Many
are destroyed and re-instantiated in 'edit' mode).
- the pad widget directly triggers a field_changed event which
causes a reset of the FieldX2Many (i.e. 'render' is called
again)
- the FieldX2Many detects that it already has a renderer (and a
ControlPanel) so it updates them
- it first updates the renderer, and when it's done, it updates
the ControlPanel BUT doesn't wait for its promise, so the
promise returned by that call to 'render' in FieldX2Many is
resolved before the ControlPanel is actually updated
- note that at this point, all thoses new widgets are not in the
DOM yet
- when all widgets are ready, the renderer patches the view (i.e.
the former content is removed from the DOM, and the new one is
attached into the DOM). As soon as this is done, the renderer
calls 'on_attach_callback' on its children, including the
FieldX2Many, which leads to a call to 'mounted' on the CP.
- then, just before the nextAnimationFrame, Owl complete the
rendering of the CP, and detects that it is now in the DOM (it
wasn't at the beginning), so 'mounted' is called a second time,
will cause the issue described above.
This commit fixes the issue by properly waiting for the CP to be
rendered in the FieldX2Many. However, this required on cascade
changes:
- Form view renderings with a FieldX2Many are now *really* async
(+- 16ms), meaning that the user can easily trigger concurrent
renderings by, e.g. clicking quickly several times on 'Edit',
'Save' or 'Discard'. Concurrent renderings are properly handled
so to prevent this from happening, we disable the buttons and
re-enable them when the rendering is done (like already done in
[2])
- in the FieldX2Many, '_updateControlPanel' was called at several
placed, but we never waited for it. As this method was
originally sync, its calls have probably been naively adapted,
whereas their should have been deeply rethought (for instance,
as it is async, and we need to wait for it, we don't want it
to be called multiple times sequentially when something happens).
This commit does that work, i.e. we clean the places where this
function is called such that it is (hopefully) never called
sequentially twice. To do so, we changed a bit the spec of the
pager in multi page, and we also fixed a paging-related bug.
In a few words, here is what we did/do when adding a new row
in the bottom of a full page:
- before: tweak the count in the data to fool the pager and
make it think that no new record has been added (so
basically, let it display something wrong)
- now: temporarily increase the pager limit so that the new
record is displayed on the current pager, and the pager
values are correct w.r.t. the displayed records.
Some tests needed to be adapted accordingly.
- By waiting for the ControlPanel when updating the FieldX2Many,
a bunch of QUnit tests failed. Those tests have something in
common: they spawn an X2Many (list or kanban theoretically,
but always list in practice) containing a FieldBoolean (only
field widget of /web converted in owl). When the FieldX2Many
is updated, we update the renderer (i.e. re-renderer the
FieldBoolean, so we have to wait for the nextAnimationFrame),
and when this is done, we update the page (again, we have
to wait for the nextAnimationFrame). So basically, we have
to wait for two nextAnimationFrames to see the result in the
DOM. For this, we added a new test util which basically does
a nextTick ('owlCompatibilityNextTick'), and called it
everywhere it was necessary. When everything will be written
in Owl, we could get rid of this util and its calls.
[1] https://github.com/odoo/odoo/commit/fbf347498f1cc7b74ef373179b7bcae201715c24
[2] https://github.com/odoo/odoo/commit/39f08950d6e20460e3a20a5b9c33e4ddf66dce78closesodoo/odoo#61926
X-original-commit: e8e64f75606f1501a8be7b0bb418a296cfd8be61
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When a progressbar filter is activated, it will only show records
matching the filter and nothing else.
"Load more" link will update its counter accordingly.
closesodoo/odoo#55466
Taskid: 2196661
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The mock server was slicing the records before sorting.
Now mocking a search read would sort the records before slicing them.
This will ensure the records to be loaded with the correct sorting order
when e.g. a load more is applied on a subset.
Taskid: 2196661
When the user clicks outside of the kanban quick create element, it's closing
itself automatically.
However, the "hit box" of this behavior is not entirely accurate and clicking
on the very edge of the box would also close the element.
This commit fixes the click behavior and allows clicking anywhere inside the
quick create element.
Task 2373095
closesodoo/odoo#61763
X-original-commit: 72ed82489daa2b82628dfdefeb06262e17e6548e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Remove the icon of the toast elements. Remove the header and move the
title in the body, as simple text. Move buttons at the bottom instead
of at the right side.
Note: this will be refactored with OWL anyway but this is a first step
towards more consistent tips across backend and frontend.
task-2311554
closesodoo/odoo#61756
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When using eg. arabic locale, the figures inside dates were replaced by
arabic figures which are not supported server side (they are almost
always sent in latin figures).
With this changeset, the we are using english locale to get date in
domains.
Without the change, added test fails with:
Numbers in domain should not use addoneForTest locale
Expected:...[date_field, >=, 2020-06-01], [date_field, <=, 2020-06-30]
Result:...[date_field, >=, 3131-17-12], [date_field, <=, 3131-17-41]
opw-2370392
closes#61354closesodoo/odoo#61443
X-original-commit: 74ea66a107cfc98cce8e52903ec21e3d752fb4fb
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit, with an opened DropdownMenu component, when the user
clicks on a Bootstrap's dropdown the DropdownMenu doesn't close.
This issue is due to a conflict between the global click listener
registered to close the DropdownMenu and the listener registered by the
Bootstrap dropdown:
the last one prevents the event from bubbling up to the `window` element
and be handled by the first one.
This commit fixes it by enabling the `capture` flag on the DropdownMenu
global click listener, giving it the opportunity to handling it properly
and close the DropdownMenu.
Note: this commit also fixes an issue when a dialog is opened from a
DropdownMenu (like the favorite's delete action) and prevents it from
closing in the background (e.g. when the dialog is still opened).
opw-1879566
closesodoo/odoo#60928
X-original-commit: 7f1bcc8ceb78729725f65585e923b08f94bf75b5
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Before this commit, when sub widget replaced its el, the ComponentAdapter
parent kept the previous el.
This caused some issues as in the ActivityRecordAdapter which lost its
event listeners when re-rendered.
This commit forces the ComponentAdapter to keep the new sub widget el
after being patched.
task id: 2360021
closesodoo/odoo#60521
X-original-commit: 393b5fd4cfba254ad054a526996e82922f9057e2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Michaël Mattiello <mcm-odoo@users.noreply.github.com>
When opening a DropdownMenu OWL component (like the favorite menu, filter
menu) positioned to the right of the screen (left on RTL languages) on a
small screen, the content of the dropdown could easily overflow out of
the viewport, making hard to use or even unreachable.
This commit fixes it by using the middle of the screen as a threshold to
align the dropdown menu to the right (or left in RTL) of the triggering
button.
Note: this fix specifically targets mobile-like/small screens as bigger
one like on desktop would require much precise calculations (and are
not an issue at the time of this commit).
Task ID: 1879566
When running the webclient in a regular environment, a 'o_touch_device'
class is set when ran on a touch-screen enabled device.
This commit adds the ability to simulate touch-screen when creating a
view inside a test (independently of the device), allowing tests to
match the reality.
Task ID: 1879566
The `remaining_days` widget is intended to be used for informative purpose,
hence it should not be editable.
opw-2362276
X-original-commit: 4c72b1536a19cd517046113a5ad93b5782774664
Introduced at 2f67881d45
Taken an event with
start_date: 2020-10-01
stop_date: 2020-10-02
allday: True
The date was displayed as "01/10 - 03/10 (2 days)" instead of "01/10 -
02/10 (2 days)"
closesodoo/odoo#60254
X-original-commit: 5eed28cf927bc504b103cc872712ab0e49830a38
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps to reproduce the bug:
- In Projects, switch to the calendar view
- Click a task
Bug:
Traceback here: https://github.com/odoo/odoo/blob/7ba47e7215df69b6556a848532e4f33ef4243e83/addons/web/static/src/js/fields/basic_fields.js#L2181
TypeError: Cannot use 'in' operator to search for 'invisible' in {}
Explanation:
We could change the inherited model of CalendarView from AbstractView to BasicView but it would be adding 400 lines of code to every calendar view. So, for now, and to keep it simple, we just parse the modifiers where it's needed to.
opw:2352436
opw:2352890
opw:2354039
closesodoo/odoo#59876
X-original-commit: 422c52a0823b1a53eeb974e76d08a44cacf4ea0a
Signed-off-by: backspac <backspac@users.noreply.github.com>
Commit e10fd34682 introduced batched reference fields name_gets
across groups but was also buggy as follows:
Have a grouped list view showing at least 2 groups
Have a reference field with different values showed in the list for each record
Before this commit, the name_get of those reference fiels were fetched only for the last group
After this commit, the name_get are fetched in a batched fashion (by model) for each group
and display correctly
closesodoo/odoo#59910
X-original-commit: bbb608a1eff638040f0fc7b951fedf1579cc15b2
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Fix the design of he notification which is sometimes broken
(if there are lists or buttons display in it for example)
task-2346462
closesodoo/odoo#59776
X-original-commit: 238654ae53582d791154388c827f725c8d136612
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
A string parameter 'order' has been added to the "sortBy" function of
the utils module to decide in which order the array should be sorted.
The default is 'asc'.
Introduced a function that awaits for an additionnal rendering frame
initiated by the Owl compatibility layer processing.
By default a simple "nextTick" will handle the rendering of any widget/
component stuctures having at most 1 switch between the type of
entities (Component > Widget or Widget > Component). However more time
must be spent rendering in case we have additionnal switches. In such
cases this function must be used (1 call for each additionnal switch)
since it will be removed along with the compatiblity layer once the
framework has been entirely converted, and using this helper will make
it easier to wipe it from the code base.
Before this commit, the pager component would only quit the edit mode if
its value changed when hitting Enter.
Now, when pressing Enter while the pager value did not change, it will
leave the edit mode and trigger a "pager-changed" event regardless.
Task 2318738
closesodoo/odoo#59285
X-original-commit: a3197283d52bfda399ce45b7d5a52406885336d0
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When manually updating the time on a daterange widget, the value sent to the
server is not converted to UTC and is sent as it appears on the input.
currently daterange widget send datetime value as it is, written in input field
if manually entered, so if user set 10:00:00 so while sending data it will be
send as it is 10:00:00 so when next time record reloaded after save, it will
display 15:30:00 if timezone UTC+5:30.
Instead, change the string date to moment object with current user timezone.
so that datetime send to server is UTC time and when next time it is loaded
it adds user timezone difference, so if timezone is UTC+5:30 and user enters
10:00:00 then while sending data to server it sends 04:30:00 and when displayed
again after reload it adds +5:30 timezone difference.
LINKS
PR #50132
Task 2240378
closesodoo/odoo#59263
X-original-commit: a029fca2d0def06ea3f67270f0e1d654d49a0c57
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit: the action menu registry items were rendered
regardless of their inner state. The problem is that these item
components can choose not to render themselves, leading to a blank
dropdown menu if no other item was present.
To fix this, the "getProps" function of the registry has been altered to
act as validation: the item will not be rendered if the return value is
falsy. The function has also been made asynchronous to allow RPC calls.
This solution is still flawed and hides a bad design choice which is to
register components and not items or item getters; this API is too
complex for its use case(s) and adds pointless depth to the DOM. The
shape of the registry should be simplified in an improvement in master.
closesodoo/odoo#59259
Task: 2325587
X-original-commit: 45c7d881a5d130f6b3222749c8c87b6c6b45e910
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
if readonly attribute is given on priority widget then priority widget should
not be clickable and hover effect should be removed so that user can easily
understand that field is readonly.
task-2339680
closesodoo/odoo#59199
X-original-commit: 53dbfc7a65a8eb2f41d6b2373cf628c4800d1f57
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since fbf347498f, when opening a view in a
dialog, the favorite filters were not loaded.
For example on the runbot:
1. In CRM, open any lead, edit it, and open the Customer dropdown
2. Create a custom filter, save it as favorite, and close the dialog
3. Open the dialog again: you don't see your new filter
With this commit, you will see your filter at step nr. 3
closesodoo/odoo#59186
X-original-commit: 418013e8dbb2aa2d4ffd4f650f080ca5a94183f9
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>
And other reported English mistakes in source string
Courtesy of Transifex translators
And remove leftover from gengo
closesodoo/odoo#59022
X-original-commit: 26efc84c5cac47a2cc83d7b084f8b71528fec6c7
Related: odoo/enterprise#13781
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Until now, the numpad decimal key was not properly handled for some
keyboard layouts.
This commit will ensure that when this key will get pressed inside a
numeric field, the user's display language decimal separator will get inserted.
closesodoo/odoo#56962
Taskid: 1913999
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
An older commit (50bf8309) had refactor part of the basic field _applyX2ManyOperations.
During this refactor, the reference field was forgotten to be included
in a condition that made the field no longer do the quick create behavior.
The name_create function in the backend was no longer called.
Adds a test for the reference field checking the call to the name_create
function and fixes the problem.
Task id 2322048
closesodoo/odoo#59044
X-original-commit: 1400b0b9f46a86254c166b422a0b23ed3b3c7a24
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when editing a column in a kanban view, in project
for instance, the translations weren't loaded.
Now, the translations are correctly loaded.
opw-2340125
closesodoo/odoo#58984
X-original-commit: e95ed1253817beccb76d1fbd55b1318b3d65cfe5
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
In general, the last actionManager's operation has priority over hanging previous ones.
This means that the order of the RPC's done by the actionManager is deterministic.
i.e. load_action, load_views
However, when testing the concurrency, some RPC of an hanging actionManager operation
(in this case a switchView to a form triggers a 'read'), may be fired anyway. Those are superfluous
but irrelevant as long as the last displayed item is the one last asked by the user.
This commit fixes the test 'execute a new action while switching to another controller' to not be bothered
with an irrelevant controller's RPC messing with the orders of RPC.
This is admittedly brutal, but justified with the current implementation of actionManager.
closesodoo/odoo#58983
X-original-commit: 4344d50a74b04ffed7a7113e8af2b8ad6800693e
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
PR #45400 disabled the export feature for those who were not in
group 'base.group_allow_export'. However, it only considered the
'Export' link in the actions menu. In list view, an export button
was still displayed in the control panel (next to 'Create'),
whether the user was in the group or not.
This commit fixes this issue.
Task 2348571
closesodoo/odoo#58920
X-original-commit: 7925e30482ad0df4b2a004c223c3eb87f3ce725f
Related: odoo/enterprise#13730
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
After each test, a check is done that there is no leftover in the
DOM. If there are, the suite fails, but there is no indication on
the test that left elements in the DOM.
This commit logs that missing information. We also stop dumping
the DOM when this happens, as it was rather creating noise than
providing useful information (the remaining elements are still
logged though).
closesodoo/odoo#58806
X-original-commit: 598d036b59012af0a95894d759fe3b6276fc8ccb
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Also fix an issue with livechats not being considered in 'chat'
filter of messaging menu.
Task-Id 2282426
closesodoo/odoo#58468
X-original-commit: 631e52536964763bbfe857305f023e5e67084e95
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
- avoid updating default position list in place
- ensure computed position takes into account enough margin with border
- fallback to requested position instead of bottom
Part of task-2270731
closesodoo/odoo#58370
X-original-commit: 3fad17421518732db2085c3eec596600cfe34f03
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
