| Age | Commit message (Collapse) | Author |
|---|
|
Commit:
https://github.com/odoo/odoo/commit/818c18e55d0718286ff5bf332186a10f4d7a58ef
Updated the resequence logic in a way that was almost falser than before.
The added test however did work by coincidence, as index values were equal to
the sequence field values.
To be sure that we synchronize with what happens on the server, we do a read
after the resequence.
Additionnally, we take into account the result of the server resequence return;
if it is false, it means no resequencing happened, so we should not do a read.
opw 1867049
closes odoo/odoo#27184
|
|
In Firefox, the input behavior and visual representation (navigation, caret
placement, value selection, etc.) was broken when using a datepicker (easily
reproductible on date and datetime widgets).
This was due to the `focus` event being stopped on the input, which doesn't
seem to be correctly supported by Firefox.
The deleted code was supposed to toggle the picker when the field was clicked
(see odoo/odoo@89093a1) (toggle on click and disable focus) but the lib
correctly supports on focus without extra code.
This also fixes the fact that the datepicker was not open on focus (only on
clicked). In some tests where the field was the first in the form view, it is
now correctly autofocused.
Forward-port: not useful from 12.0 because the code has changed with BS4 and
this has already been applied in odoo/odoo@6692919 and odoo/odoo@c63630d.
Closes #23438
closes odoo/odoo#27657
|
|
The datetimepicker option was introduced to be able to customize the
datetime picker widget in date/datetime fields. However, due to the way
the _makeDatePicker function was coded, it did not work in datetime
fields.
Thank to Yajo for the initial fix
closes odoo/odoo#27541
|
|
cherry pick of 634de21b76b9
Before this commit, we had two different errors when data was
unavailable:
The first one is generated by Odoo: "No data to display, try to[...]"
The second one is generated by nvd3: "No Data Available".
We always want the same message.
So now, we always make some checks before rendering
the graph by calling _render.
opw-1874349
|
|
Hardening of commit:995610c065bf0242cb5023cfad2940234395739e
The JournalDashboardGraph requires nv, which is lazyloaded.
However it requires nvd3.js which is loaded after nv.d3.js.
A function called in destroy is defined by nv.d3.js,
which can make the crashhappen with the right (wrong) timing.
opw 1873749
|
|
The resequence mechanism works if the sequence is sorted by its handle field.
Therefore sorting on another field should lock the handle, while sorting on the
handle field should unlock the handle.
opw 1867049
|
|
The report layout "background" has an image background from bottom to
top. When we transform the report in PDF, we have no idea in the
document of how many page, which orientation, width or height it will
take.
Thus to be able to have the background at the bottom of a page when
there is not enough content, we set a min-height for the body content.
This height was 1000px originally and has been decreased to 900px in
41c75ad0c3 because an empty page was possibly added (since the height of
body + header + footer was bigger than page size).
This issue is about getting a blank page when pdf is in landscape.
For example in A4 with 90ppi has a 1052px height in portrait, but 744px
height in landscape so we always get at least two pages with possibly a
blank one.
With this commit we lower it to 620px allowing 124px headers/footers.
opw-1881059
closes #26962
|
|
This reverts commit 4cb585ab4f880147fbe35eb988c3c1da9728f624.
When creating from the kanban view:
- crm.stage
- hr.recruitment.stage
- project.task.type
- helpdesk.type
- mrp.eco.stage
We go from a dashboard of eg. "GroupRecord" named "group_id" in the
record. And when a stage is created, "default_group_id" is used. With
the change the stage was not linked to the current "grouping".
We could probably use "search_default_group_id" instead but the behavior
may be present in existing customization.
opw-1884217
closes #26943
|
|
This makes runbot Enterprise fail. Reverts until a proper solution is
found.
This reverts commit f4f1480a3e6c437c7d14929fadd0782a53171dd5.
|
|
CORS error was firsly fixed with 4bd8e3e2ed48 in 11.0
Then it was cherry-pick'd and improved in 10.0 with 9f1438d5f1b.
But the improvement was lost during forward port from 10.0 to 11.0.
This commit adds the lost fix.
Closes #26812
|
|
Before this rev., there was a crash when a FieldDomain was reset
with a new domain (e.g. coming from an onchange). For instance, it
crashed in Email Marketing > create new Mass Mailing > select
mailing lists. Introduced by 68332a01.
opw-1882850
|
|
|
|
|
|
|
|
Since march 2015, using in a domain "relativedelta(months=X)" with
X being bigger than 11 or lower than -11 would result in an error.
This is because in the refactoring adding modules (e8a00bc50d) the two
functions divmod and utils.divmod with different implementation in
pyeval.js were replaced by one function divmod in web.utils module.
But there was still an usage of the removed implementation.
opw-1880766
closes #26816
|
|
The resequence mechanism works if the sequence is sorted by its handle field.
Therefore sorting on another field should lock the handle, while sorting on the
handle field should unlock the handle.
opw 1867049
|
|
The calendar should use the time format of the language parameters.
Partial backport of d4b5668c1adf7430b5b53c8600ed89f672d0c76b
opw-1881335
|
|
When a column is created in the kanban view, the context of the window
action is fully given but it may contain default_{field_name} context
keys that are intended for the action model.
eg. on a product.product view we could have {default_type:'product'} in
the context, if we grouped by company_id and created a new company, we
would the context is propagated and we would try to set type='product'
on the company (which causes an error).
Without the change, the added test fails with:
default_* should be removed from context, actual: "true", expected: "false"
opw-1879064
closes #26676
|
|
Be in a grouped kanban view with progressbar with limit 10:
- records 1 to 10 are loaded on a column
- do "Load more..." on a column => records 11 up to 20 are loaded
- do "Load more..." 2nd time => records 11 up to 20 are loaded
- do "Load more..." 3rd time => records 11 up to 20 are loaded
- ...
While in reality it should be:
- do "Load more..." 2nd time => records 21 up to 30 are loaded
- do "Load more..." 3rd time => records 31 up to 40 are loaded
- ...
This was caused by the progressbar reloading the column's group. This
set the loadMoreOffset to 0 thus forgetting the current state.
Without the change, added tests failed with:
records of column are loaded => actual: "1,2,2", expected: "1,2,3"
opw-1878359
closes #26628
|
|
Suppose you select a customer for a sale order.
You type the beginning of his name "think", and a name_search is triggered
which finds matching results, with first result "Think Big Systems".
There are three ways to select it: click, enter or tab.
Now there can be a warning set on this customer
("Bad client, only accept cash", or "good client, offer discount").
In that case, clicking on tab would trigger the onchange displaying the warning,
but it would also set floating to true, which means a dialog to create client
"think" would appear.
This happens if the onchange is delayed, and thus the call to reset the floating
state is triggered only after the focusout completed, instead of before.
Coauthored with @aab-odoo
opw 1866619
opw 1874475
|
|
The pivot view didn't take into account the widget set on the fields.
In particular this was a problem for float fields that store time values.
They are now displayed with float_time if declared as such in the view.
opw 1876445
|
|
The domain was instantiated without being given any evaluation context.
As a result, the uid variable was not defined,
crashing the js if present in a user-defined filter.
opw 1866852
|
|
momentjs `isSame` method considers undefined values but not false
our method _isSameValue does consider false
Correct the error when running web tests
Deprecation warning: value provided is not in a recognized ISO format
|
|
Before this commit, when we applied two or more groupbys in line
graph, the groups displayed on the X axis where shifted to the left,
and the first one wasn't displayed at all.
related task: #1848289
Closes: #25037
|
|
Let x_1, ..., x_a, x_{a+1}, ..., x_{a+k}, x_{a+k+1}, ..., x_{n} be a record
sequence ordered by its 'sequence' field.
Suppose the reordering occurs between elements x_{a+k} and x_{a+1}.
If the subsequence x_1, ..., x_a is ordered, then it does not change.
This is also true of the subsequence x_{a+k+1}, ..., x_{n}.
The resquence function makes exactly this assumption, and only sends the server
the subsequence x_{a+1}, ..., x_{a+k} to update its 'sequence' field.
The update of x is done as follows: it is index + offset, where index is the
position of x in the subsequence, and offset is the 'sequence' of the first
element of the sequence (i.e. x_{a+1}.sequence).
It is easy to see that we need another hypothesis: that the sequence numbers are
unique. To show it, suppose that the sequence of x_1, ..., x_a is 0, then all
x_{a+1}, ..., x_{a+k} have sequence 1, and lastly all x_{a+k}, x_{a+k+1}, ...,
x_{n} have sequence 2. Then after the call to the server resequence, the
subsequence x_{a+1}, ..., x_{a+k} would have sequence numbers 1, 2,..., k.
Since the x_{a+k+1}, ..., x_{n} subsequence have 'sequence' value 1, this would
obviously be incorrect.
We fix the reordering of the data in the js frontend to be consistent with
what is done by the server.
Note that this is only pertinent for sequences of reordering moves, since
otherwise the data comes directly from the server.
opw 1867049
|
|
The feature was already declared in AbstractQuickCreate, but the
ColumnQuickCreate object did not define a _cancel function.
|
|
You:
- open a grouping in a list view
- check a line of this grouping
- open another grouping
=> all checkbox are unchecked
With this commit, 0982ceaa is improved so the selection is only reset
when the list has been reloaded.
opw-1865736
closes #26213
|
|
|
|
|
|
On a database where many modules are installed (e.g. runbot all), with
the option "manage available packaging options per products", doing a groupby
"product" on the "package type" list view triggers a js error.
It comes from the fact that the fixed_group variable contains a "length"
attribute; the _().each function uses this to determine (erroneously)
that the object is an array.
It thus uses fixed_group[0] to get an undefined, and then tries to access
a method of undefined.
We replace the each by a simple js loop.
opw 1863576
|
|
|
|
|
|
Before this commit, it was not possible to add an amount to a new
bank statement. The input (.o_form_field_monetary) appeared as disabled.
This bug was due to this commit: @a1224f5ca
This rule should be only applied to .o_form_field_radio.
Closes #18887
Task ID: 35832
|
|
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
Closes #25693
|
|
|
|
fixup of dc253ff1c65029e3795c1e49da0b16aa9e90db2a
|
|
Have ~50 records in a column,
Mark 49 of them as blocked (kanban_state field)
Mark 1 or 2 as done
Before this commit, the bar that showed the proportions of blocked objects was invisible
This was because the min-width of a bar was 10px, without max-width
Leaving the red bar to 95% or something, the green bar to 10px
All of this overflowing 100%
After this commit, we compute max-width and min-width to be able to fit everything
within the progress bar
OPW 1867464
closes #25962
|
|
|
|
Before this commit, the style of the value and text in some stat buttons were
broken.
The design of the stat button is to have a single value and a single text which
are stacked as follow:
[CSS] [Visually] [Example]
.o_stat_info +---------+ +------------+
.o_stat_value | | | |
.o_stat_text | value | | 10 |
| text | | Forecasted |
| | | |
+---------+ +------------+
However, some stat buttons use multiple values or texts. For example:
[CSS] [Visually] [Example]
.o_stat_info +-------------+ +------------+
.o_stat_value | | | |
.o_stat_info | value text | | 3 Hour(s) |
.o_stat_value | text | | Lost |
.o_stat_text | | | |
.o_stat_text +-------------+ +------------+
[CSS] [Visually] [Example]
.o_stat_info +---------------+ +---------------+
.o_stat_text | | | |
.o_stat_text | text value | | Min: 10.00 |
.o_stat_info | text value | | Max: 20.00 |
.o_stat_value | | | |
.o_stat_value +---------------+ +---------------+
The latter is works fine with block, which guarantees vertical alignment.
However, the former case has some alignment issues like this:
[Visually]
+------------+
| |
| 3 |
| Hour(s) |
| Lost |
| |
+------------+
This is due to the use of `display:block` for any `.o_stat_text` and `.o_stat_text`.
This commit fixes this issue, without affecting the other cases.
Task-ID 1841523
|
|
The value of the statinfo widget is rendered by the qweb after a t-esc.
Say if the python rounding returned 14.0000000001
(supposed to be a two digits precision number through the magic of floats)
then the statinfo widget would print it as-is.
We now format the value at assignation.
opw 1865426
|
|
|
|
one2many
In a one2many, if the user clicked the trash button while editing another line,
the row was not unselected.
Thus the modal was not triggered, which entailed that the currently edited line
was always saved.
In particular, it allowed to give empty values to required fields.
opw 1834346
|
|
multiple pages
Suppose there is a one2many field embedded in a one2many,
(say we are viewing record A with one2many field B itself with a one2many C).
Furthermore, there is a second page of the one2many field B.
If an onchange is applied on B, then the server replies with a 1 command for all
B records attached to the currently viewed object A.
This includes a list of commands [[5], [4, C_id]*] for each B record,
in particular B records that are on the second page.
Since they are on the second page, they might not have been fetched by the
frontend; in that case the corresponding C_ids are thus unknown.
As a consequence, on save the frontend sends a command 0 to create the records
for all unknown C_ids.
Since it doesn't have any value to give to the 0 command, the row creation
usually crash in the backend.
Another wrong behaviour is fixed at the same time: if the server sends an update
on the list of C ids with 4 commands.
In that case, if the record has not been prefetched, we have no way to know
if the list changed or not.
To solve this, when we receive the 4 commands by the server, we send back 4
commands.
coauthored by @aab-odoo
opw 1835936
|
|
Before this commit, there was a traceback in the following scenario:
Let's have a kanban view with groupby and a domain.
If we clear the domain then clear the groupby, there could be a crash.
This crash occurs because when we clear the groupby, it performs a `reload`,
and assumes that the datapoint contains grouped data. However, if this
computation takes some time, it is possible to overwrite the datapoint so that
there is no longer grouped data.
This commit fixes the issue by enforcing at most 1 execution of the method
`reload` active at any time. Consequently, successive reloads operations are
now much slower.
Note that it uses the single non-reentrant mutex on the basic_model to enforce
this rule, which means:
- No more concurrent `reload` and `save`.
- If an execution having the mutex in `reload` come accross the same mutex,
it is blocked forever. This is hopefully not the case at the moment,
however a reentrant mutex should be considered in the future.
|
|
Steps to reproduce the bug:
- Go on a SO and click on "Send by email"
- Remove the attachment and click on "Add an attachment"
- Choose an attachment A and remove it by clicking on the cross
- Click on "Add an attachment" and choose the attachment A
Bug:
The attachment didn't appear in the modal.
opw:1862482
|
|
|
|
Before this commit, the point of sale displayed a loading message
every 5 secondes if the barcode scanner was configured.
This issue is due to the following commit: @1aacc96
After this commit,some calls may block the interface when they did
not do it before.
It concerns all rpc done with ajax.rpc and all done with a new
session.
We have now to explicitly set shadow property.
opw-1860493
|
|
Let's assume a one2many A inside a form view, such that the one2many
views (list, not editable, and form) are defined inline, and there is an
onchange on A. There is another inline one2many B editable list
displayed in the inner form view (and B isn't in the list). There are
two records on the one2many A, both of them having one record in their
one2many B. Edit the first record of A, and edit it's subrecord in B.
Click on save. This triggers an onchange on A and the onchange returns a
command 5 (DELETE_ALL), and two commands 1 (UPDATE). Now edit the second
record of A, and simply close the dialog (e.g. 'Discard'). Save the main
record: the record in one2many B of the second record of A has been duplicated.
This occured because the code in BasicModel messed up information coming
from the onchange (UPDATE command) and from the read (performed when
opening the second record), thus producing a CREATE command instead of
an UPDATE one.
This rev. ensures to properly mix the read data with the onchange
result, by transfering the changes over the list datapoint created after
the read.
opw-1836785
closes #25330
|
|
Revision on b09f0c99
The intent of the previous commit was to no drop records in a list
on discard in the following cases:
- when they have been created from a `default_get`
- when they have been created from an `onchange` that result
from a `default_get`
Before the commit above, the kind of records that were abandoned
in those cases are stated as invalid, which happens when a record
has a required field that is empty.
The case of an `onchange` that is not involved in a `default_get`
was not considered in the fixes above. In fact, this is the intent
behaviour in most cases. However, if the items in the list are
created from such an `onchange`, we should not drop them.
This commit fixes the bug where records in a list that are created
from an `onchange` are wrongly abandoned. Here is the new logic to
abandon a record on discard in a list:
- the record that is marked as "do not abandon" should not be
abandoned;
- a record that is registered as a "not new addition" in the
list should not be dropped;
- a record that is registered as a "new addition" in the list,
and has been updated afterwards, should not be dropped;
- a record that is not new should not be dropped;
opw-806650
|
|
Avoid to crash the client web with setValue(false).
false.match, false.split, false.length... will not works.
Before this commit, _render call the setValue after comparing '' !== false
|
