When having account installed, but having as only
access right "Contacts creation", it wasn't possible to
display the partner form.
Setting the "groups" on the button itself has as effect
to hide the button, but not to prevent its value computation.
If you did not had the access rights required to compute the
buttons values, it leaded to security issues.
Put the "groups" on the view instead prevent the button to be loaded,
and its value to be computed. It therefore avoids both
a useless computation (computing the value of a hidden button
is not really useful), and prevent any access rights warnings.
Besides, 3 different groups were needed to display the
three buttons:
- account.group_account_invoice
- account.group_account_user
- analytic.group_analytic_accounting
Not having one of these tree groups could lead to security
warnings. We therefore split this view into three sub-views,
with each one a group set (and a button)
opw-628668
Many trivial changes to journal items, such as the
"blocked" flag for litigation (follow-up), do not affect
the balance of the whole entry. These should not cause
the account.move to be (re)validated.
For example it should be possible to change trivial
fields even on journal entries recorded in a closed
fiscal period.
Since all the lines in a partial reconciliation share the same state and the same amount_residual, we need to keep only one 'result' line.
It was the first line found that was kept ; now it's the line whose amount is greater than amount_residual, whiwh most likely is the significant one.
Fixes#5129
In a workflow context (for instance, in the invoice workflow),
context is not passed.
Therefore, relying on the 'recompute' key being the context
in order to not recompute the fields does not work with Workflows.
It leads to huge performance issues,
as fields are recomputed recursively (instead of sequentially)
when several records are implied.
For instance, when reconciling several invoices with one payment
(100 invoices with 1 payment for instance),
records of each invoice are recomputed uselessly in each workflow call
(for each "confirm_paid" method done for each invoice).
With a significant number of invoices (100, for instance),
it even leads to a "Maximum recursion depth reached" errror.
closes#4905
When having an invoice with multiple lines having the same
product_id and account_id, the residual amount was wrong.
This is due to the fact the residual amount of each line
was computed on the residual amount of the invoice divided
by the number of lines of the invoice, and the fact the main
select of the sql view was grouped by product_id, account_id.
So, for an invoice defined as
Product Account Total
A 1 10
A 1 10
B 1 10
The invoice analysis, grouped by product, account, computed
Product Account Total Residual
A 1 20 10
B 1 10 10
The residual amount '10' of the first line being
30 (the residual amount of the invoice)
divided by 3 (the number of lines in the invoice)
The residual amount of the invoice should actually be divided by
the number of lines in the invoice * the count
of occurences in the group by clause
So, in this case, (30 / 3) * 2 = 20
Replacing the big jointure by
SELECT count(*) FROM account_invoice_line l where invoice_id = ai.id
to get the number of lines in the invoice
is just an optimization for performances
opw-621672
A record rule exists on currencies but not on rates.
If creates multiple currencies with rate = 1, we could fetch the wrong one in
the search and get a security exception while trying to convert rates.
Fixes#3323, opw 626353
This rev. is related to 6641c61ce6
During the above revision, a new jointure has been added
with product_uom, on product template uom_id
The join link was wrong, it was:
- LEFT JOIN product_uom u2 ON u.id = pt.uom_id
and it must be:
- LEFT JOIN product_uom u2 ON u2.id = pt.uom_id
as the alias 'u' is the previous jointure, not this new one.
Besides, the uom_name is now the name
of the product uom of this second jointure
As the uom is now the product default uom
instead of the category reference uom
The groupby clause has been adapted, as the selection was slightly altered
Besides, grouping by u.uom_type, u.category_id was pointless
Prevent creating/modifying accounting entries made on close periods.
The period_id and journal_id field on a account.move.line is a related so was
silently (without write call) updated so did not triggered the call to
_update_journal_check while modiying the linked account.move
Force the check in the validation of the move. As the move can not be balanced
without going through this method, this will prevent posted entries in closed
accounting period.
Fixes#1633, opw 615886
When fetching the VAT reports for several periods, only the last period was took into account
This is due to the fact that a browse record assignation no longer works in Odoo 8.0 API
at least not the same way.
code.sum_period = sum_tax_add just do nothing in Odoo 8.0.
Besides, using the variable "code" outside its loop is kinda crappy.
If the report was printed from the tax codes list
Accounting > Configuration > Taxes > Tax codes
There is no information concerning what should be displayed (periods, details, etc.)
as the user did not printed the report from the wizard
(from Accounting > Reporting > Generic Reporting > Taxes > Taxes report)
We therefore set default values, in order the report to not crash
Nevertheless, the user has obviously to go through the wizard
if he wants to set a configuration different than the default one
Before 8.0, the field journal_entry_id did not exist.
For database coming from older release, like 7.0, this field is not filled in during the migration, because this is not possible.
Set the needaction to depend only on the journal_entry_id will have as effect to have every bank statement line entered when the database was under 7.0 to match the domain, while the needaction is made to display the number of records that need an action.
Besides, even in 8.0, this is possible that a line has not the journal_entry_id set, while not needing any actions (see 2bb38ca89d)
For bank statement line having an account_id, but no journal_entry_id, it is not possible to reconcile the line in the bank statement reconciliation tool, as a filter is applied to only reconcile lines having journal_entry_id AND account_id not set.
As written in the help message of the account_id field:
This technical field can be used at the statement line creation/import time in order to avoid the reconciliation process on it later on. The statement line will simply create a counterpart on this account
Not allowing the reconciling should not prevent to close the statement in such a case. The button "close" was displayed only when all lines had journal_entry_id set.
Once the bank statement reconcilation done, the back button should not come back to Home when it does not found the bank statement list in the breadcrumb history, but simply perform a history_back action, which will come back to the previous action, the statement form for instance.
opw-625397
Revert edbd0df
Instead of removing the demo data (demo data is our friend), make the test more
specific, adding a date to match the rate of 1.5289 all year long.
Old demo data hardcoded the currency rate of USD to 1.5289 at the half
of the year, introducting new year red runbot.
Using assertAlmostEquals to avoid values like 32.730000000000004
Denis Ledoux
Arthur Maniet
Denis Michiels
Olivier Dony
Christophe Simonis
Martin Trigaux
Alexis de Lattre
Goffin Simon
Rifakat Haradwala
Aaron Bohy
Xavier Morel
Arthur Maniet
Arthur Maniet
Guewen Baconnier