`makeRecord` is now asynchronous as it will load data
for relational fields (X2manys and many2ones if `display_name`
is not fetched).
This change has implied a refactoring in all `makeRecord`
occurences to adapt with the returned deferred.
With the new views, the barcode mechanisms were completely broken,
because the view and widget JS code was totally changed.
This commit update and refactor all that code to make it work with the
new design philosophy. Also, it update the coding style.
The RPC system was not completely satisfactory, we decided to prepare
the future and do it properly. This commit introduces the new rpc
system, which replace the previous new one. We now simply have a
method, this._rpc, which takes a dictionary of parameters. The idea is
that depending on the parameters, it is able to add correct default
value when necessary.
For situations where we don't have the this._rpc method, we can use the
rpc.query method, which takes the same arguments, but directly calls
ajax.rpc instead of triggering up some events.
The new views and widgets (at least some of them) first landed
in web_studio (v10), and they we moved later to web, so changes
in web_studio need to be applied in web.
* account, mass_mailing, sales_team
These view extensions have already been ignored for around two years.
The new views development is a great opportunity to remove them.
We replace a bunch of formatting and parsing functions by an object
(parse or format) which can be used to dispatch on the correct type. It
allows us to remove the format_field and parse_field functions.
Also, we camelcase our new code and add some comments.
With our new views, we broke almost all JS code, including the
reconciliation widget, which was (and still is) dependant on the field
widget. With this commit, we rewrite and simplify the reconciliation
code. We also add some tests, to help with the maintenance.
Work done by CHM
Fine tuning of this commit: 69c41c7
When cancelling a payment, the remove_move_reconcile function was called and
it removed the payment from the invoice and in the payment history, only the
validated payments were kept.
This commit keeps the behavior before this commit: 69c41c7
opw:691692
Move the "dashboard_graph" widget to web.
It converts a Text field containing data to a graph. As it is a generic
widget, it can (and will) be used elsewhere.
The css clear was using jquery ui class for enterprise which now may
not be available on the given part. This commit replace it with class
defined in account_reconciliation.
With this the style could have issues such as not displaying the
congratulation message after reconciliation.
fixes#14743
In the reconciliation widget, create a counterpart line. No domain is
applied on the "Account" field regarding the company, meaning that we
can select an account from any company.
opw-694149
For the field "tax_ids", a command must be written in the the returned dictionary.
In this way, the ids of the tax will be set on the account move line.
opw:689806
ir.needaction_mixin is not used anymore by the webclient.
From 9.0, the concept has changed: this feature is now
available in mail module, with the mail.thread mixin,
and message_neeadction field.
Remove all code handeling needaction bullet and
counter on ir.ui.menu, knowing that since 9.0
webclient does not display the counter anymore.
This code was, thus, useless and some RPC calls
were done for nothing, and adapt accounting
reconcialiation widget.
An issue arises in the following use case:
- Company rounding policy in "round globally"
- Tax excluded of 20 %
- Create a statement of 3.80 EUR
- Reconcile the statement thanks to the reconciliation widget
- Click on "Choose counterpart" in order to manually create a line to
reconcile with the 3.80 EUR statement
- Add an amount of 3.17 EUR, and choose the 20 % tax
The widget creates an extra line of 0.00EUR . This is because the
remaining amount is 0.004.
The reason lies in the `monetaryIsZero` function. There is a hardcoded
decimal precision of 4, while it should be 2 for EUR.
We add an extra parameter to the function so it is possible to adjust
the decimal precision required. Only the problematic calls are modified
to avoid unnecessary intrusive modification.
Closes#13452
opw-688399
In details:
* account.operation.template object renamed into account.reconcile.model
* account.reconcile.model.template object created
* added some records for l10n_be
Was PR 11230
========
Purpose
========
The graphs on the accounting dashboard give the impression that we had $0 in the bank because the graph is at the bottom of the kanban kard.
==========
Specification
==========
The bottom should be zero, the top should be the maximum of the visible period, and the rest of the graph should be proportionate.
* This new button is a behavior change, but this is needed for big databases with a lot of statement lines to process. Indeed, in that case we prefer to load the widget as soon as possible and thus let the user process the lines manually or click on that button (but at that time he knows why it takes time).
* Opimization of various method in order to speed reconciliation and view opening : added indexes, direct use of sql queries...and also removed the code that was looping on open debit/credit to propose a sum of entries to match the statement line's amount, because it was a little greedy and wouldn't give accurate results most of the time.
Martin Geubelle