In order to have some data to display in the dashboard views, we need to
set the create_date of the crm.lead and sale.order so that they are not
all created today.
We can now set the create date directly in the demo data, so we remove
the hack that was previously used in website_sale
This rev. is similar to db9b91ff, but treats the x2many case.
Calls to the 'commitChange' function of renderers must not be done
inside a mutex, mainly since 241704536, as they could end up in a
deadlock. For x2manys, it was actually the case in practice in
Inventory > Operations > Inventory Adjustments > Create > select
'One product only' > select a product > try to edit the real
quantity in the editable list > focusout > deadlock.
The reason why the deadlock occurred in this view and not in, e.g.
sale.order, is due to the presence of the field_float_scannable
widget. Indeed, the barcode engine intercepts input events and
manually re-triggers them. As a consequence, the 'change' event is
not triggered on the field, and it does not notify the environment
of its new value by itself, until the field x2many asks it to
commit its value. Note that this might be an issue as well, as
onchanges are thus not triggered.
Task 1878254
Rev. f241441 recently added the possibiliy to define custom
controls (instead of the single 'Add a line') in editable list
views. However, it didn't take into account keyboard navigation.
Suppose that the focus is on the field preceeding the list, and
the user clicks on TAB, the code assumed that there was only one
control, and focused it. However, when there were several control,
the last one was focused (which is typically the less common one),
and there was no way to navigate to the others.
This rev. focuses the first control by default, and allows to
navigate through controls with RIGHT and LEFT. Pressing TAB still
moves out of the list, to the next field.
Note that i'm not happy with this fix, as the logic doesn't seem
to be in the right place. Indeed, the notion of controls is the
concern of the editable list, not the x2many field, so the list
should handle this logic by itself. Unfortenately, this is not that
easy to change, as for now the list doesn't even know that we are
navigating to/from its control(s), until we click on it/them.
Changing that will be for later, in master.
We also did a linting pass on the concerned code.
Task 1878254
We're not shipping the sourcemap files, and while the assets minifier
strips out the mappings they're getting hit in debug=assets which is
bot useless and problematic when running odoo-bin without a proxy for
static folders: if sourcemaps are enabled (which is apparently the
default in all browsers if devtools are opened at this point) the
browser tries to fetch the sourcemap, which does through the
SharedDataMiddleware which doesn't find them and passes the query on
to the regular Application which goes through the entire dispatch &
NotFound process.
If website is installed, that process ends up rendering website.404,
which can be pretty costly until everything is properly cached:
# initial request
"GET /web/static/lib/bootstrap/js/index.js.map HTTP/1.1" 404 - 319 0.198 0.954
# a few requests later
"GET /web/static/lib/bootstrap/js/index.js.map HTTP/1.1" 404 - 27 0.022 0.060
And the way sourcemaps are fetched (might be headers, might be the
stampede as browsers will try to fetch a dozen sourcemaps as fast as
possible) seems to make this problem much, much worse: instead of 300+
the requests take 800+ queries each, multiple seconds, and requests
get worse as time goes on (didn't investigate the exact reason for
that) *and* they apparently don't ever get cached (at least they don't
after half a dozen reloads of the client).
Steps to reproduce the bug:
- Create a journal "Temporary" with default account
(don't care about the names) with Fixed asset type and reconcile = True
- Create a vendor bill
- Create a payment from this vendor bill in the temporary journal
- Create a bank statement and with a line where you specify the vendor
- Try to reconcile the temporary account with the bank account
Bug:
Impossible because the temporary account item was not displayed
opw:1884376
When saving the settings, the `google_drive_refresh_token` is never set.
This is due to the `ir.config_parameter` which was retrieved after being
saved.
opw-1882068
By default, the `set_value` method doesn't do anything, and is expected
to be overridden. However, `ir.default`, groups and
`ir.config_parameter` are set BEFORE `set_value` is actually called.
This is an issue when it is necessary to retrieve one of these values
before the save, for example in order to compare the value before and
after.
We move the setting of the various values directly in the `set_value`.
This way, it becomes possible to interact with the values before any
modification is performed. On the other hand, the existing logic remains
unchanged.
opw-1882068
- Create a partner in Germany
- Set an invoice address for this partner in Poland
- Create an invoice for the Poland address, but the delivery to Germany
- Validate invoice
The Intrastat reports the transaction in Poland, while it should be
Germany.
opw-1878590
When fetching messages from the portal controller, we might
give a domain to restrict the message selection. Typically,
the ecommerce allows users to submit messages with rating
of the product. Users are allowed to filter the messages
with a certain rating.
Passing a non-normalized domain to this controller could
give strange result, as the code was using `+=` to concat
domains; some result domain could have been correct, but
return some strange results.
This commit normalizes all domains used in the code
making a non-normalized domain (given as parameter) crashes,
instead of returning unexpected messages.
Closes#26939
This reverts commit c539311. The default taxes will now be found in the invoice's onchange() which makes more sense and will work on all income/expense accounts without having to set the taxes on all these accounts.
This will be used to add the 'Upload' button on the tree view of vendor bills, by extending the regular view.
Was part of PR #26740
Was part of task #1880089
This is done by adding a new field on mail.thread objects and setting it when posting a message with attachments on a model inheriting from mail.thread.
Was part of PR #26740
Was part of task #1880089
This commit fixes the handling of the service parameter
in a mocked environment:
- updated docstring: now an object (previously an array)
- no longer used by mocked server (unused parameter)
- enforces default value for this parameter (empty object)
The test was failing because it was using an old approach to mock
services in JS tests. Also, it provides ajax service in the list
of services, which was not supported in a mocked environment.
With this commit, when an ajax service is provided in the test,
it will use this service instead of using mocked RPCs from the
mocked server.
Since https://github.com/odoo/odoo/commit/4330ea02676a4afd88707bb463a007e7de3c8686, action_mark_won was
not api.multi anymore, which made it impossible to mark leads as won in
batch.
The problem is that we do exactly this in the demo data.
As we need to keep the rainbowman in the interface the decision has been
taken to split the method in two parts, one for the interface which
returns the rainbowman (and uses ensure_one) and the second which is a
true api.multi method.
Thanks to @tde-banana-odoo for his advice on the matter
cherry pick of 634de21b76
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
Changes made at #23879 changed the dependency of l10n_cn to include a large
list of cities.
Move to a different module to make the l10n_cn more lightweight.
Closes#26592
When filling the results of a read_group using
_read_group_fill_temporal we were using the name of the field.
(https://github.com/odoo/odoo/commit/283c842289f1bc06bc30a877864e868127418e80)
But _read_group_format_result needs the name of the groupy which can
differ from the name of the field as groupby supports the following
syntax for dates `field:groupby`
This ultimately lead to a crash when trying to groupby multiple date
fields in a graph view.
Linked to Tasks : #1879604 and #1879168
It was already present in the accounting and purchase application but not in
sale menus.
Apply the same logic as in purchase and use a group_no_one
Closes#22862
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 xpath on the res config settings view was attached to a div added in the
account module but the record was inheriting from base and not account.
As snailmail account inherits from account, it was somehow working.
Thibault Delavallée