Editable grouped list views isn't a supported feature. Before this
rev., grouped lists weren't automatically set as non editable, so
it could cause crashes when the user clicked on rows of grouped
lists with editable="top" or "bottom".
This was for example the case in Timesheets > All timesheets ->
go to list view.
The 'data' attribute of exported datapoints (using 'get') must
contain a value for each field in the view, and the default value
is false when those fields are unset. The code manipulating those
datapoints supposes that this is the case and it makes it easier
and clean.
However, it wasn't the case for x2manys in new records for which
the default value contains CREATE commands with missing fields:
in that case, those missing fields weren't added in data.
This caused a crash in the Employee form view, in edit, if the user
clicked on 'Create and Edit' of the 'Working hours' field, because
some code in field_utils assumes that if the value of a date field
isn't false, it means that it is a moment instance (but in that
particular case it was undefined).
This was causing an error in the form rendering as a group does not
accept text as direct child (and displaying '/>' as text was probably
not the desired behaviour.
The buttons were not updated after column creation.
This was causing an issue in an empty kanban when you created a new column,
the 'Create' button was not highlighted.
After the record deletion, the parent should be updated to take the deletion
into account.
This was causing an issue in the Kanban view: after a column deletion, it appeared
again if you created a new one.
The attribute `widgets` has been renamed in rev https://github.com/odoo/odoo/commit/7ff8aa73e17b281b3e2bc4c7275d020eab0204e7#commitcomment-22116249
However, KanbanRenderer still uses a `widgets` attribute, not for the fields
widgets but for its columns (or records if ungrouped).
These widgets weren't correctly destroyed since then.
This was causing an issue when you were trying to quick create a record after a
column creation (that generates an update): the quick create was added in the
first old column (which was not in the DOM anymore) so you couldn't see it.
The kanban group expects to have local ids in its data and not the whole
datapoint.
This was causing a traceback when adding a new column after adding a record.
Previously, the string attribute of the field node was ignored
in the title of the form dialog and it always displayed the
string value of the python field definition instead, which is
a default value instead.
Additionally, I took this opportunity to add tests for other
similar dialog titles which actually worked already with the
string attribute of the field node but were not tested yet.
Previously, when a checkbox was re-rendered, it was losing focus
since it was removed and re-created. Now, if the checkbox itself
is the origin point of the re-rendering, we give the focus to the
newly re-rendered checkbox, resulting in a seamless experience
just as if the checkbox was never removed and re-rendered.
In some cases, we had duplicated footers in form view dialogs. It
actually happened when the view was reloaded, which is not particularly
frequent, but happens most of the time the user clicks on an action
button, which does not close the window.
To reproduce the issue, you can open the lunch module, click on the
'Feeling Lucky' button. It will open a form view with a special button
in the footer: 'I'm feeling lucky'. Clicking on that button will return
an error (no order matches the criterion), and will trigger a form
reload. Then, you will see two footers: one in the modal footer, the
other one in the form renderer.
The solution to this issue is to make sure, when we update the view and
a footer tag is found in the form renderer, to replace the current
footer buttons by these new buttons.
Handling datetime is not a good idea, mostly
when computing different in terms of days.
Forcing the hour (time) will set the tests correctly
regarding the working hours, and the datetime
difference, independently of the execution time
of the test.
Before this commit, the new form view implementation was rendering
<newline/> tags as real <newline/> DOM element. The wanted behavior
is now restored:
- As outer group direct child, produce a <br/> tag, forcing the next
group children to be on a new line
- As inner group direct child, produce nothing but forces the creation
of a new <tr/> (for the next group children)
The original goal of the commit was to implement a missing behavior
for label tags in form view. This finally need some deeper refactoring
for it to work so this commit does not introduce any change in behavior,
only comments explaining the problem.
When a field widget switches between readonly and editable states, it is
fully rerendered. Labels have sometimes to get a specific class when
their associated field is (become) readonly and without any value. This
condition was evaluated on the initial widget and not on rerendered
ones.
Note that this commit only restores an already implemented behavior
broken by https://github.com/odoo-dev/odoo/commit/8f9362809e91ff7c2876ab464017abb13a4e0974
... but this time a test will prevent a new breaking
Even if the `default_order` attribute should be like 'name,id desc,coucou'
we want to support the syntax 'name, id desc, coucou' (i.e. with spaces after
the comma).
The commit also patches the mock server.
Usecase: A person scans various products in a warehouse or the network is slow.
Only one request per product must be made, the rest is changing the number locally
and all performed scans (products or actions) must not be lost.
The mutex ensures that the scan is performed in the correct order.
Functionality deprecated since v9
Add also some small rendering fixes for manual reconciliation:
* display congrats only once
* display journal_id as required
* use isValid to create a new proposition line
* Can erase all proposition lines in manual reconciliation
Current new implementation of the form view ignored several properties
linked to <group/> elements:
- groups' col attributes were considered to always be 2
- groups' children colspan attributes were considered to always be 1
- elements different than <field/> and <label/> in groups were forced
to their own row
- it was not possible to have a group hierarchy deeper than 2
- <td/> elements widths were not properly set
- ...
When a qunit test fails, the log only contains the assertion message.
This is in fact useful to have the "actual" and "expected" values to
understand the bug.
Also, we recently updated the configuration so that the "hide passed
tests" option is enabled by default. This is in fact useful to have
it disabled if the user wants to run only one test (debugging).
The pad widget was partially updated to the new views, but was no longer
working. In this commit, we rewrite the widget to make it work.
Note that we did some functional changes:
- we do only one rpc to check if the server is configured. the result is
stored on the prototype, so we do not need to do it again
- we do some rpcs with shadow: true, so we will not stop the rest of the
ui if the server is slow to respond
- we display a loading message in readonly, when the content is not
loaded yet.
We fix in this commit three small issues in the test framework.
1. throw an explicit error when we try to do a fieldviewget in the mock
server with a model that does not exist. This will make it easier to
figure out what went wrong when copy pasting a test from one file into
another, and forgetting to change the model in the createView parameters
2. wrap the result of special methods in the mock server in a deferred,
so we can simply return a value when using that functionality. Also, it
is more consistent with the rest of the mock server
3. for iframes, we no longer change the src attribute to #test:url.
This had the problem of actually loading the page. Instead, we change
it into about:blank and we copy the old url into the data-src attribute for
reference.
With this commit, we prevent view dialogs from changing the 'global'
environment in the view manager. Here is how it could cause a problem:
* open a form view for a bill of material
* click on one of the component, it will open a form view in a dialog
(and will change the environment with a wrong res_id)
* click on the many2one product -> it will open a new action in the
background, and change the environment again
* click on the breadcrumb to come back to the bill of material: the view
manager will try to restore the correct res_id (which is the wrong id
from the component form view), the form view will do a read (when
reloading the data), will get an empty result, will update its
information with no data, then will be in a wrong state which means
that the basicmodel will fetch a x2many with a wrong res_ids list
* boom
Before this commit, numbers in list views were right-aligned
depending on the widget they were using (float/monetary). Now, the
input text alignment is inherited from the parent which should
solve the problem.
The field move_line_ids was present in the view and used only for display
purposes. However modifying another field triggering an onchange (e.g. a payment
line) was recreating the move lines.
Recreating the accounting entries may trigger an error if the entries are
already posted.
The entries are recreated because:
1. the move_line_ids is loaded with the default tree & form view for
account.move.line records, displaying several fields
2. some of the fields (e.g. reconciled) are computed
3. the initial onchange recomputes all the computed field, including the one
on the one2many (e.g. recomputing move_line_ids.reconciled)
4. the field being dirty, the onchange returns the value of move_line_ids with
[(5,),(1,id,{...}),...]
5. trying to save the modified lines may fail
Replace the field by a simple readonly integer field.
opw-741205
Aaron Bohy