- Set up Paypal as described in
https://www.odoo.com/documentation/user/11.0/ecommerce/shopper_experience/paypal.html
- Buy a product on the eCommerce.
The vendor might receive an email mentioning that Instant Payment
Notifications (IPN) are failing.
When completing the paypent process with Paypal, 2 confirmations of the
transaction will occur. The first one is through the route
`/payment/paypal/dpn` (Payment Data Transfer (PDT)), which takes place
right after the payment validation. The second confirmation comes
through the route `/payment/paypal/ipn` (Instant Payment Notification
(IPN)), which might arise with some delay (and potentially being run
several times).
Both confirmations will trigger the method `_generate_and_pay_invoice`,
which can raise an error if no invoiceable line is found ('There is no
invoiceable line.' in `sale` module). In this case, we should log the
error and move forward instead of crashing and stopping the workflow.
More information on PDT and IPN at
https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNPDTAnAlternativetoIPN/
opw-1837196
In case of changing the quantity on hand of two variants of the same product,
the two message created will have the same name (the name of the
product.template).
Show the name of variant instead.
- When a quotation if viewed by a customer, a note is posted in the quotation's chatter saying "Quotation viewed by customer".
This is causes issues if the quotation is accessed without the access token and by a partner that do not have the rights to write on the model "sale.order".
To address this issue we provide to the "_message_post_helper" function the sale order's access token to bypass the accesses checks.
OPW-1839183
When validating a delivery order with automated inventory,
some accounting moves are created.
Since an inventory user might not have accounting rights,
the validation of delivery orders might fail.
We simply had a sudo when in the internal method creating the move.
Moreover if the inventory valuation is set in FIFO,
the product price might be updated.
It might fail for lack of additional rights.
We add a sudo for this price update.
opw 1836761
When validating a delivery order, some stock moves might be merged by an
internal function, which thus might delete some stock moves.
Since an inventory user has no right to unlink stock moves,
the validation might fail.
We simply had a sudo when doing the unlink, since this is an external method.
opw 1836761
Commit 542201eed3 added the possibility to configure a set of countries for a
given payment acquirer.
Commit 194d52e8fd refactored the payment form, but forgot to take the country
into acount.
opw 1837819
- Create a product named 'toto'
- Perform a call to `name_search`:
`self.env['product.product'].name_search('pouet', [], 'not ilike')`
Product 'toto' doesn't show up in the result list.
The domain should take into account that `default_code` can be `False`.
Note: the bug also occurs if the product is called 'trululu'.
opw-1837957
Remove behaviour introduced by [1], if there's a price difference the
price difference account will be used. This code block did not take into
account the fact that out move have a negative price unit, resulting in
inverted debit/credit. Furthermore, there's no special case for return
of standard and fifo.
[1] 1df16a189e
opw-1828196
- Set a default value for the field 'Activity Type'
- Schedule an activity
The default value doesn't appear.
The default value is taken into account, but the onchange override the
value.
opw-1838066
This commit adds the auto-creation journal for installed acquirers.
This is not easy because:
- The acquirers are created on the 'payment' module but are enabled only when the specific module
is installed. E.g. Paypal is enabled with 'payment_paypal'.
- To create a journal, a chart of accounts is required. However, the post_init_hook on the
'account' module makes the installation order harder. E.g install payment_paypal directly:
The module are installed in the order: account -> payment -> payment_paypal -> l10n_generic_coa.
To fix the problem, the journals are created at two moments:
- During the installation of the chart of accounts.
- At the installation of an acquirer module. E.g. payment_paypal.
Was PR #23904
Was task: 1831620
Steps to reproduce the bug:
- Create a stockable product P
- Create PO and confirm it
- Cancel the PO
- Reset the PO to Draft and reconfirm it
- Validate shipment order
Bug:
- The "Receive product" button is still displayed but every shipment orders of the
PO have been treated.
NB: The field is_shipped is only used to display the button "Received product".
opw:1838539
It was possible to change manually the company of an asset, although its category would be belonging to another company and thus its depreciation lines and journal items also.
To tackle this problem, we set the company_id field of an asset as related to its category
Was PR #23498. Courtesy of Miquel Raïch
When in Python 3, then function `open` defaults to open the file in text mode
with and the encoding (if not passed) is taken from
`locale.getpreferredencoding`.
Using `getpreferredencoding` is not necessarily a good practice. Because
files might no be encoded that way.
When testing Odoo not in runbot (which has LANG set to C.UTF-8) you may get:
Traceback (most recent call last):
File "/home/gitlab-runner/src/odoo11/addons/web/tests/test_js.py", line 24, in test_check_suite
self._check_only_call('web.qunit_suite')
File "/home/gitlab-runner/src/odoo11/addons/web/tests/test_js.py", line 37, in _check_only_call
if RE_ONLY.search(fp.read()):
File "/home/gitlab-runner/virtualenvs/odoo11-MlnlRiTaP2/lib/python3.5/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 4757: ordinal not in range(128)
The proposed solution is to read the file in binary mode, and decode to
unicode/str ourselves using utf-8. We don't use the encoding argument of
`open`, so that the code works in both Python 3 and Python 2.
PR #24434
Before this, the progressbar values were not updated (both count and progress)
after archiving all the records of a column.
Multiple things have been done here to update it.
Firstly, a optimization had been done to avoid reloading the progressbar when
updating a column ; this optimization was not correct due to this precise use
case. This will update the progressbar.
Secondly, the `aggregateValues` are reset when putting empty groups back in the
datapoint. This attribute is used to compute the counter if a `sum_field` is set
on the progressbar widget. It needs to be reset because the loop that computes
it won't iterate on empty groups.
Eventually, the mockRPC of the progressbar route was not taking the `group_by`
argument into account (probably a typo).
Use case fixed: manual reconciliation through the account.move.line list of items with several currencies, that will create a full reconcilation with several exchange rate entries to balance the amounts in all foreign currencies. Unreconciling these lines was wrongly creating an account.move with a lot of lines with debit = credit = amount_currency = 0.
Usecase to reproduce:
- Create a product A with a qty on hand 5.5
- Create a delivery order with an initial demand of 5.5
- Validate it with a qty equals to 5.95
The initial demand is updated to 5.951 then reduced to 5.95
and a backorder is created with an initial demand of 0.001.
That should not happen since I process extra quantities.
It python 5.95 - 5.5 = 0.4500000000000002 and the float_compare
use a round UP method thus it returns 0.451 and the following
flow is based on a wrong value.
In this case a float compare is used before the float round, so an
HALF-UP rounding should be okay since a very small quantity diff should
be filter by the compare.
Fixes#24401
- Company currency in EUR
- Create 2 rates for USD:
1.0 on 2018-01-01
0.5 on 2018-02-01
- Create an invoice on 2018-01-02 of 111 USD
- Register a payment on 2018-02-02 of 111 USD
- Unreconcile the payment
An error occurs: 'You are trying to reconcile some entries that are
already reconciled!'
In this specific case where the rate decreases, the exchange rate entry
is reconciled with the payment, so we need to keep the payment entries.
When a scrapped move is part of an open picking, it was not possible to
unreserve the picking. A scrapped move is done and scrapped ; this
combination should be allowed.
opw-1835186
- Create the following reconciliation model:
Line 1 is 50% of amount, tax is 20%
Line 2 is 50% of amount, tax is 0%
- Use this reconciliation model to reconcile an amount of 1000.
4 lines are created:
- 2 lines for base amount (500)
- 1 line for the 20% tax (100)
- 1 line for the 0% tax (1000)
Obviously, the last line is incorrect, and should be 0.
opw-1837049
The calculation of the delivery cost for a sale order / invoice was not correct when
free over a limit had been satisfied.
Steps to reproduce the bug:
- Set a delivery method DM with a fixed price = 10.0 and free when the amount of the order exceeds 100
- Create a SO for an amount of 150 and set on it DM
- Confirm the SO and deliver it
Bug:
A SO line with DM was created with a fixed price of 10.0 instead of 0.0
opw:1838070
When doing several grouping quickly (or if the system is slow) on the
pivot view, we may try to display data that now doesn't corresponds to
the current selected groupBys.
This commit ensures that when we load data of the pivot view, we drop
the previous data loading that are currently being carried out.
Without the fix, the added test failed with:
TypeError: Cannot read property 'length' of undefined
because the test does:
- select one level of group by
- select two levels of group by
- resolve the first level of group by
- resolve the second level of group by
Without the fix, we would try to display the data for one level of group
by when the pivot view had two levels selected.
With the fix, displaying the first level of group by was discarded once
a second one was being requested.
opw-1825892
closes#24396
If the user has limited_access, download_security field was not read due to the
override of check_field_access_rights and so the field not set.
When you try to access/read it, you got: Selection is not iterable.
Now we check in sudo the download_security.
We also add the **kw that should be present in all routes.
Avoid: "slide_download() got an unexpected keyword argument 'debug'"
We also remove this controller from the sitemap.
Use case fixed: manual reconciliation through the account.move.line list of items with several currencies, that will create a full reconcilation with several exchange rate entries to balance the amounts in all foreign currencies. Unreconciling these lines was wrongly creating an account.move with a lot of lines with debit = credit = amount_currency = 0.
When a user creates a new column in a kanban view, leave the action and
comes back, the order is not preserved. With this commit, we force a
call to resequence to ensure that the order does not change.
The initial rev. odoo/odoo@2d3ecf2 that was supposed to handle this use case
was in fact only dealing with one command as default value for nested x2m, not
more.
The basic model can now handle multiple commands.
Closes#24241
The css generates all the attributes separately and not in simplified form.
In order to have a better compatibility we simplify the css tags.
e.g. border-left-style: none; border-bottom-s .... will be simplified in border-style = none
We convert the link.btn into a table to have a good rendering in outlook, and revert the
change when the user edit the content.
- Stripe needs to have the amount in integer, so we have to multiply by 100 the amount.
Which sometimes create float representation errors and remove/add ~1 cent on some transactions (i.e 72.60€)
- Stripe needs to have the amount in integer, so we have to multiply by 100 the amount.
Which sometimes create float representation errors and remove/add ~1 cent on some transactions (i.e 72.60€)
When you pay multiple invoice with one payment, you need the write
permission on account.journal, this had been solved when registering a
payment for one invoice in 91ca84644
In this commit, the same logic is applied on account.register.payments
opw-1835888
opw-1834343
closes#24369
Steps to reproduce:
- Go to the Contact
- Create a new contact with an email address with an ascii character
Bug:
A traceback was raised.
Closes#19852
opw:1837714
In 41ffb503 the "Invoice Notification Email" and "Sale Order
Notification Email" were modified so the company used was the one of
the object if available or the sender otherwise.
This had not been done for the "Purchase Order Notification Email" which
was added in saas-14 which might be unexpected.
Also as in 7a03f9ce9 specify the company when displaying the logo.
opw-1838112
closes#24344
ConnectionError is raised when there is no internet connection
if case of timeout a ConnectTimeout or ReadTimeout is raised.
It was not catched.
requests.exceptions.Timeout catches both
Hiral Bhavsar