Before this commit, we waited for 10 seconds before defining the
boot test (checking that all JS modules have been correctly
loaded). However, small test suites (like the mobile one) ended
before this test was defined. So we could end up with a green
branch with tests not being executed (e.g. if a testing module
had missing dependencies, and was part of a small suite).
This commit removes the boot tests and instead does the check
at the end of the suite, before logging that the suite passed.
closesodoo/odoo#50109
X-original-commit: 048557eef32df94715ab464614c9d9d34c4a2689
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, some elements in the control panel were not properly encapsulated
in layout-related parent elements and this caused some inconsistencies if some of
the control panel components were not displayed. For example: if the breadrumbs
were missing, the search bar went to the left side instead of the right.
Now, all components are in a grid-like structure (in desktop mode) and should not
overstep their given boundaries. The layout in mobile remains unchanged since the
top part behaves quite differently.
closesodoo/odoo#50057
X-original-commit: 533db5991a5bb871198485cd71a63f75a8c6becf
Related: odoo/enterprise#10148
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Before this commit, when re-activating a previously active notebook tab, the form
renderer would assume that a tab was actually active. However this does not happen
if no tab is visible or defined and it results in a crash instead.
Now, if no active tab is found, a default active tab (0 = first) is set. This only
helps to prevent the crash and does not affect the current behaviour.
closesodoo/odoo#50006
X-original-commit: 73e0c0a1395ebd0e2b4ac7f857c863a0358c5e17
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Have a list view with an Owl field component (e.g. widget="badge"),
visible. Open the optional field dropdown and make another field
visible.
Before this commit, the '_onToggleOptionalColumn' handler was
executed twice, because two click events where triggered: one on
the label, and one on its associated input (because of the for
attribute, see [1]).
As a consequence, the new field was added, and directly removed
from the view. This could even cause subsequent crashes.
The difference between an Owl component and a legacy widget is
that the Owl component is async (more than a nextTick) as we wait
for the nextAnimationFrame to render. When the rendering is fast
enough (e.g. without Owl components), the click event isn't remap
to the input yet (because we empty the list HTML node), so the
handler is executed only once.
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/label
Issue reported on task 2204306
closesodoo/odoo#49920
X-original-commit: b02d347e8770835ad28a6487071930a904bce101
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When an element is clicked during the test and a tiemout occurs, message
that appears in Odoo logs is not really clear.
closesodoo/odoo#49907
X-original-commit: 0e1545c52fdca6d311a18533d3d4efed984df329
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Before this commit, the result of our custom qunit assert
'doesNotHaveClass' was incorrect when it was called with
several classnames.
For instance
assert.doesNotHaveClass(<span class="a"/>, 'a b');
passed, whereas it shouldn't.
closesodoo/odoo#49892
X-original-commit: c40fc67a130ae8e0f061a89d3a21d2507a0f9ae3
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Currently in kanban view which contains search panel when user click
on kanban dropdown menu then a dropdown menu will be hidden due to
scrollbar of kanban view.
This issue arises from this commit:
https://github.com/odoo/odoo/commit/a95cbbd631a2fa9be62eb42cba43e853fdf4b789
closes odoo/odoo#49791
Task-id: 2204306
Closes: #47586
X-original-commit: d613bb8ba4f5a4d818592a80f4aee2ef67916bc0
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, the 'selection' fields were treated like 'char' fields in the
"Add Custom Filter" menu of the control panel's filter menu. This meant that their
value was defaulted to "".
Now, the default value of a selection field is its first selection value.
closesodoo/odoo#49772
X-original-commit: 62b62570725bc8eb3d3fa77fd1e8efd7a4fb5d2b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
This commit introduces a new option in fields inheriting from type Numeric
which is `format`.
By default, Numeric fields are formatted according to their subtypes and locale
Adding, in a view, the option format set to a falsy value
will prevent the field's value from being formatted.
```
<field name="int_field" options="{\'format\': false}"/>
```
Task 2050119
Before this commit, the SearchPanel widget was given a single unified domain coming
from the view/controller. The issue was that some modules injected additional leaves
in this domain and there was no way to remove them/separate them from the original
view/controller domain.
Now, another paramater (the `viewDomain`) is given to the SearchPanel, containing
the distinct domain related to the view. The Lunch module has been adapted to give
the `location` domain through this new key.
Note that some tests steps had to be inverted since the method retreiving the
domain of the view/controller is asynchronous (needed by Lunch to give time to the
model to be loaded). It mainly concerns the RPC order which does not matter in this
case.
Task 2239706
closesodoo/odoo#49720
X-original-commit: e895e553899933be14c8abfd8c676b44a7f534d8
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
There's a traceback when we edit an activity on a campaign
* Create a child activity
* Save the activity (not the campaign)
* Edit again the activity
* -> Traceback
Introduced in a9cebd5
Task ID 2220930
closesodoo/odoo#49698
X-original-commit: efa8952c39b0bcb0969013dc22e05b5d61ff1c66
Related: odoo/enterprise#9964
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, restoring the previously active tab on a form view was done
through programatically clicking on the tab and letting Bootstrap handle the switch
itself. This caused some cases of race condition since the click handler is asynchronous.
Now, classes are applied manually and should not cause any concurrency issue.
closesodoo/odoo#49668
X-original-commit: 214b842cba030f451430ff0d8c3fc1868be515e9
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
This commit replaces the use of utils.patch by the new class patcher and
makes the renderers that are converted to owl patchable.
closesodoo/odoo#47700
Related: odoo/enterprise#9551
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit implements a new way to monkey-patch ES6
classes (for instance, Owl Components).
Usage
-----
odoo.module('module.BaseClass', function (require) {
const patchMixin = require('web.patchMixin');
// Define your class as usual
class BaseClass {
constructor() {
this.foo = 'foo';
}
bar() {
console.log(this.foo);
}
}
// but export it like this to have a "patchable" version
return patchMixin(BaseClass);
});
odoo.module('module.Patch', function (require) {
// imports the "patchable" version
const BaseClass = require('module.BaseClass');
BaseClass.patch('key', T =>
class extends T {
constructor() {
super();
this.foo = 'patched foo';
}
bar() {
super.bar();
console.log('patched bar()');
}
}
);
});
odoo.module('module.instance', function (require) {
// imports the "patchable" version
const BaseClass = require('module.BaseClass');
const obj = new BaseClass();
obj.bar();
// if module.patch is loaded before this module the patch
// will be apply and calling obj.bar() will log:
// patched foo
// patched bar()
// You can unpatch a patchable class
BaseClass.unpatch('key');
});
While the edit mode interface is full of useful things, it also adds a
lot of clutter, and alters the page's width and thus, its layout. This
commit adds keyboard shortcut for website editors to use, and allows
them to enter a "fullscreen" mode that hides the editor interface while
remaining in edit mode, allowing the user to have fewer distractions
while editing text content, and a closer rendition of the page's final
layout while editing.
For this, keyboard shortcuts were required, and a few other useful
shortcuts have been added, such as alt-1,2,3 for the navbar, just like
in the backed.
task-2126915
closesodoo/odoo#46953
Related: odoo/enterprise#9295
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
For testing, we use helpers functions like testUtils.dragAndDrop().
Due to the commit odoo/odoo@de924f41ee
these methods were wrapped by a deprecated function to add a deprecation
warning in the console when these methods are used.
After this commit, the deprecated method will properly propagate the
returned value of the original function. And so if the returned value
is a Promise now we can await this Promise.
This should fix some false positives on runbot in saas-13.3 (e.g. FullCalendar).
closesodoo/odoo#49611
X-original-commit: 33bfe175bf1ba7824a1bef27fd7fa0898dbe8cb3
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit fixes the kanban view to render components.
Before this commit, when rendering a component an error was thrown.
closesodoo/odoo#49525
X-original-commit: 29c18b53af26752079a49e4ece2419f62f680b5d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Using bootstrap popover with owl is possible, but with a lot of
friction.
This commit adds a Popover element to ease developments that require
a popover. This component takes 2 props:
- position='bottom' (optional): 'top', 'bottom', 'left', 'right'
- title (optional)
Its usage requires setting an `opened` slot for the content of the
popover, whilst the 'trigger' of the popover uses the default slot.
E.g.
```xml
<Parent>
<Popover>
<t t-set="opened">
<p>You have opened the popover, congratulations!</p>
<button t-on-click='_handlerOnParent'>Dispatch cake</button>
</t>
<button class="btn btn-primary">Click me!</button>
</Popover>
</Parent>
```
Note that:
- only one popover can be opened at a time (opening a popover will
close any previously opened popover)
- `Popover` uses `Portal` under the hood, so events are propagated
correctly even though the popover is teleported elsewhere in the dom
(see example in this commit message with `_handlerOnParent`)
- `<Popover>` is registed as a global component in QWeb and does not
need to be added to a Component's subcomponents list
closesodoo/odoo#47710
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
A long time ago, commit [1] increased the limit of displayed badges
inside a many2many_tags widget, from 40 to 1000 (a large limit that
should never been reached with such a widget).
However, this solution was specific to the many2many_tags widget,
and didn't apply to its extensions (like the many2many_tags_email
widget). For instance, open the chatter full composer, add 40
partners in the recipients field and try to add one more: nothing
happens.
This commit sets the limit on the widget itself. That way,
extensions automatically have the same limit, and can override it
if needed.
[1] d4cf4374d1
Task : 2091027
closesodoo/odoo#49488
X-original-commit: 02e41f1131b4ea3ad977cc241a3d447c37195f6e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- install timesheet
- go to general settings > set documents layout to use 'external_layout_boxed'
- go to timesheets > list view > select all > print > timesheet entries
Previous behavior:
the first line of the report's table is missing a border
Current behavior:
borders are consistent
opw-2230710
closesodoo/odoo#49432
X-original-commit: a70437c0fc8127976ce00b5ec1ef4ae006b28e15
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
If for some reason someone wanted to develop a textarea using the
editor which is supposed to work as a public user (like we are trying
to do on Odoo.com), it was not possible. The code was "designed" to
allow it but there was one problem: the lazy loading of the editor
assets required a `render_template` call to the server... which cannot
be done from a public user.
This commit solves the issues by allowing the lazy loading of assets
to use a custom route if required. That route is then used by the editor
"root". That route performs the render_template as a superuser provided
that the view's xmlid is whitelisted.
Note: there was another unauthorized call for public user: the
colorpicker. This was solved by disabling the colorpicker template rpc
for public user, they will still get the default summernote one.
Part of https://github.com/odoo/odoo/pull/48981closesodoo/odoo#48981closesodoo/odoo#49398
X-original-commit: e84a0bfdc99c21406861b88c02b11c925d92f927
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The caching system which was implemented was not working if the
same asset was asked twice "at the same time" = "if the second demand
occured while the first demand's RPC loading was taking place".
Part of https://github.com/odoo/odoo/pull/48981
X-original-commit: ba0ac348a3700331cec6955625ca2b6c72600ced
TL;DR A bit of magic and ... Pouf ... all virtual events are now real records.
Purpose
=======
The current implementation of recurring events uses "virtual events" to represents all
events in the recurrence. Only one event is stored in the database. All other events are
dynamically built and sent to the web client which sees them as real records.
This implementation is old, difficult to read (6 years of changes and bug fixes) and
has become more and more difficult to maintain.
A fresh start would be welcome.
Specification
=============
When creating a recurring event, a `calendar.recurrence.rule` record should be created.
This model holds the rrule configuration and is responsible to manage events that result
from the rrule.
When a new recurrence is created, all resulting events are also created (stored in the
database). No more virtual events.
To avoid an explosion of events, a maximum of 720 events is created. With 720 events,
a daily recurrence lasts for 2 years and a weekly recurrence lasts for 15 years.
This strategy is used by Google Calendar and seems acceptable in most cases.
A cron job could eventually be introduced to generated more events as the end comes.
This allows to introduce an new rrule end type: 'Forever'. This is actually a shortcut
to create a recurrence running for 720 events.
Inspired by Google Calendar, new possibilities are introduced when modifying a recurring
event (e.g. change the name, add an attendee):
- Modify only this particular event (the event is still part of the recurrence)
- Modify this and following events (events are still in the same recurrence)
- Modify all events
In a similar way, when updating the rrule of an event (e.g. from every Monday to every
Tuesday), the user can choose to:
- Modify this and following events: the recurrence is split. The first part remains
unchanged but now ends when the second recurrence begins. The second parts is the
updated rrule.
- Modify only this particular event.
- Modify all events: Forbidden (same as Google Calendar)
Note: when events are "moved" because the rrule changed, the events are not actually
moved. They are unlinked and new events are created (See "Some design choices explained"
section).
Some design choices explained
=============================
Where to store the rrule?
-------------------------
Two options were considered.
1) Store the rrule on an event, each event of the recurrence having a Many2one
to the parent_id, aka the Master Event of the recurrence.
2) Store the rrule on another model: `calendar.recurrence.rule`. Each event in the
recurrence having a Many2one to the recurrence record.
Both options have pros & cons. But there is no clear winner.
However the actual business logic of handling the recurrence creation/update
would be the same.
Where the rrule configuration is stored is the only main difference between both options.
And this is probably the easiest part of implementing recurring events.
With that in mind, option 2) is chosen. It allows to clearly separate recurrence
logic from the events themselves. It is also the "correct" way of modeling data to avoid
many empty columns for most records.
Reusing events on rrule update
------------------------------
When an rrule is modified, events should also be updated.
In most cases, current events are unlinked and new events are created from scratch.
Only events exactly at the same time before and after the rrule update are kept.
Trying to reuse other events would require an obscure and arbitrary heuristic.
(Imagine an rrule every Monday that is changed to every Tuesday and every Friday.
What would you do?).
This implies that any change to a specific event (name change, attendee added, chatter
messages) is lost. This tradeoff seems acceptable as updating an rrule should not be
that frequent. Moreover, Google Calendar also works that way so why not Odoo?
Reusing events on events shifts
-------------------------------
On the calendar view, drag and drop an event to shift the entire recurrence.
One way to handle the recurrence shift is to apply the same timedelta to all events.
Now events are correctly positioned... except for events that were specifically
moved. Those outliers needs special handling.
This also introduces some behavior inconsistencies:
when an rrule is directly modified, events are not reused, but when the rrule is
modified by drag & dropping an event, events are reused. This option needs more code to
handle the shift and the behaviors are not consistent.
The chosen option is to find the rrule configuration from the dragged event (this is
easy) and update the recurrence with those new rrule values. This brings us back to
an rrule update (see above): code reusability yeah; one behavior to rule them all yeah.
One downside is that outliers are lost (but Google Calendar also works that way).
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
Let's assume an editable="bottom" list view with handle widget and a
required field. Moreover, there are less than 4 records in the list,
so there are empty lines at the bottom of the list s.t. there are
at least 4 rows.
Click to add a row: a new row (in edition) is added at the end of
the list (instead of an empty row). Do not fill the required field,
but instead move another row after the new one (which is still in
edition). Then click on discard.
Before this commit, the discarded row was replaced by an empty one
(s.t. there are always at least 4 rows in the table), but that
empty row wasn't added in the bottom of the list.
task-2209076
closesodoo/odoo#49251
X-original-commit: 22f43536cb78e07aaab3fd806f3c6c5f068824f3
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
* Reword tasks in the sample project
* Add a "Create and Edit" button on the project creation modal
* Open the file chooser in "Set a cover image" if there are no images
set
* Correclty display the kanban state button on archived task
* Add a button to list the tasks when deleting a project
* Open file chooser for cover image: Automatically open the file chooser
when setting a cover image on a task if there are no attachments to chose
from.
closesodoo/odoo#47306
Taskid: 2209133
Related: odoo/enterprise#9141
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Currently, the Employee picture stays on top of the card of the employee
we're looking for. The image does not disappear after a search is validated.
Steps to reproduce:
>> On employee kanban focus cursor on search panel, then mouse over
to employee image so it will be zoomed, now without mouse leave just
type in the search panel and enter, the big zoomed image stuck on
screen and don't even know how to make it go away.
So in this commit, We fix that on keudown hide the zoom image so
when user search on search panel it will hide the zoom image.
OnShow of zoom bind the generic even keydown and on that just
hide the image so it should not stick on screen.
TaskID : 2212808
Closes : #48253
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Issue
- Access rights > archive ir exports & line
- Any list view
- Select all > action > export
Access rights error
- Export all (next to import button)
Export done
Cause
Action > export does a search_read which checks
access rights
Export all is bypassing that check
Solution
Do a search_read when clicking on export all
before doing the export process
OPW-2230048
closesodoo/odoo#49203
X-original-commit: 8aa89d4c416bdcf3c7f6543f3d32006f9807c938
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
TL;DR: remember `osv` and `except_orm` ? You can forget about them.
* Deprecated `except_orm` dropped.
* `UserError` elevated as super type of all user-related
errors.
* Unused `DeferredException` dropped.
* Unused `QWebException` dropped (real one is in `qweb.py`).
* `MailDeliveryException` made a python exception.
* `name` legacy exception attribute made an alias of the python standard
`args[0]` attribute and deprecated.
* `value` legacy exception attribute dropped.
* `exception_type` RPC error response key dropped.
* Deprecated `osv` module dropped.
* `--osv-memory-age-limit` cli option made an alias of
`--transient-age-limit` and deprecated.
The `odoo.exceptions.Warning` have long been a deprecated alias to
`UserError`. It is going to be removed in a future version but first we
explicitly deprecate it with a warning.
The `odoo.exceptions.DeferredException` was a very old internal
exception, it has been removed without deprecation notice as it is never
raised.
The `odoo.exceptions.except_orm` has been a deprecated exception type
with deprecation warning for 5 years, it has been removed in favor of
UserError which becomes the super class of all user-related errors.
The `odoo.base.models.ir_mail_server.MailDeliveryException` was
inheriting `except_orm`. As it is not related to a user error but is
more of a problem an admin much take care of, the exception has been
made a Python error.
The `exception_type` JSON key in RPC error responses was holding an
hardcoded value derived from the exception type. Its usage has been
dropped in favor of the `name` JSON key that holds the precise exception
name. Again as it was hardly used in the source code (beside the crash
manager) it has been dropped without deprecation warning.
Since we are here trying to clean odoo custom exceptions, we are also
deprecating the `name` exception attribute in favor of the more standard
`args[0]` attribute.
The `name` (along with `value`) were two attributes used to raise
`except_orm` exceptions before the introduction of `UserError`,
`AccessError` and related exceptions. The `name` attribute, at the time,
was holding the exception type/title. Nowadays it contains the error
message. The `value` attribute, at the time, was holding the error
message. Nowadays it is no more used.
The `osv` module contains very old deprecated aliases. There is no
simple way to log a deprecation warning for osv, osv_memory and
osv_abstract but as they have not been in use for ages, they have been
removed too. To be consistent, the `--osv-memory-age-limit` cli option
has been made a deprecated alias to the `--transient-age-limit`.
closesodoo/odoo#45723
Task: 2187728
Related: odoo/enterprise#9162
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
After cb76a0022, three more Qunit tests were found to fail randomly.
closesodoo/odoo#49190
X-original-commit: 9809c53e65059d53a9f115ab29ef02583f84bdb5
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
before this commit: from commit: https://github.com/odoo/odoo/commit/d58d6e270f4106d717821438490f60bc4f71306e parent context
was propagated to sub views, propagating whole context to sub view creates
issue as it contains default_* key inside it, there is a chance that sub view
has same field name which matches with default_fieldName in context,
e.g. go to sale order form view and create sale order line, while selecting
product, write in product_id field so that Create and Edit option comes,
select Create and Edit option, so whatever previously written in product_id
field will be added in product.product form's context as default_name,
now go to Purchase tab of product form and try to create Supplier, but note
that Vendors One2many should be editable, if it is not then to produce this
issue, make Vendor o2m list editable top/bottom, as soon as you click on
Vendor o2m's create button traceback generated which comes from name_get of
res.partner, issue raised because vendor o2m has m2o of res.partner and field
name is 'name', when default_get for vendor o2m is called it will propagate context
and context has default_name='typed string in product_id', as name field is
m2o with res.partner it will generate traceback as m2o accepts (id, name) tuple
not string
after this commit: propagate context to sub view but remove default_* keys
from parent context
task-2121161
closesodoo/odoo#49075
X-original-commit: 2e3756e0ce96a9e0c5fa304632a2600cbd832ef5
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the value of the search bar remained when the auto-completion
dropdown was closed (via click out or "Escape"). This was inconsistent with the
behaviour of the search bar which is supposed to show the auto-completion values
related to the search input.
Now, the value is cleared when the dropdown closes.
Task 2227590
closesodoo/odoo#49066
X-original-commit: 1c3e6ef0a5946ce415c9a210546b207011a51b3d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Following 889dd9245, there is still a qunit test that randomly crash.
closesodoo/odoo#48977
X-original-commit: cb76a00226cf22d1ed659d736a36fa9b92e0a512
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
In a form view, nodes with classname "oe_read_only" (resp.
"oe_edit_only") are only visible in readonly (resp. edit) mode.
Moreover, fields inside a group automatically have an associated
label.
Before this commit, when one of these classnames was set on a
field node inside a group, the effect wasn't applied on its label,
so the label was always visible, even if the field was hidden.
Bug reported in PR odoo/odoo#48699closesodoo/odoo#48968
X-original-commit: 705f434f0f18a0e4d2fdb0f86d3e350d190b2a30
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The "Views > CalendarView > drag and drop on month mode with all_day
mapping" test would fail regulary with "Found 2 elements to click on,
instead of 1" because the drag and drop would be ongoing and the event
would sometimes appear two times in the DOM when we try to click on the
drag and dropped event.
closes#48928closesodoo/odoo#48937
X-original-commit: 9bc0b11b2e255852c1376fe6fa87722186681a73
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
*google_drive
Go to a user form view and click on "Change Password" in the action
menus.
=> traceback `Cannot read property 'constructor' of undefined`
This error is raised because `active_domain: undefined` is in the context
and py_eval can't handle an undefined value.
closesodoo/odoo#48915
X-original-commit: 69694c627be42e3d068e48be14026493628a3a8d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: lul-odoo <LucasLefevre@users.noreply.github.com>
Co-authored-by: aab-odoo <aab@odoo.com>
Currently when zoom slowly from right to left on employee image it
will not zoom the image.
currently to hide the zoom image we used target.width() and the method width
gives the width of the selected element (excluding padding, border
and margin) so due to border excluded it will hide the zooming image.
Aslo the offsetHeight property returns the viewable height of an
element in pixels, including padding, border and scrollbar, but not
the margin.
The reason why the 'viewable' word is specified, is because if the
element's content is taller than the actual height of the element,
this property will only return the height that is visible.
so instead of method width we used method outerWidth which gives
width of the selected element (including padding and border, excluding
margin).
closes odoo/odoo#46619
Co-authered-by: Mahendra Barad <mba@odoo.com>
Task: 2199218
Closes: #46619
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Add a new group allowing administrators to remove the ability for
users to bulk-export data from the database. It's pretty minor as
technically the user can still access the underlying object through
the basic methods but it's still a bit of a roadblock.
Users can export by default.
Task 2170900
closesodoo/odoo#45400
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
After this commit, in the graph view, when the user clicks on parts
of the bar and pie charts, it opens the list view of the concerned
records (like what was already done in the pivot view).
This is the default behavior, but it can be deactivated by setting
the attribute 'disable_linking' to true in the view.
Task 2198461
closesodoo/odoo#47796
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Before this commit, when the duration of an event is "24H * n". The event
is set as allDay. This is strange to have a event that start a 8H and end
at 8H of next days and the event is in the allDay slot.
After this commit, we don't change the allDay flag anymore.
Steps to reproduce:
* Open calendar in week view
* Create a event from 8 -> 16
* Then resize the end of this event from 16 -> 8 of the next day (BUG)
Task ID: 2183249
Before this commit, it was possible to create/move an event in the "all
day" slot of FullCalendar even when the mapping field wasn't set.
With this commit, when the "all day" mapping is not present, the "all
day" slot of FullCalendar becomes hidden.
Ref:
https://fullcalendar.io/docs/allDaySlot
Task ID: 2183249
Due to previous commit, in month view, the flag marking events as "all
day" is no more present and so some logic is not applied anymore. This
results into the wrong end-date.
With this commit we avoid to change the end date of an event in
FullCalendar.
Note that it changes the behavior on drag-and-dropped event in month
view:
* Before both the last and this commit, an event if 1H will become an
"all day" event when it's dropped into another cell.
* After them, the time will be the same as the original event and only
the date will change.
Also, one test was already added in commit odoo/odoo@7af13089df
to check that, in month view, when we move a non-"all day" event to
another day, it can't change into a all day event.
This commit adds a second test to cover the case when the "all day"
mapping is present.
Task ID: 2183249
Before this commit, events were sorted by ID in month view.
Event A occurring after event B would be placed on top of B instead
of below.
Steps to reproduce:
* Go in the calendar app
* Insert a event at 12:00
* Insert a event at 8:00
* Insert a event at 14:00
* Go in view month the events are not sorted (BUG)
In month view, events are forced to be "allday", so the sequence used
can't be based on its time but only on its ID.
To fix this, this commit doesn't force the "allday" flag anymore.
Task ID: 2183249
In `calendar_tests.js`, the tests about creating an event with timezone in
week mode only triggers 7 asserts but they were design to trigger 8 of
them.
After analysis, it looks like in the commit odoo/odoo@369c20a99b
the FullCalendar's UI was redesigned and some CSS rules might have add
some margin preventing a MouseEvent from being triggered correctly,
resulting in misadapted tests.
This commit restores the original behavior by adding some pixels to
these offsets, allowing the events to be correctly dispatched and
adapting again the tests.
Task ID: 2092550
This commit updates the FullCalendar library from v3 to v4.
The purpose of this update for us is to add a proper support of the
drag-and-drop of events on mobile.
But also to fix scrolling issues present mainly on smaller screens. In
those configurations multi/inner-scrolls were present resulting into
either the inability to properly scroll the desired content or even
blocking alltogether the scroll.
As a nice-to-have feature, the version 4 removes its dependency on the
jQuery library, allowing a faster loading of a bigger set of events.
Last but not least, this version also reduces its dependency on the
Moment.js library (but still keeps a binding to it for compatibility
purpose).
This commit focus only on the update of the library itself and the
adaptation of the related code to keep it working. Further
enhancements/fixes will be done later on.
To do so it modifies the following points:
* Update the library in itself (js, css...).
* Convert all FullCalendar's method calls to the new syntax (e.g.
`$calendar.fullCalendar('destroy')` becomes `calendar.destroy()`).
* Add a utility method to convert v4 events into the old v3 event
structure to ease the transition from one version to the other.
* Wrap all event's custom fields into a new event's
`extendedProps` object (as its the new way of storing them instead of
directly as a prop. of the event).
* Adapt `slotLabelFormat` and `weekNumberCalculation`.
* Use the view's new names:
** `agendaDay` -> `timeGridDay`
** `agendaWeek` -> `timeGridWeek`
** `month` -> `dayGridMonth`
* Use the option's new names:
** `viewRender` -> `datesRender`
** `eventMouseover` -> `eventMouseEnter`
** `eventMouseout` -> `eventMouseLeave`
** `isRTL` -> `dir`
** `selectHelper` -> `selectMirror`
** `weekNumberTitle` -> `weekLabel`
Ref:
https://fullcalendar.io/docs/upgrading-from-v3
Task ID: 2092550
Add new Kanban examples and improve the usability of the dialog.
closesodoo/odoo#48620
Taskid: 2210279
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Prior to this commit, the list_editable_renderer was grabbing the first
table in the DOM. This made it so extending list views with another table
could cause the new table to resize unexpectedly when changing the column
width of the list view generated table (i.e. o_list_table).
While this double table situation may not arise very often, it directly
hindered task: 2198420 and may hinder other customized view tasks.
Related to task: 2198420
("Requests for Quotations KPI's" subsection)
closesodoo/odoo#46654
Related: odoo/upgrade#877
Related: odoo/enterprise#8945
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Aaron Bohy