| Age | Commit message (Collapse) | Author |
|---|
|
The changed test uses the drag&drop helper, and an operation does
not work as expected with the given params on chrome 90. The runbot
currently uses chrome 80, so it is not an issue, but if your chrome
is up-to-date, and you try to run the test suite, this test would
fail.
closes odoo/odoo#70008
X-original-commit: 43994da9980e4133274984f720bb58f3546ea0f9
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Commit [1] recently fixed an issue with nested x2many fields and
onchanges: in some cases, all field values weren't sent to the
server as they should.
However, there is a small issue with this fix. We didn't correctly
apply the default value to option `changesOnly`: when not given,
it was considered false, whereas in this particular function it
should have been true.
It caused an issue in the following scenario:
Have a form view with an x2many field (say A) displayed as a list.
In the list, there is another x2many field (say B), and (whatever
its type) a field C with an onchange. When the user changes C, the
onchange is performed, and we send to the server the value of all
fields. In particular, in the row, we send the value for the
many2one field pointing to the main record (the inverse field of
the x2many relation). The value for that field is basically the
whole record, containing itself field A. For field A, the value is
a list of commands, and for the updated record, it is a command 1.
Before this commit, in the values sent for this command, field B
was the empty array, even if it wasn't empty.
This issue was reproducible in account.move, on an existing record
having already a line in invoice_line_ids (this is field A). In
that line, tax_ids (this is field B) must have a tax which is
included in the price. When changing the quantity of the product,
the subtotal wasn't correctly computed.
[1] https://github.com/odoo/odoo/commit/a8b43d02066b2299ac2f4b88056c37725e9ce6cd
opw~2489755
closes odoo/odoo#69167
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
|
|
One might design a custom field widget to display/interact with a
one2many field. Before this commit, if this field widget triggered
a field_changed event to update a related record, it crashed,
because the code assumed that there was a view associated with the
field.
Closes #68276
opw~2468238
closes odoo/odoo#68294
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
Let's assume the following situation. We have a form view with a
one2many field A displayed as a list. In the list, there is a
one2many field B. B can't be edited, its value is computed by
an onchange. By default, it contains a single record (i.e. the
first value returned by the onchange is [[5], [0, 0, {...}]]).
When another field (say C) changes, B's value is re-computed to
[[5]]. Moreover, there is an onchange on A.
In this form view, let's assume the following scenario. Create a
new record and add a line to A. In this new line, B already
contains a record. Change C. This triggers an onchange that
returns [[5]], and B is now empty. It triggers a second onchange,
on the main record (as field A changed).
Before this commit, in this second onchange, B's value wasn't sent
among the other values of the new line.
The spec says that for onchanges, we must send all data, not only
what has really changed. From that perspective, the above scenario
highlights an issue.
That issue had two root causes. First, commit [1] wrongly fixed
another issue, and as a consequence, when building what to send
for the onchange, we didn't generate the values for fields that
hadn't changed inside an x2many (for added subrecords at least).
This commit reverts the fix of [1], and fixes it differently by
only sending a command 1 (update) after a command 4 (link to)
when the record is dirty (i.e. when it has been modified). See
[1] for context and details.
Second, the code that generates the values to send to onchanges is
the same as the one that generates the values to save records
(write or create). However, when saving, we only send what has
really changed. The values are at some point processed to remove
empty command lists from the list of changes (as it means that
nothing changed). However, here we ignored the flag that stated
whether we want all field values or just what has changed. This
commit takes the flag into account before removing the field's
value.
[1] https://github.com/odoo/odoo/commit/3e3a244e1afc4d74920a6302a14fa2590e8b6648
Issue reported in task~2352524
Model: account.move
One2Many (A): account.move.lines
Nested computed One2Many (B): tax_detail_ids
Field triggering the onchange (C): tax_ids
closes odoo/odoo#67679
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
|
|
Commit [1] altered the way the FieldMany2Many behaves with respect
to 'create' and 'delete' options. Indeed, for many2many fields,
adding or removing records doesn't mean "creating" or "deleting"
records, as it is only about adding/removing records to/from a
relation. This is completely fine and correct.
Unfortunately, a feature has been lost in the process: it is no
longer possible to state that a many2many field should be editable
but should not allow to add (or remove) record to the relation.
This commit fixes the issue by adding two new options: 'link' and
'unlink' for that purpose.
[1] https://github.com/odoo/odoo/commit/c98579d25af01c14df4baf57fb4652f3e7469096
opw~2466213
closes odoo/odoo#67358
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
|
|
The Many2ManyCheckboxes widget displays all values that could be
in the many2many relation, with a checkbox indicating whether each
value is in the relation or not. It is designed to be set on fields
where the comodel contains a few records (typically, we don't want
to see dozens of checkboxes in the form view). This widget shouldn't
be used on many2manys with a large comodel, as we have better tools
to handle them (like a tree view).
We deal with extreme cases (when the widget is, by mistake, set on
a field where the comodel is huge) by using the name_search limit
of 100: at most 100 checkboxes are displayed.
Before this commit, this extreme situation wasn't correctly handled.
If there were in the relation records that weren't displayed
(because they weren't inside the 100 limit), then, editing the value
by (un)selecting a checkbox would automatically remove all non
displayed values from the relation.
This commit ensures that we keep in the relation all values that
aren't displayed.
Issue spotted when working on opw~2439041
closes odoo/odoo#67373
X-original-commit: fa324ef071952d749f635f878bee0fa462cfa011
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Before this commit, if the widget "many2many_checkboxes" was set on
a field with more than 40 values in the comodel (i.e. more than 40
checkboxes displayed), (un)selecting a checkbox that wasn't in the
first 40 checkboxes crashed. This was due to the default x2many
limit of 40: we only created a datapoint for the first 40 values,
whereas we could have up to 100 values to process (name_search
server-side limit). Note that this limit of 40 had no other impact
than limitating the number of records processed by the BasicModel,
the maximum number of checkboxes displayed being ruled by the
name_search server-side limit.
This commit ensures that all values returned by the server (at most
100 when this message is written) are processed and can be edited
as expected.
opw~2439041
X-original-commit: be5e5bc49cb9744c26ca75dcee74caf11447f250
|
|
The color_picker widget, that can be seen for example in the track form
view for event tracks, had an issue: if the user clicked on it, then
pressed TAB, a traceback was displayed.
The problem comes from the fact that the color picker widget inherits
from FieldInput, but is not a fieldinput, so many expectations made by
the FieldInput code do not hold, such as the code run when handling
navigation (by TAB and such keypress). Because of that, the code in
_onNavigationMove crashed, because it expected an input.
Since this is a bug fix, I simply disabled the navigation in that case,
so no crash happens. Sadly, this widget has still a big issue: it
clearly does not work as most users would expect: pressing TAB or arrows
should update the selection. But this would be a more complicated
refactoring, for a bug which is clearly not critical, therefore this
commit implements the simple and safe solution.
Also, we disable the focus outline to minimize the wrong expectation.
Seeing them kind of implied that one could update the selection with the
keyboard.
Note that the widget color_picker was moved from another addon to web/, without
any tests nor documentation.
OPW 2467369
closes odoo/odoo#67174
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Steps:
- Install mrp
- Go to Manufacturing > Master Data > Bills of Materials
- Create a BoM
- Components:
- Add a component
- Save
- Click the component
- Close the modal window
- Click the component once more
Bug:
Traceback here:
https://github.com/odoo/odoo/blob/55a6642a9621fa9683895d5d45a015bb04c3017b/addons/web/static/src/js/views/basic/basic_view.js#L147
Error: can't convert undefined to object
Explanation:
As seen on the line just above:
https://github.com/odoo/odoo/blob/55a6642a9621fa9683895d5d45a015bb04c3017b/addons/web/static/src/js/views/basic/basic_view.js#L146
`fieldsInfo` might not have the view we are looking for.
opw:2452142
closes odoo/odoo#65805
X-original-commit: b27c0698d95cbccaa6c35a1fd3faa852a71ac2c2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
|
|
This commit partially reverts commit [1], and backports commit
[2] from 14.0.
Even though [1] correctly fixes the faulty scenario, there is a
variation of this scenario which isn't handled. It has been
fixed in 14.0 by [2], and that fix also fixes the original
issue of [1]. So we keep the tests of both [1] and [2], and
the fix of [2].
[1] dd97d446ee94a32089f200bb7122139d31e69873
[2] f6c06bd0b87dac11d76a3134eb61c7ef4eb59270
closes odoo/odoo#65562
X-original-commit: 63c60549ef5185f5ec61dc985f0bcc2cb82ccc89
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Issue
- Install "Field Service" app
- Create new task
- Try to select Planned start/end date and valid
Daterange picker is hiding when trying to scroll down to valid selection.
Cause
The daterange picker is closed when ev.target is not inside the picker,
however ev.target always return the document element.
Solution
Do not hide daterange picker on scrolling if on mobile.
Note : It will only apply if scrolling on the daterange picker and
will still hide if scrolling outside this last one.
opw-2428099
closes odoo/odoo#65423
X-original-commit: fb01006342c6d6fd902e13a5f4c2642c87fe452d
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
|
|
Steps to reproduce:
1. Go to Project App
2. Open and edit a task
3. Click on Customer => search more
5. Click on "Filters"
6. Click on "Group by"
=> The "Filters" and "Group by" dropdown are open at same time => bug
Since odoo/odoo@e4f87710e16357f24f388159a7b1e82eccda598a, we added a way
to prevent bs and owl dropdown to be open in the same time.
But when the web-editor is present, the CSS selector used to match the
opened modal ("search more" in this case) conflicts with the DOM created
by the web-editor (modals identified by the classes: .web-editor,
.note-picture-dialog, .note-link-dialog, .note-help-dialog).
To avoid this conflict, this commit uses a more restrictive CSS selector
to match only the first (active) opened modal (as web-editor doesn't
attach its modals at the root of the body).
closes odoo/odoo#65274
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
|
|
Let's assume the following situation: in a form view, there is a
one2many field A displayed as a list (non editable). In the list,
there is another one2many field B displayed with no widget (it
basically displays "X records"). In A's form view, B is also
displayed, but this time as a list.
There is an onchange on the main form view that adds a line in A,
(and simply sets B to [[5]], i.e. 'No record').
Before this commit, if the user opened the newly added sub record in
A, and clicked on 'Add a line' of B, it crashed.
The cause of the crash was that the wrong viewType was used to
create the new (default) record in B: it used the original
viewType, which was undefined (B is displayed with no widget in
A's list). With this commit, we use the viewType of B that is used
to edit it, in this case 'list'.
In the slighlty different scenario where B is displayed with
widget many2many_tags in A's list, there were no crash, but wrong
fieldNames were sent to the 'default_get' RPC. As a consequence,
default values for fields in B's list were potentially not loaded.
opw-2422806
closes #64793
closes odoo/odoo#65157
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
Let's assume the following scenario with 'purchase_product_matrix'
module installed:
- create a new Purchase Order
- add a line in the one2many
- select "Customizable desk" as product
- [the desk matrix opens]
- close the matrix
- select "Conference chair" instead
- [the desk matrix opens, whereas it should be the chair one]
It didn't work because of a small bug in the FieldOne2Many. This
field is configured to be reset when any other field in the view
changes. The product configurator feature relies on that. However,
when another field changes, the One2Many didn't update its internal
state with the new record (and it skipped the rendering, which is
fine). The matrix product configurator thus read an obsolete value
in the internal of the one2many.
Since the internal state is now always up-to-date, we can directly
read there the grid information, instead of looking inside other
fields that have been updated (attempt done in [1])
It would be nice to rethink the whole product configurator stuff
in master, to make it more robust, maybe when converting it to owl?
[1] https://github.com/odoo/odoo/commit/21bcafc053be7f80eed7a684fee2dc1e3caaafa5
opw~2421798
closes odoo/odoo#64552
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
stock.picking
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
closes odoo/odoo#62818
Signed-off-by: Nicolas Martinelli (nim) <nim@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
closes odoo/odoo#62399
Signed-off-by: Géry Debongnie (ged) <ged@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/39f08950d6e20460e3a20a5b9c33e4ddf66dce78
closes odoo/odoo#61593
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
|
|
Courtesy of translators
Reexport .pot of modified modules
closes odoo/odoo#61002
Related: odoo/enterprise#14485
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
The `remaining_days` widget is intended to be used for informative purpose,
hence it should not be editable.
opw-2362276
|
|
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
closes odoo/odoo#59208
Signed-off-by: Aaron Bohy (aab) <aab@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
closes odoo/odoo#59189
X-original-commit: 53dbfc7a65a8eb2f41d6b2373cf628c4800d1f57
Signed-off-by: Aaron Bohy (aab) <aab@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
closes odoo/odoo#59013
X-original-commit: e7d4baa3d52dc73c9631365801fbe41a4d54e3a1
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Issue was spotted in list views containing the "badge" widget with
decorations (e.g. in the Purchase Order list view). At first, the
decorations were correctly applied, but they weren't anymore after
a reload (e.g. after toggling a filter).
They weren't because the list renderer didn't called
'on_attach_callback' on its subwidgets at reload (thus, 'mounted'
wasn't called on its subcomponents, and the decorations are applied
in the mounted hook).
This commit moves the logic from the FormRenderer to the
BasicRenderer, so that it applies on List, Kanban, and Form views.
This commit also removes the transition scss rule on the badge
field widget as it caused a flickering at reload.
Task 2336440
closes odoo/odoo#57762
X-original-commit: 713bce22e8f412f2c26e663b9e30fdd64933ff0c
Signed-off-by: Michaël Mattiello <mcm-odoo@users.noreply.github.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Task 2327599
It is used in the selector of a tour to know the type of a document.
|
|
This new widget allows definition of Images through static urls stored in a Char field.
It was implemented to provide a way to reduce databases footprint by using
static files instead of duplicating them in the databases (& their backups).
|
|
The document layout preview is a complete defferent simplified template
with its own css that replicates at best the different styles.
It does not have the external layout features and lack of fidelity.
The new preview actually use the real documents templates and put the
result in an iframe. It now has a high fidelity, though not perfect.
The goal is for a better onboarding, where clients see easely how
documents will look if they had an app to generate them. Of course, the
data on the document is a false invoice.
Refactor all this from base to web.
Task ID 2304177
closes odoo/odoo#56415
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
|
|
This commit adapts the BasicModel to combine calls to `default_get` and
(first) `onchange`. When creating a new record, we now only call
`onchange`, which thus return default values and potential onchange
values.
Tests (and the MockServer) have been adapted accordingly.
NOTE 1. If the `default_get` within the `onchange` returns a value for
a field that is not in the view, we ignore it, and it won't be saved.
Before, that value was kept and sent upon save. This change in behavior
may prove problematic, although the overall risk is small. Decision has
been made to keep heavy comments and code snippets if we were to revert
back somehow to the previous situation.
NOTE 2. Putting a context on a many2one field may change the value
returned by `name_get` for that field. By default, the calls to
`name_get` are done by `onchange`. If the context on a field must be
used for `name_get`, one has to set the option `always_reload` to `True`
on the field. In that case, every `onchange` that changes the value
will trigger an extra `name_get`.
NOTE 3. Suppose that a one2many field has a list view with field A, and
a form view without field A. When adding a line, we now send all known
fields (main view and inline views) to the `onchange`, which may return
a default value for A. The value will appear on the list view, but not
in the form view. The former behavior was to call `default_get` with
the fields that occur in the form view only, and therefore field A would
be left to value `False`.
NOTE 4. A test surprisingly adds an extra call to `read`. The test was
actually wrong before. With the changes in MockServer, we now correctly
receive a command `[6, false, [1]]`, whereas before we received `[1]`,
which isn't a valid command, and which was ignored. As a consequence,
an extra `read` is done, whereas the test asserts it shouldn't. But it
already didn't work before (I checked by sending the correct command).
This needs to be bugfixed elsewhere (task-id-2323491): in a o2m with a
onchange and default order records on an other page than the first
should not trigger a `read`.
Task 2261084
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
Improve mock server:
- add support for mocked `fetch`
- add support for `active_test`
- add support for x2m `in` in domains
- add support for default values computed from a function
- implement a more natural "next id" compute
- allow initial data without ids
- ensure write and x2m commands integrity
- improve bad data/bad commands error messages
- always warn for failing RPC, not only in debug mode
- fix all existing tests that had inconsistency data
Other changes done in mail (or dependents) that are not just related to tests:
- remove `direct_partner` from formatter result
->`correspondent` can be computed from other keys, especially `members`
- fix `livechat_visitor` convertData
-> only process if there is value
- add `current_partner` and `current_user_id` as `init_messaging` result
-> easier to mock than session
- remove usage of `need_moderation`
-> that was just a search indirection to `moderation_status`
- adapt `partner_id` -> `res_partner_id` key in `_notification_format`
-> to be consistent with field name
- add name in result of `mail_partner_format`
-> sometimes display_name is not the same
- remove usage of `is_moderator`
-> that was just an indirection to `moderation_channel_ids`
Enterprise counterpart: https://github.com/odoo/enterprise/pull/11523
task-2287171
closes odoo/odoo#55854
X-original-commit: 7ba3fecb3377a720d1eb70e7515a0c45da73836d
Related: odoo/enterprise#12391
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
|
|
This commit adds smart date inputs for date and datetime fields.
The goal of smart date input is to provide the user some shortcuts
when setting dates.
The rule is [+-]\d+[dwmy]?
So we can enter inputs like:
+3 to have today + 3 days
-2w to have today - 2 weeks
+1y to have today + 1 year
+5m to have today + 5 months
-4d to have today - 4 days
closes odoo/odoo#55602
Task: 2270347
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Before this commit, user could not selecta a date before year 1900.
This was an historical limitation due to python < 3.2 that didn't
support dates before 1900.
After this commit, user can select any date, user can select any
date from 01/01/0001.
taskID: 2166761
Fixes #41788
Closes #43055
closes odoo/odoo#51406
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
Follow-up of odoo/enterprise#11881, in order to eliminate all similar
typos.
The CSS pseudo-class selectors are spelled `:first-child` and
`:last-child`, and never take any argument, as opposed to
`:nth-child(<nth>)` for example.
Ref: https://developer.mozilla.org/docs/Web/CSS/Pseudo-classes
jQuery doesn't care and matches with or without the `()`, but CSS
engines don't, and now libsass SCSS compilation crashes due to the empty
argument list (cfr. opw-2299465)
Better avoid confusion and fix the typo everywhere.
closes odoo/odoo#54685
X-original-commit: 82244e17339615615535073e6f9e1ddbcf0b57d9
Signed-off-by: Richard Mathot (rim) <rim@openerp.com>
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
|
|
There are orm models that don't have _rec_name defined. The orm doesn't
allow creation of record via name_create if _rec_name is not defined in
the model. This commit considers this fact, such that if name_create
returns false, we don't proceed on displaying the non-existing record.
Note: _rec_name defaults to 'name' if not specified so only few models
don't have _rec_name.
closes odoo/odoo#54270
Task-id: 2285036
X-original-commit: 676c2b8e4fdf7347d44bc5afb7ca51d39338a527
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Since commit 042b4060bdbbd, attrs 'column_invisible' on button was
ignored. This commit makes this work alongside the adjacent button
grouping feature: if all adjacent buttons have their attrs
column_invisible evaluated to true, no column is rendered for this
group of adjacent buttons.
closes odoo/odoo#53489
X-original-commit: 3110e34ab8e5ec3bf7160655af21f72b4d2179db
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Before this commit, the daterangepicker always opened below the input,
even when there was not enough space to display it. Moreover, when the
user scrolled while the picker was opened, it wasn't stucked to the
input, so the picker was displayed at a random position after the
scroll.
With this commit, we compute the available space above the picker
when opening it, and if there is enough space, we display it above,
otherwise, we display it below. Moreover, we automatically close
the picker when the user scrolls.
task-2117229
closes odoo/odoo#42161
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
|
|
This commit adds noLeadingZeroHour option to formatFloatTime.
The noLeadingZeroHour option can be used to format the value
like 1:30 instead of 01:30
This format behaviour is wanted for fields in web_grid module.
Task 2261853
closes odoo/odoo#52217
Related: odoo/enterprise#10870
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Hardik Prajapati <hap@odoo.com>
Co-authored-by: Mohammed Shekha <msh@openerp.com>
|
|
This commit adapts tests following recent changes on the helpers.
The main change is that addMockEnvironment (and all functions using
it) are now async, as they need to wait for services to be started.
|
|
closes odoo/odoo#52826
Related: odoo/enterprise#11084
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Generally, Users are not necessarily aware that they can quick create a most
records by simply typing in their name+enter in the many2xxx field input.
The exact purpose of this commit is to make sure the user discovers the quick
create feature of our many2xxx fields.
For that, when the input is empty, display 'Start typing to create a record...'
at the bottom of the dropdown when can_create is set and no_create_edit option
not set. So the user can easily understand that by typing and pressing enter
will create the new record.
Also "Search and Create" options in the dropdown only been shown to the user
when it type anything in the input box as the same case in the "Create" option.
Task : 2266557
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
|
|
When a resequencing is done inside an object hierarchy of two
controllers, since 9b90d8727d we would call resquencing code one time
per controller.
So if for example we are in a list view inside a form view (eg. a
"Search More" modal in a form view) the resequencing would work for the
list view, but then cause traceback when it is handled by form view.
With this changeset, the first controller that get the event
`resequence_records` even gobbles it up.
Without change, added test fails because of original traceback:
Cannot read property 'res_id' of undefined@ 202 ms
Source:
TypeError: Cannot read property 'res_id' of undefined
at /web/static/src/js/views/basic/basic_controller.js:744:67
...
opw-2256818
closes #51827
closes odoo/odoo#52018
X-original-commit: eef4b99fdb9469c040af80d055933eda367b7b3d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
The ColorpickerDialog will become a widget, this commit is only about
renaming the related XML file.
Part of https://github.com/odoo/odoo/pull/46088
task-2195313
|
|
In a form view, have an x2many list with two fields A and B (e.g.
A is a many2one, and B is a char). There is an onchange on the
x2many that is triggered when the user sets A, and that sets B.
In this scenario, let's assume that the user first writes something
in B, but directly deletes it. Then, he sets A. Before this commit,
in this situation, B wasn't updated with the value returned by the
onchange.
Indeed, B's field widget was still flagged as 'isDirty', because
the user interacted with it, but it didn't commit its value, as it
hasn't actually changed. Basically, it remained flagged as 'isDirty'
forever, and thus couldn't be updated with the value returned by
the onchange.
This commit ensures that the 'isDirty' status is correctly updated
when the change is actually undone.
Task 1958793
closes odoo/odoo#51085
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: pka-odoo <pka@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
|
|
In a form view, have an x2many list with two fields A and B (e.g.
A is a many2one, and B is a char). There is an onchange on the
x2many that is triggered when the user sets A, and that sets B.
In this scenario, let's assume that the user first writes something
in B, but directly deletes it. Then, he sets A. In this situation,
B isn't updated with the value returned by the onchange.
Commit [1] is an attempt to fix this, but it actually broke what
has been done in [2]. However, tests of [2] still passed, because
they didn't accurately reproduce what happens in practice (outside
the test environment).
An input field widget listens to 'input' and 'change' events. It
commits its value when both occur, but in the 'input' case, the
action is debounced with a large value (so that it actually only
commits the value on 'change', i.e. when the field is focusset
out). In the tests, the debounce value is 0, so fields actually
commit their value directly when 'input' events occur. This is
something we may want to change in the future, to remove this
discrepancy.
This commit adds a test with a large debounce value, so that we
accurately test what happens in practice, and we make sure that
this won't be broken in an attempt of fixing something else.
[1] cdca11db2ec207363df1d4fb3c87014d9c931d25
[2] a71f22370217d2da6ad13bd29c2fa412a40ebe4c
Related to task 1958793
|
|
Write something in a many2one field, and click on 'Create "..."'
to quick create a record with the given value (name_create). When
the name_create fails (e.g. because there are mandatory fields in
the model), we open a form view.
Before this commit, when this happened for many2one fields inside
x2many editable lists, it crashed, since [1].
[1] 50bf8309f88fb6c8d8e27b14d40450e92e5a4e4e
closes odoo/odoo#50948
X-original-commit: 43c513306094444ff25ad98584b426ddb8a3b525
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
This commit improves the dialog that opens when a user clicks out
of an 'un-commited' many2one. It is no longer possible to edit
the value, and the sentence has been reworded.
closes odoo/odoo#49528
Task: 2234212
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
In readonly, this widget displays the image of the related record
next to its display_name. In edit, it behaves exactly like the
regular many2one.
Part of task 2195254
|
|
This widget can be used on date and datetime fields. In readonly,
it displays the delta (in days) between the value of the field and
today. In edit, it behaves like a regular date(time) widget.
Part of task 2195254
|
|
This new field component displays the field's value inside a
bootstrap pill badge. Supported field types are 'char', 'selection'
and 'many2one'. The background color of the badge can be customized
by using the decoration-xxx mechanism, e.g.
<field name="state" decoration-danger="state == 'cancel'" widget="badge"/>
Part of task 2195254
|
|
Issue
- Install CRM
- CRM > Reports > Activities
- Add a custom filter > Created on
- Select the date
You can't, the date picker is not shown
Cause
Actually, the date picker is shown but
very quickly and it is closed by a scroll
event thrown by Chart.js.
Solution
Close the date picker only if the user
scrolls manually.
OPW-2245019
closes odoo/odoo#50482
X-original-commit: bda320052ac937f5bc17c7da81d84633d72a8370
Signed-off-by: Jason Van Malder (jvm) <jvm@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
|
|
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] d4cf4374d1baa529bb651bb3cc32e9db140963a8
Task : 2091027
closes odoo/odoo#49488
X-original-commit: 02e41f1131b4ea3ad977cc241a3d447c37195f6e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
