It seems Paypal does not always send the same responses on auto-return
even when PDT is off. Although not reproducible on a Paypal sandbox,
sometimes the system auto-return to /payment/paypal/dpn without any
meaningful POST data. This seems to only happen with new accounts
that use the 'Hermes' web application of Paypal.
The correct thing to do would be to add a new field on the paypal
payment provider for PDT token and make the PDT flow available
to users; but this is a stable branch and this fix is already
sufficiently delicate. This shall be done in master though.
From this revision on, users can then activate PDT on their paypal
account, set the PDT token as an ir.config_parameter value (WITH
GROUP RESTRICTION SET TO ADMIN/SETTINGS GROUP!!!) and the system
will process these requests correctly.
There is a multi-company record rule on `res.partner.bank`,
meaning you cannot see the bank accounts of other companies.
Making a constraint on `sanitized_acc_number` alone prevent
to create a same bank account into different companies,
while you cannot see this bank account from the other
companies.
In this case, the user tries to import its bank statement,
and it contains a bank account which already exists
in the database but for another company than the one
he is currently importing the statement, and,
- it cannot find it because of the multi-company rule,
- it cannot create it because of the constraint
The constraint must take into account the company
opw-690969
The revision
a1d6c2d631
has been ported with an oversight:
except_orm is no longer imported in this file,
besides, the new way to raise these warnings is to
use "UserError" instead.
opw-693779
If the graph view was left while a nvtooltip was shown (thanks to
keyboard shortcuts or during loading time), the nvtooltip remained
and was only destroyed when leaving the action.
Now they are automatically removed with the view as they are now
placed inside of them instead of inside the body element.
When there is a shipping address, this is the second select tag which
is used(defined in website_same_delivery/views/website_same_delivery.xml)
opw:693127
On an accounting journal, when checking "Dedicated refund sequence",
choosing the refund sequence is mandatory. This is the subject of the
below revision:
d94c449547
Since the refund sequence field was available only for with the debug
mode, the user was not forced to choose the sequence, while he must be.
This is not possible to use the dedicated refund sequence if you do not
choose it there.
opw-693955
Instead of hardcoding the IN & OUT endpoint
addresses for the ESC/POS printers, we now
attempt to auto-detect them.
This should increase compatibility with many
compatible thermal printers that are simply
using a different address, such as the
- STMicroelectronics POS58 Printer USB
- HU HAI SUNCSW Receipt Printer Co.,Ltd. Gprinter USB Printer
Fixes#12890
The scenario when using the code view is the following :
- click on code view button to use code view
- make changes
- click on code view button to get back to wysiwyg view
- save from the wysiwyg view
If the 3rd step is not done:
- for the inline editor, we lose the changes that have been done in code
view,
- for the iframe editor, we lose the entirety of the content.
At one time the user was forced to go back to wysiwyg before being able
to save, but this have been removed hence the present usability issue.
With this fix, when the editor content is saved, if the user is in code
view he is automatically set back to wysiwyg view.
closes#14339
opw-693052
Before, it did a search to see if the package existed,
but the only thing it needs to do is see if the package
on the pack operation corresponds to that of the quant. (no need to check children also)
There is a test added:
A picking with 120 pieces incoming, 120 in pack 1, 80 in pack2
When we deliver those in a picking out, with product pack operations: (by taking them out of the pack)
120 from pack 1 and 80 from pack2,
we should only have 2 quants and links between moves in the end
And before, it generated 3 because it matched the wrong quants and made the wrong links.
opw 693760 closes#13836
In 9.0 when the pos user was not at least in the group Accountant
(group_account_user), he was not allow to close or open the balance
when the pos session was configured in cash control.
ps:be carefull with the old rule: Point Of Sale Cashbox Line POS User
deleted with a26b805f5e
opw:69251
This commit fixes the driver to respect the new device
registration mechanism via hw_proxy.rs232_devices.
It also refactors the code to more easily support multiple
scale protocols, and introduces support for the ADAM Equipment
AZExtra scale protocol. (Might be compatible with other ADAM
Equipment scales)
Support for th AZExtra scale is experimental at the moment,
especially given two annoying problems with this model:
- they do not support proper probing (stays mute until a
non-zero weight is measured), so they have to be probed
last and *assumed* to work
- the scale beeps when a read attempt is made and the
weight is not stable yet, or the weight has been already
read previously. This constant beeping during operation
is mitigated by extra delays between readings, but might
still prove to be a major issue for supporting this scale.
RS-232 drivers now need to register any device
they are handling in the hw_proxy.rs232_devices map.
This will prevent other drivers from probing them,
possibly messing up with the device.
Any update to rs232_devices must be done while holding
the hw_proxy.rs232_lock.
The hw_scale driver will be updated to use this mechanism
in the next commit, that will also handle a new RS-232
scale protocol.
- ngrok download URL has changed
- default kernel for raspbian image has changed and needs to match
- remove pre-existing git checkout to avoid conflicting
- wait a few seconds after setting up loop dev with kpartx to access image
contents - sometimes required to let the device appear in /dev
Some banks, like ING, create a line for free charges.
We just skip those lines as there's a 'non-zero' constraint
on the amount of account.bank.statement.line
The tests are running on consumable product, it means that there is no
resevation of quants and verification of reserved quants when you create
and assign moves. So the tests are not really usefull with consumable
products.
To make the tests efficients, we set the products as stockable. And we
use 'reserved_availability' instead of 'availability' in tests
'test_10_pickings_transfer_with_different_uom' and in
'test_00_picking_create_and_transfer_quantity' be cause the assert is
done after the move reservation.
In test 'test_00_picking_create_and_transfer_quantity' when we check the
move_lines state after the action assign, the first and last should be
only 'confirmed, because they are partially available. When product
were not stockable, all lines were assign, because there was no check of
the reserved quants.
In 'test_10_pickings_transfer_with_different_uom' we removed the call
'picking_out.action_confirm()' and 'picking_out.action_assign()',
because they already have been called before.
The price set for the non integrated carrier must be the same either when you
set it on the SO with button "set_price" or when you set it on the stock picking.
The field "carrier_price" must be in readonly when the state of the picking is done.
opw:691224
Hypothesis:
- We have a product 'pa' managed by lot.
- We don't create lots, when we receive products.
- We create lots when we deliver products.
- We don't have any units of product 'pa' in stock.
- We recieve 4 units of product 'pa' in one picking.
- We create a picking to deliver 3 products 'pa' (stock.move).
- We actually deliver 4 units of product 'pa' (1 in 'LOT1', 1 in 'LOT2' and 2 in 'LOT3').
- The problem also occurs when you just have 2 products in and 2 out in
different lots, but we based the example on the tests defined in
'test_stock_flow.py'
Thesis:
- We don't have anymore quants of product 'pa' in stock after delivering the 4 units
Problem:
- We actually have 3 quants of product 'pa' in stock, two having the 'lot_id' corresponding
to 'LOT3' and 'qty=-1', and one having no 'lot_id' and 'qty=2'.
Origin:
- This problem is caused by a bad condition in the function '_move_quants_by_lot' defined
in the model 'stock.move'.
Explanation:
When we reserve the 3 units of product 'pa' in the picking out, the quant in stock having
'qty=4' is splitted in 2 quants, one having 'qty=3' and a 'reservation_id' equals to the id
of the move in the picking out. And one with 'qty=1', having not reservation id.
So once the products are reserved, we will complete the pack operation present in the picking.
We will add 4 units of product 'pa' dispatched in Lot as 1 in 'LOT1', 1 in 'LOT2' and 2 in 'LOT3'
to the pack operation.
Then when we validate the picking, the quants with references to 'lot_id' must be created, and
then moved to the client.
Because we have set 4 units of the product 'pa' in the pack operation, an extra move of 1 unit of
product 'pa' is added to the picking to have a total of 4 untis of 'pa' moved to the customer
location.
When the function '_move_quants_by_lot' is called, it gets in parameter 'false_quants' which contains
the quant reserved by the first move, it means the quant in stock with the reservation_id to the first
move, and 'qty=3'.
The function, will now split this quant in 2 different quants:
- one with 'lot_id' corresponding to 'LOT1' and moved to customer location.
- one with no 'lot_id' staying in stock location still reserved to the first move.
Then, the function should reset the 'false_quants' with the quant containing the 2 last units reserved
in the quant from the last split in order to complete the next operation (create a quant with lot_id 'LOT2').
But the condition to find this new reserved quant contains (x.package_id.id != ops.package_id.id) where x is
a quant which is wrong, because when we don't manage package, x.package_id.id is 'False' and ops.package_id.id
is 'False' too. So it doesn't find the remaining quant.
So to fix it, we changed this part of the condition as the quant package_id should be equal to the pack operation
package_id (if no packages, False = False)
The partner of an account move is defined as a related on the partner of
the move lines. This kind of relation implies that the partner of the
account move is the partner of the first account move line. This is
arbitrary and doesn't make much sense.
Closes#14167
opw-693289
To have the right sign, amount = debit - credit
Before the fix:
-Create an invoice in another currency than the currency of your company
-Link the invoice lines to an analytic account.
-Validate the invoice.
Bug:
The analytic lines have a negative amount in the amount currency field
which was a bit stange as it is the opposite sign than the amount in the company currency.
opw:692557
When an asset is set as Prorata Temporis, with a one month period, the
first depreciation amount is computed on the basis of the remaining days
in the purchase year. This doesn't make sense for a monthly
depreciation.
This commit makes the distinction between a monthly and a yearly
depreciation. In the case of a monthly depreciation, the remaining days
in the purchase month are taken into account.
opw-690034
Backport of 0a3899b72c
The fiscal year start date should be taken into account when calculating
the depreciation amount in case of prorata temporis.
opw-678072
Backport of e69d9b8b7d
Steps to reproduce:
- Create a Sales Order with 2 product qty
- Keep Delivery Method as DHL International
- Confirm
- Open Delivery Order
- Edit Qty of the Delivery Order
- Change Carrier (any integrated)
- Validate the transfer
- Process the backorder
- Edit and change the Carrier to normal or free delivery charges
- Validate
Bug:
The price of the free delivery charges was not recomputed and kept
the carrier price set on the SO.
Fix:
When the price of the carrier is "fixed" or "base_on_rule", the price must
be reconsidered in case of change.
opw:691224
It can happen that the account moves generated during reconciliation
from a bank statement with several lines have the same number.
This is a complement of commit 9365482df0. The order of statement lines
is not derterministic since it is based on `statement_id desc,
sequence`. Therefore, at each call of `process_reconciliation`, the
array `self.statement_id.line_ids.ids` can be different.
opw-690853
The function open_entries doesn't have to propagate the context
because it propagated group_by from other models.
Example:
- Click on Accounting > Adviser > Assets
- Click on Group by > Category
- Click on an asset
- Click Entries
The group by "category_id" was propagated on the model "account.move"
and it led to a traceback.
opw:692888
Odoo Translation Bot