This revision is related to dd47b6f5bc.
The above revision was allmost correct, except that, in a supplier
invoices, the `amount_currency` of the invoice is negative,
and the one of the bank statement is possitive.
To check that both are equal, we should subtract one to each other,
and check that the diff is 0, but both part need to be the
absolute value.
opw-634263
closes#6533
Prevents installing the hw_* modules at all when the python
dependencies are missing. If they were already installed
do not start the hardware threads to avoid wasting resources
and logging errors
This fixes :
* pagination only on /members and sometimes with bad page count,
* free members could not be searched (were always all displayed),
* all elements are displayed even if there is a pagination,
* for members without country, errors happened in some use case,
* when too much locations were on a map (>2000) it failed,
* numbers of members by countries was not displayed for guest.
And also as performance improvemnts:
* only query all partners when the map is enabled (customize > left
world map),
* limit partners put on the map to 2000 (even then it's a lot for
google maps),
* don't browse all membership_line to get res_partner but use a query.
opw-634653
Avoid ZeroDivisionError if a move is confirmed with quantity of 0 (when stored
in database where the rounding is done by the precision defined on product_qty
field.
Fixes#6439
When importing a CSV file with an "id" column containing
external IDs (XML IDs), the system automatically creates
or updates the corresponding ir.model.data entries.
This would fail for regular users who do not have
create/write access on this internal model.
When an opportunity has a 100% probability, it is regarded
as won. When the opportunity is regarded as done,
there is no more use to show the mark won/lost button.
opw-634420
The server parameter `log-db` gives the possibility
to store the logs of a server in a specific database,
in the ir.logging model.
Unfortunately, it wasn't possible to store these logs within
the database from which the logs came from in a multi databases
environment (e.g. the SAAS).
This revision gives the possibility to store the logs
within the database where the logs come from,
using --log-db=%d (inspired from the --db-filter arg)
We also added the possibility to change the level of logs to store in
the database, with the --log-db-level argument, which is set
by default to `warning`.
Update:
When an existing purchase order line is updated, for example if a new procurement was required,
we check if the sum of existing running linked procurements is larger than the quantity in the
purchase order. If it is the case, we update the quantity and the unit price accordingly.
Without this fix, we systematically add the procurement quantity (or the provider minimum quantity)
to the purchase order line, even if the sum of the procurements is smaller than the ordered
quantity.
Cancel:
When a procurement is cancelled, we recompute the unit price of the associated purchase order
according to the quantity and make sure the provider minimum quantity is met. If the required
quantity is zero, we cancel and unlink the purchase order line.
opw: 632175 and 632176
With Safari, the function content_disposition must return "attachment; filename=\"%s\"" % filename
to avoid that Werkzeug raises an UnicodeDecodeError.
Fixes#6160
opw:634205
When processing the reconciliation of a bank statement
within the company currency with an invoice in a foreign currency,
avoid to recompute the bank statement debit / credit within
the currency rate at the time of the invoice when the
`amount_currency` of the bank statement line and the `amount_currency`
of the invoice move line are the same
(while having the invoice move line and the
bank statement move line in the same currency,
and having the bank statement currency and
the company currency the same),
to prevent gain/loss exchanges during currencies conversion.
Computing the amount of the statement line
within the currency of the invoice is useful
to compute the difference of amount paid within the company currency
when a change of currency rates occured between the invoice date
and the date of the payment.
Nevertheless, recomputing the amount in the currency of the company
is useless when the payment currency
and the company currency are the same,
and the amount of the invoice and the statement in the foreign currency
are identical, since the amount is already computed, within the
debit/credit field of the invoice move line.
Besides, this prevents gain/loss changes.
opw-631748
opw-632133
opw-631895
closes#6559
When the target currency is the company currency, there
is no need to re-compute the debit/credit amounts of the move lines,
since these debit/credit values already contains the amount
of the move line within the company currency.
Avoiding the recomputation prevents gain/loss during currencies exchanges
opw-631748
opw-632133
opw-631895
If a line of the invoice move was in a foreign currency
but its residual amount in this foreign currency was 0,
the `amount_residual` (in company currency) was used,
instead of the `amount_residual_currency`, which
is the residual amount in this foreign currency.
This was due to the fall back with the `and / or` statement.
Using `if / else` instead solves the issue.
This could lead to issues when the residual amount
in the foreign currency was 0, but the residual amount
in the company currency was 0.01, due to the exchange rate
loss.
In SQL, the addition/subtraction between NULL and an integer/numeric
returns NULL.
Therefore, if either debit or credit was set to null instead
of 0.0, debit-credit returned null, instead of the actual subtraction
opw-634044
This reverts commit a1da6c2132.
This revision was a temporary patch to solve function fields
computation issues, solved thanks to the commit b7f1b9c01e
The `set` method of the one2many class returns a list
of the fields that require recomputation,
the computing of the function fields being delayed
for performances reasons.
Nevertheless, if the `set` method was called
through another `set` method, in other words,
nested `set` calls, the fields to recompute returned
by the second, nested, call to set were never recomputed,
the result list were simply lost.
e.g.:
```
create/write
│set
└─── create/write with recs.env.recompute set to False
│set
└─── create
with recs.env.recompute set to False
```
To overcome this problem, the list of old api style
compute fields to recompute is stored
within the environment, and this list is cleared
each time the store_set_value has done its job of
recomputing all old api style compute fields.
opw-629650
opw-632624
closes#6053
Use the sale description for suggesteds items.
So when seeing suggesteds items in a quotation, we so the sale description
(if there is one) next to the product name.
It was already done for contained items, but not for the suggested ones.
closes#6565
opw-634507
Consider a new field that uses the same compute method as another existing
field. When the field is introduced in database, its value must be computed on
existing records. In such a case, the existing field should not be written, as
its value is not supposed to have changed. Not writing on the existing field
can avoid useless recomputations in cascade, which is the reason we introduce
this patch.
This is related to revision bb913d0.
':' in product names are removed, to avoid issues when
searching products with ':' in their name.
JS replace method only replaces the first occurence, if the
needle isn't set as a regex with 'g', e.g. /':'/g
opw-634547
When seen from a mobile, the shortcut menu was over the content of the
quote and hid it.
This fix sets the menu inline in the page when he has no place to be on a
column on its own.
opw-633890
The lazy property `pure_function_fields` was not invalidated upon every setup
of models, and hence could contain old instances of fields. As every model
setup re-creates instances of fields, the property has to be recomputed.
Within the 'import invoices' wizard in bank statements
(addons/account/wizard/account_statement_from_invoice.py)
Prevent currency rate differences when the statement
currency is within the company currency (and therefore
the debit/credit fields are already within the currency
of the statement)
opw-631895
Closes#6504
Accessing `field.digits` can crash if no environment is available at that
point. This happens in function `get_pg_type()`, which is called from method
`_auto_init()`. An environment is simply created in the method's scope to be
available for `field.digits`.
The computation of property `digits` was creating a new cursor to call the
function that determines digits. This technique is fragile because the current
cursor may have pending updates that the new cursor will not see.
The issue was discovered by Cécile Tonglet (cto). She observed an infinite
loop during a database migration, and a traceback inside the loop showed the
presence of the `digits` property. This change fixes the infinite loop issue.
Christophe Simonis
Denis Ledoux
Olivier Dony
Nicolas Lempereur
Daniel-CA
Goffin Simon
Raphael Collet
Nicolas Martinelli
Jeffery Chen Fan
Levent Karakas
Rui Andrada
Manuel Vázquez Acosta
Alexandre Fayolle
Lionel Sausin
Arthur Maniet
belkacem77
Julien Legros