In account_budget module,
when creating a budget position,
the user can select view accounts and also accounts with consolidation children,
in addition to normal accounts.
However, when viewing budgets with positions containing only view accounts,
the "practical amount" field was always zero.
Since these type of accounts are accepted as budget positions,
the system should take into account children and consolidation children
when computing the practical amount.
Fixes#372Closes#1247
this is not necessary anymore, with the new kanban view. It also
paves the way for further changes (soon to be done): using a viewmanager
to instantiate the many2many kanban view
Don't preload company logo of the wrong company
When a user other than the admin signed in
and was in a company different than the admin
and this company had a different logo,
the company logo (in the upper left corner)
displayed the logo of the admin company,
instead of the logo of the company of this
user.
As soon as the user refreshed the page
in his browser, the issue was resolved,
but the logo should be the good one
from the beginning.
Closes#1453
More precisely, installing a theme module is valid if: there exists a module
such that all theme modules already installed or to be installed, correspond to
one theme module and its theme module dependencies.
Closes#7147
This is a really difficult optimization. Based on various benchmarks
and some hard thinking, we discovered that this change will shave
approximately 100ms for each drag and drop performed by a normal user.
We believe that this is a safe optimization in most cases (but we didn't
test it on some architectures, such as ARM or Solaris). It is also
compatible with most SQL JSON-enabled databases.
Fixes the impossibility to invoice purchase order lines, which were never
invoiced but set to invoiced by validating a first invoice created by invoice
control "manual".
In the method action_invoice, the call to the method "_prepare_analytic_account" in dict "inv_line"
had no effect because the value of account_analytic_id was being cleared by the product_id_change statement.
So in the end the invoice line was created without any account attached
Now it checks for an existing value, and if it is not already filled in,
the value from _prepare_analytic_account is taken.
Add a `delivery_type` selection field on delivery.carrier.
The default is `grid` i.e. a static pricing grid with rules
to compute the delivery costs.
Future module will however be able to extend the `delivery_type`
selection to add new keys, such as `fedex` or `ups` and provide
custom implementations for the various API methods, as described
below.
In order to add your own external provider, follow these steps:
1. Create your model MyProvider that _inherits `delivery.carrier`
2. Extend the selection field `delivery_type` with a pair
('<my_provider' , 'My Provider')
3. Implement API methods as required:
<my_provider>_get_shipping_price_from_so
<my_provider>_send_shipping
<my_provider>_open_tracking_page
<my_provider>_cancel_shipment
As of version 8.0, search_count method has been implemented
Usage in this place is not needed though,
as we just need to know if there are messages in domain,
not the exact number of them.
Due to that we replace method search_count with search and add a limit of 1,
which provides better performances.
Fixes#6670Closes#6679
- Remove the Bid notebook on the purchase order form.
- Add a message on the chatter to display the field Bid Received On
- Move the field Bid Valid Until under the Order Date field, displayed only if Bid Received on is filled.
- Remove Invoice Received Checkbox, as there is now a stat button to display the information
- Add a default filter "To Do" on the RFQ and purchase order views, which displayed all the record not in the states done or cancelled.
- Changed several labels, and reorganized some options in the configuration.
When invoicing in currency A and being paid in currency B, the exchange
rate between those currencies might differ between the invoice date and
the payment date.
When reconciling, invoiced amounts should be converted using the invoice
date exchange rate.
opw-640248
In the Account Tax Decalaration wizard,
Accounting > Reporting > Generic Reporting > Taxes > Taxes Report,
When not choosing the start/end period, but choosing
a fiscal year, the fiscal year was simply ignored,
the report took a fiscal year randomly.
In addition, if no fiscal year was chosen,
the fiscal year randomly chosen could even
not be a fiscal year of the right company,
in a multi-company environment.
closes#7219
opw-643194
Some tests (e.g. mail) have expensive and significant DB setup for a
number of small and cheap tests. Using a TransactionCase, the DB setup
far dominates the tests themselves, by up to 10x (mail unit tests take
~130s on my machine, the tests themselves take ~15s).
The SavepointCase introduced here is an hybrid of SingleTransactionCase
and TransactionCase: it uses a single transaction for all tests in a
class, but each test case is isolated by a rollbacked savepoint. This
allows a common DB setup (via setUpClass) while keeping independent
tests.
TransactionCase should remain the primary test case superclass, but
SavepointCase can be a fair optimisation when setup costs far dominate.
The computation of total_invoiced field was very slow when the size of
account.invoice.report grows. This is due to usage of the field
user_currency_price_total that requires to build the full view (generates query
(id in []) for function field).
Using temporary SQL view (inspired by caf333e), directly filter the needed
items and avoid building the full table.
Fixes#6654
Martin Trigaux