Removing the test "field changes are correctly debounced in text fields"
because it doesn't represent the reality that fields are not debounced
anymore in production code.
This test was nondeterministic.
Before this rev., this._super wasn't correctly reset after being
called. It means that it was sometimes wrongly set, for instance
in the following scenario:
utils.patch(SomeComponent, {
x: function () {
this.y();
this._super(...arguments); // this._super was still y
},
y: function () {
this._super(...arguments);
},
});
closesodoo/odoo#41691
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
During the fix of the click_all test in community in 0f2a500f0e,
I have overlooked that enterprise used this code and removed a bit too much.
Restore the start flag in enterprise.
closesodoo/odoo#41784
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The `text` attribute is not translatable, so we support the `title`
attribute which is.
Fixes#38568
opw-2148416
X-original-commit: 21203ec63db6702529a791f5abab317c6d4fb8af
Before this commit, after the introduction of OWL, for some reason,
maybe because the session is ready earlier or later, the webclient is
opening the first app sightly earlier than before, making it too early.
The click_all failed actually because, in the initialization of the
webclient, it does a read on read user, protected by a drop_previous
it tries to start the first applictaion, when this happens, the hash
changes
==> because the hash changes, it tries to open an application, with is
also protected by the same drop previous, this discarding the result of
the read and preventing the then callbacks of the read to happen.
After this commit, we are declaring that the client is ready after the
actual load of an application.
closesodoo/odoo#41695
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The format of `many2one_reference` was not introduced when the new field type
was created, which leads to empty values when the web client is trying to
display the value of such fields in form views.
Since the value of this field is an ID, it is decided to display it like an
integer, which is consistent with previous behavior: the fields that are now
`many2one_reference` are still stored as integer and they were already displayed
as integer before.
This was fixed in list views in commit d0c852f50e
and the current commit fixes it for form views.
opw-2127010
closes#38009closesodoo/odoo#41666
X-original-commit: c37a16c9dfd09038925034b90ab49e1ab674e714
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Followup of a425695e
The terms were back in 12.0
Courtesy of Juan José Scarafía
closesodoo/odoo#41624
X-original-commit: 85d0c7001a997748d7691205bbb8d066597591a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The date filters sent to servers were being computed in current locale,
so in arabic we would get things like this:
- "٢٠١٩-١٢-٠٩" instead of "2019-12-09"
- "٢٠١٩-١٢-٠٩ ١٦:١٦:١٥" instead of "2019-12-09 16:16:15"
which would cause a traceback in backend.
opw-2122333
closes#41570closesodoo/odoo#41596
X-original-commit: da778afc24b048244467649dfa4af4e6f4a78e44
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Update of Chart.js library to the latest version.
Before this commit, we weren't able to see all
x-axis dates labels like in Accounting Overview.
Tick label rotation on mobile has been fixed in
https://github.com/chartjs/Chart.js/pull/5961.
closesodoo/odoo#41582
X-original-commit: 24d8ae59e08143dc0ca7e05be37a3cd607d58a4a
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Sometimes, it might be useful for an action (e.g. a client action,
although this may be used by standard views as well) to include custom
values in its state. Since the state of a 'fullscreen' action is pushed
in the URL, this means that it is possible for the action to resume its
state properly upon refresh of the page (before this commit, only some
standard information were pushed to the state - action_id, menu_id, etc.
for window actions and action's name, active_id, active_ids for client
actions).
By implementing the `getState` method, an extension of the action mixin
can thus push any state it wishes to the URL.
closesodoo/odoo#39529
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Because the webclient and other higher level components such as the
actionManager are not yet rewritten in OWL, we cannot make a complete
migration of the controller and the model to a more OWL-ish code.
We have rewritten the renderer completely in OWL, it uses more
extensively a template and manages its own state and its sub-components.
We did not rewrite the controller, however we have made it inherit from
`web.ControllerAdapter` which is a thin compatibility layer used when a
odoo controller uses a OWL renderer.
In the tests, the only changes are that all the events triggered by the
test and handled by OWL must be triggered on DOM nodes directly and not
on JQuery elements.
closesodoo/odoo#39491
Related: odoo/enterprise#7135
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: VincentSchippefilt <vsc@odoo.com>
Co-authored-by: pro-odoo <pro@odoo.com>
Add a base class for a complete OWL renderer
Add a compatibility layer for a Odoo controller that uses a OWL renderer.
Co-authored-by: Pierre Rousseau <pro@odoo.com>
In this commit:
- transformed test_utils helpers to always trigger native events
- introduced new test_utils_create helper: prepareTarget
- updated qunit asserts to support Owl Components
- updated all misused helpers that would crash with the updated test_utils
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Pierre Rousseau <pro@odoo.com>
With this commit, we properly introduce the Owl library into our beloved
codebase. More information on the Owl library can be found in the project
repository: https://github.com/odoo/owl/
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
This commit adds mixin to manage file uploads in view controllers and to
display progress bars.
The first motivation and use case is to allow MRP to manage and display
uploads like in Documents.
closes odoo/odoo#38397
Task: #2074822
Related: odoo/enterprise#5887
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, when doing a primary inheritance
the root node of the resulting template was the one of the inherited template
after this commit, the root node of the resulting template is the one defined
on the inheriting template
closesodoo/odoo#39452
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, when a template was inheriting from another
the template mentionned its t-inherit
This has been deemed overkill as the information is irrelevant to the caller
i.e. the caller just wants the template and doesn't care how they've been computed
After this commit, only t-name and attributes not related with inheritance
are disclosed
[FIX]: base: static inheritance propagates other attributes
When doing a inherit in primary mode, the original attributes on the root node of
the inheriting template were not propagated
After this commit they are
At the conception of this feature it has been intentionally thought that
the behavior for static templates should resemble
what is done for ir.ui.view
While keeping the general previous behavior (and this is important)
A little bit of context for ir.ui.view
They are defined as XML's, but end up as python objects
Their meta-data (id, name, inheritance specs...) are thus
present in their XML definition, but end up as part of python objects members
Hence, the final, business, usable arch is free of those meta-data
and is left only with business-relevant dom nodes
The static inheritance feature was backed with those ideas
but inherently encountered the issue that, for them,
the meta-data also end up in the business dom, since
they are at no point considered as plain objects.
Decision has been made, back then, to exclude the root node
that holds the metadata, to be at all targeted by any XPATH
This decision is now challenged as the specs of XPATH should be respected
This commit consequently introduces the root node as any other
It can be replaced, and will be targeted by
`expr="."` or `expr="//NODE_TAG"`
The few attributes that are necessary to define them are kept across
inheritance cycles though.
Task 2046908
Instead of having all the fields duplicated with second_*, we have now a
o2m allowing us to
* have more than 2 lines
* reduce duplicated code
* fix bugs and add features at only one place
We also remove the computation of writeoff and suggestions from the
client side as some code was 4-upled before (twice in in client and
twice in server side). The logic is now only at one place.
closesodoo/odoo#38119
Related: odoo/enterprise#6324
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Before this fix, a QUnit test was wrong (didn't parse)
After this fix, the test actually works and tests something.
closesodoo/odoo#41257
X-original-commit: 3818a7f0df754717a7379dc8341729b508a166be
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The `session_info` dictionnary is used to bootstrap some JS code client
side (usually in the backend). It includes relevant information, such
as some parameters key for the OdooBot onboarding, the Enterprise
subscription expiration alert, etc. to avoid triggering a lot of RPC
calls upon webclient start.
`session_info` is also called by the remote authentication mechanism
located at `/web/session/authenticate`, which can be used by external
mechanism to obtain a valid session remotely.
Revision odoo/odoo@8a28cc2 introduced the concept of cache keys for
some oft-requested data (such as menus, translations and dynamic qweb
templates) to avoid requesting them on each webclient start, since they
tend not to change often. Unfortunately, it introduced a read on the
ir.ui.menu model that raised an `AccessError` if the authenticating user
was not a member of the `base.group_user` group ('Internal' user type).
While fixing that issue, it became apparent that `session_info`
returns a whole lot of information through this remote connection route
which is entirely unnecessary if not used in the context of a webclient
start, such a currencies, the state of the enterprise subscription, etc.
This commit fixes the access right issue by removing this non-relevant
information from the returned dict (including cache keys) if the user
is not an internal one.
closesodoo/odoo#40770
X-original-commit: 6e99ac2c6cd5ca9af87b4fc7a3a1394359e30b02
Related: odoo/enterprise#6860
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Reproduce the issue
- Load Arabic language
- Install Accounting
- Create an invoice & add credit note
- Switch to arabic
- Click on the "(i)" icon near the total price
The popover is displayed at the other side of the screen
Cause
- RTLcss was reversing the "left: 0" css property to "right: 0"
- The popover configuration was not adapted for RTL
This commit ignore RTL for the popover css "left" property and
configure correctly the JS side
OPW-2146210
closesodoo/odoo#41200
X-original-commit: 88f03f0444a2533b1f6085369af431131da42b54
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
Reproduce the issue
- Load Arabic language
- Install Sales
- Report > Sales
- Switch to arabic
- Click on the pivot view to display the dropdown
The dropdown position is incorrect
Cause
The calculations are based on a `left` value who is weird.
This commit use the mouse X position to compute the `left` value.
OPW-2146210
X-original-commit: d021f4257c87863b75f148c4809f5e2797a1e99f
After commit odoo/enterprise@8a38a60b1f
mobile tests didn't run correctly because of missing viewport META in HEAD.
This commit add the missing META. This META must be before all
JavaScript file to ensure that JavaScript also know that we work in
a viewport.
Note that "runbot" run tests in a chromium headless with a size screen
reduced and so it worked without this fix.
closesodoo/odoo#41183
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
* web, mass_mailing, website
Introduced a new sub-widget for snippet options: we-colorpicker. This
allows to retrieve a color value (either a normalized css color or a
theme color name) to be used for a snippet option method.
This commit replaces the old 'colorpicker' snippet option whose behavior
is now simply achieved by defining an xml option using a we-colorpicker
widget in combination with the 'selectStyle' standard method.
This commit also adds the possibility to control the border-color of
elements alongside their border-width. Again, just a we-colorpicker
widget in combination with the 'selectStyle' standard method.
Note: this commit reviewed what the colorpalette palette widget
notifies. This is not a cssColor and a 'isClass' flag to say if it is
a css class or not. The colorpalette always returns a color string which
can be the name of a color like 'alpha'. This is up to the caller to
check if the color string is a css color or not with isCSSColor. In the
case it is not, the related code can read the actual color by reading
the related css variable.
Part of https://github.com/odoo/odoo/pull/40282
In preparation of task-2122935 and other tasks
* website
Review colorpicker methods to always allow to use normalized colors.
Also factorize some code in the color palette widget.
Part of https://github.com/odoo/odoo/pull/40282
In preparation of task-2122935 and other tasks
Fixes the way record end hours are computed in calendar views.
Before this commit: objects `record start` and `record end` properties being copied by reference
and being incorrectly rewritten by other functions.
This caused incorrect end hour computations (and a SQL crash in the Planning app).
Now, objects are copied by value and don't interfere with each other.
Task 2072961
closesodoo/odoo#37690
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Adapt calendar highlight option (that "highlight" event linked to the
record we come from) to current JS framework data structures.
note: this changeset also fixes the original `_compute_is_highlighted`
that was would trigger CacheMiss errors, and also adds back the CSS for
highlighting that was lost between 12.0 and 13.0 version.
opw-2131494
closes#40791closesodoo/odoo#41077
X-original-commit: da56e3e7036ecdb3905f4152778e853e080e0163
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- Set the computer TZ so that it is UTC day + 1. For example, set to
'Australia/Adelaide' and perform the tests after 3:00 pm
- Go to Account > Customers > Invoices
- Set the Invice Date to today in the TZ
You receive the warning 'This date is on the future...'
The comparison of a UTC date without time `currentDate` is inconsistent
with `moment()`, which is not UTC and has a time set.
After playing around with `.utc()` and `startOf('d')` with no luck, we
decided to give up the idea of making `getTZOffset()` enter the game and
simply compare the string formatted values.
opw-2093186
closesodoo/odoo#40984
X-original-commit: f9eec97cb128f71796fca0116841453555ab4684
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
`name` field can be required and falsy `data.name` should not be
added as default in context or it warns for missing required field.
Task-2052536
closesodoo/odoo#35880
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
On mobile, there was no way to create a new column in the kanban view. This
was specifically annoying in the Project app (the user was able to
create the project but couldn't set its stages).
This commit enables this feature by adding a `+` icon at the end of the
tabs. This button opens a quick-create column widget.
If there is no existing column (for example in a newly created project),
this quick-create column widget is opened by default.
Finally, this commit improves the processing needed for the swipe
animation between the columns.
Task ID: 1893137
closesodoo/odoo#40722
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Co-authored-by: Ankit Sathvara <asa@odoo.com>
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Co-authored-by: Romain Estievenart <res@odoo.com>
Before this commit, with a time range activated in a pivot view,
click on a non empty cell would not always give the right list of
records because of a bad action domain.
The reason is that the headers domain or comparisonDomain were
not always set when appropriate:
- for the headers 'Total', the corresponding group obtained
by read_group does not contain the key __domain. For that
reason both the key domain and comparisonDomain were left
undefined.
- for headers that correspond to groups not present in the two
periods compared, one of the key was left undefined.
With the present commit, we correctly set the domain and
comparisonDomain keys everytime they are useful.
closesodoo/odoo#40713
X-original-commit: 2f89820faa5966b8321d6681e9745a4e938e2bec
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Conditional expressions were already parsed, but there was no support
for executing them (or stringifying them back though I'm not sure when
that's used).
closesodoo/odoo#40502
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce:
1. Go to the Accounting / Invoicing apps
2. Open Taxes (Configuration -> Accounting / Invoicing -> Taxes)
3. Try to create a new tax and the client crash.
It occurs because the `_processX2ManyCommands()` method doesn't handle
correctly a missing `fieldInfo` on some X2Many tags.
On mobile, when calling `load_views` the kanban view is used by default.
But if the kanban isn't defined, a default kanban view with only the id
of the model is used.
In the case of the taxes form, the `default_get` retrieved for this
form refers to a Many2Many (`tag_ids`) inside a One2Many. But this field
isn't present inside the loaded kanban view, so when we process the
command defined by the `default_get`, the `field_view` item doesn't
exist (because the default kanban loaded only contains the id of the
field).
Now instead of using an undefined `fieldInfo`, we fall back to an empty
object on the missing field to avoid the crash.
closesodoo/odoo#40617
X-original-commit: 47a306a31ac6d3c9e68e83b77a80426d5c6ceb05
Signed-off-by: res-odoo <res-odoo@users.noreply.github.com>
Reproduce the issue
- Install CRM
- Go in CRM > Reporting > Pipelines
- Click on the first "Group by" button
The dropdown menu is out of the screen at 100% zoom.
If we want to see the whole menu we have to dezoom ("Ctrl" + "-")
Cause
We are using bootstrap to handle dropdowns. Bootstrap uses a library
named "popper.js" to compute the position of the dropdown according
to the remaining space.
In this case, there is no space left to place the dropdown below
the button, so popper.js flip it above the button and
this cause the issue.
This commit disable the flip from popper.js and set the max height
of the dropdown menu to 140px:
- navbar: 42px
- control panel: 82px
- some margin: 6px
OPW-2116974
closesodoo/odoo#40530
X-original-commit: 9def02699d96f4dfd8dd806d2bec86a872a0c6eb
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
Co-authored-by: aab-odoo <aab@odoo.com>
This is a weird situation, but the python handles it. Let's assume
a many2one field F1 on model M1 with comodel M2, and on M2 the name
field (which is the _rec_name) being itself a many2one, and the
following scenario:
- create a new record for M1
- for field F1, select 'Create and Edit': it opens a form view for
M2 in a dialog
- type something in F2 input, and click 'Quick create'
- save the dialog
Before this rev., the value of F1 was [object Object]. Now, the new
value is properly displayed.
OPW 2091106
closesodoo/odoo#40549
X-original-commit: 5a04ea848abf50b1fb1f9893d1fcd98013bc025d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Reproduce the issue
- Install Projects and Studio
- Edit the projects app's kanban view
- Enable group by stage
- Close studio
- Add several stages
The stages are wrapped to the next line
Cause
I think the problem comes from c5f6802, we apply a wrapping to
all the kanban_dashboard items and in this cases the items are
the stages.
This commits apply the wrap only on non-grouped kanban dashboard.
OPW-2123031
closesodoo/odoo#40449
X-original-commit: f40478d5bacfdc44c76b0aac2f749549bbc58681
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Vincent Schippefilt