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
This commit adds a link to each calendar.event to join a video call
hosted on Jitsi.
TaskID: 2367543
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#61280
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
Sometimes we want to limit selection of 2many fields to a single record at
a time. For example when creating marketing automation activities we want
users to create them one at a time to ease linking between them (parent /
children relationships). Indeed 2many subrecords have to be created before being
selected in other 2many subrecords (i.e. create an activity to set it as
parent of another activity).
SPECIFICATIONS
The open_one2many_record trigger method now accets disable_multiple_selection
option in parameter to pass it to the FormViewDialog constructor.
LINKS
Task ID-2087993
COM PR odoo/odoo#40177
ENT PR odoo/enterprise#6675
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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>
Some actions use 'non-standard' key in the action dict, to pass extra
parameters. In that situation the filtering of keys in `clean_action()`
strips valuable params, in an attempt to avoid leaking internal action
data.
One example of this is the dynamic action definition returned by
`open_yodlee_action()` in the account_yodlee module, which uses several
non-standard properties.
This commit alters the filtering logic in order to allow extra keys by
default, as long as they're not actual fields of the action model (and
therefore should not cause unintended "internal data" leaks).
A warning is also added to recommend passing those extra parameters in
the `context` and `params` action properties, which are explicitly
designed for this, by convention.
For cases where extra properties are returned and where the warning is
annoying, those properties can be explicitly _allowed_ by making them
virtual action fields, through a `_get_readable_fields()` override.
X-original-commit: 5cc3a6f2307be617c51e8d9c5f167acc60cc6287
5c4544fb29 reordered some of the
operations at the export toplevel, and in doing so moved the filtering
of the xid out of the `fields` list *after* that fields list has been
used to know what fields to export.
Meaning the fields list isn't filtered anymore, and requesting the xid
on a view would blow up due to a latter assertion checking against
that.
Fix the filter, although a better solution might be to strip out the
field upstream (in the fields list provided to the export wizard) such
that users wouldn't even attempt to perform this export.
An other possibility (possibly combined with the previous) could be to
only strip out the export of the xid based on the absence of an
``id`` field on the model, though that's somewhat risky: technically
views have no reason to be stable so a "record" could disappear or
move around without the ORM being aware, leading to dangling xids.
Fixes#46674closesodoo/odoo#62995
X-original-commit: adc25bcf67438675bc9b0d55975ce733d58b4fb5
Signed-off-by: Xavier Morel (xmo) <xmo@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>
Done for res.partner.bank, res.company and board models. Some override may
have been ignored because heavily linked to business code (like company
in stock).
See merge commit for more details.
Task ID-2330149
COM PR odoo/odoo#61246
ENT PR odoo/enterprise#14561
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>
The copyright part of the footer could be edited but not saved.
Now it can be saved.
closesodoo/odoo#62614
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
search_utils only allows to filter on last 3 months, in
spreadsheet we want to be able to filter on all the months
therfore we construct the datedomain manually and we need
the function constructDateRange to be able to do so.
task-id:2340623
closesodoo/odoo#62580
Related: odoo/enterprise#15042
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.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>
In the 12.3 editor revert, the handler for the getRecordInfo event was
removed, but the code that triggered this event was forgotten and now
doesn't do anything. This commit removes this dead code.
closesodoo/odoo#49126
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.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>
Same change in several areas where translations existed:
- website editor notification popup
- elearning share popup
- forum remediation filter popup
- event registration attendees popup
- portal rating popup
- stripe payment error popup
And many other locations where there were no translations yet
"×" has been replaced by its UTF8 character.
Also introduced aria-label where missing.
Before this commit the close icon was included in translated resources.
For example, in Spanish the "×" had been turned into "&veces;"
thus not rendering an icon anymore
After this commit the close icon is not a translated text anymore and
remains an icon across all languages
https://github.com/odoo/odoo/pull/60186
task-2312878
closesodoo/odoo#62250
X-original-commit: 9896af94ebc887d98ccf44e6568ef7eeb5a27172
Related: odoo/enterprise#14937
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Create a product with:
Cost: 60.80
Quantity On Hand: 999.0
- Go to Inventory / Reporting / Inventory Report
- Export as XLS
The header values have too many decimals: 60739.2000000007
The root cause is `convert_to_cache` returns this value:
https://github.com/odoo/odoo/blob/042298f8c949fba470eda6ad90f94c95ca291030/odoo/fields.py#L1333
In this case, `currency.round()` keeps the extra digits. Since the field
is not stored, the useless digits are kept.
A simple solution is to use `float_repr` on the non-stored float fields
to make sure that doesn't happen. Another solution could be to not
convert the floats to strings, but that doesn't seem intended.
opw-2378895
closesodoo/odoo#62265
X-original-commit: 2ebcbb16f113dee1416097b7a52f8068a40a34cf
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The `Adyen Account` menu entry leads to an external page.
This cannot be tested by the click_all test.
closesodoo/odoo#62269
X-original-commit: bcbbe3dd80bfe50bf897ce620da0bd7ddb3c3094
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Since odoo/enterprise@93ac6e5116 a the `Add Bank Account` menu is using
an new proxy server. As it's an external service, it's not desirable to
click on this menu during the test.
closesodoo/odoo#62157
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.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
_getUngroupedListDomain
can be used to extend the domain of a search_read for a list resource
_getGroupedListPropsToKeep
can be used to extend props to keep from a previously existing list resource when a read_group occurs
Taskid: 2196661
Currently, in the user setting, hovering on the live chat input will
focus on the signature div due to long height of the empty svg.
So in this commit fixes the issue by adding the css property in the
svg element of signature widget due to that svg element contains the
proper width and height.
closesodoo/odoo#61897
Taskid: 2361880
X-original-commit: 6fe2a0b8b6f8dadb2eb7008019f2d7266dcf6fb1
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit:
When trying to send the notification for the user form, it shows a traceback.
This is happening after https://github.com/odoo/odoo/commit/ab4000fb3cf8fa54ba714ceceec391b78d73755e
After this commit:
Send the notification without any traceback as handle
the MailDeliveryException inside CrashManager
Task-2333121
closesodoo/odoo#61832
X-original-commit: 3aadcf1ad42e704c369910628a1549d1e777c959
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
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>
Before this commit we didn't notice when the dropdown buttons were
disabled or not.
Now, we do the same as on desktop:
the text color is gray when you aren't able to change the stage.
Note that the previous css selector didn't worked because
we are in a dropdown on mobile.
Task ID: 2348528
Before this commit, the intent was to change the border color
of the first button that appears when the status bar is disabled.
The problem was that this added a border for all buttons and
not only the (visually) first one.
*: web, website
Make the empty oe_structure messages "wizz" when the user clicks on a
snippet to drag instead of dragging it.
Note: also rename the "_onSnippetMouseDown" handler to not confuse it
with this new "_onSnippetClick" and add the missing documentation
comment for it.
Part of https://github.com/odoo/odoo/pull/60837
Related to task-2363616
closesodoo/odoo#61724
X-original-commit: bdfddace29b16404c06a7ebfc0cc242463a0e768
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Small refactoring to allow calling the method to update the debug
manager action independently from `current_action_updated`. Needed for
3d80ff9998dd402ac48d280e5d6b81aaf91b6180.
opw-2365539
closesodoo/odoo#61491
X-original-commit: c4e1cfc527cf65fdad201b77e54bf7027b8dd6c2
Related: odoo/enterprise#14639
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Fix traceback when creating a new contact by checking the id list is not empty
Filter default reporting by name rather then by campaign (as campaign is an option)
Group by Campaign only if the option is checked to enforce coherency.
> This is unblocked with a group.
Hide the 'replied' status from sms reports as it is not relevant for sms.
Remove the preview message for sms as it is not relevant elsewhere then the object of mails.
Warn the user if he's trying to send a sms with only white-space characters.
> this causes an error because the plaintext-html conversion in mail_thread.py
> consider a white-spaces-only text as empty.
Mobile placeholder added for a better understanding of the field by the user.
Task ID : 2302578
closesodoo/odoo#61461
X-original-commit: e6496af1ea31b2c699de9e41196a9ae3a07efb7f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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, when adding a icon to a statusbar button, there was no
margin between icon and text. This makes button not very nice as button is
very near to the text itself.
After this commit, for readability purpose, a margin has been added to the
icons of a statusbar button. Statbutton margin has been chosen to keep
things coherent through form buttons.
LINKS
Task ID-2083049
COM PR odoo/odoo#49129
ENT PR odoo/enterprise#9715
UPG PR odoo/upgrade#1883
WHY: you may have wrongly compiled assets for reports (e.g. if you didn't have
rtlcss installed on first run)
closesodoo/odoo#61324
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Previously, in multiple modules, long names would result in an overflow of text.
With this commit long texts should appear like this: [aaaaa...] instead of
going out of their boxes.
Various views are updated, depending on which fields we wanted to prevent
from overflowing and the probability they do so.
Task ID-2325219
PR odoo/odoo#57713
PR odoo/enterprise#13226
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
1. Go to Project
2. Filter > Add custom filter > Last Updated on
3. Click on the date field and use the date picker to change the value
4. The dropdown is closed and you lost your selection => BUG
This bug was due to a conflict between owl and bs dropdown (e4f87710),
to prevent this bug, we added a check to ensure there are no open
bootstrap calendar inside the current dom.
Note that if you click outside the dropdown, the datepicker is already
closed when you go through this code. It means that the datepicker will
not be present in the DOM anymore and the dropdown can be closed too.
opw-2373573
closesodoo/odoo#61262
X-original-commit: 73dfc1f7a8e2197fcdd4053ec57c260576593a15
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: res-odoo <res-odoo@users.noreply.github.com>
Issue
- Install "Project" modules
- Set user language as "Hebrew"
- Go to Project and open any project
- Go to 'gantt' view
- Try to resize a task
Everything is reversed.
Cause
Jquery-ui 'resizable' widget do not manage RTL feature.
Solution
Update the the `position.left` props according to the language
direction (LTR or RTL).
opw-2367692
closesodoo/odoo#61082
X-original-commit: 1f318d7c7aa66287c8756a89b49293b4e8c2217e
Related: odoo/enterprise#14507
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.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>
This commit adds an easy improvement fixing a page speed warning: the
font awesome font (declared in a font-face in assets_common) can be
preloaded.
The only problematic point was that font-awesome defines the font by
a series of URL using different font formats. Only one can be
preloaded (otherwise you would load files for no reason). As all Odoo
supported browsers use the woff2 format, we only preload that one. At
the cost of a warning for other browsers which use a different format.
task-2350647
closesodoo/odoo#60715
X-original-commit: 60c787679260a97c58f399af1a51d7549429f979
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Giacomello Nathan